What's new
What's new

Dynapath Delta 20 drip feeding program error "next character not N"

BenTerrible

Aluminum
Joined
Sep 21, 2009
Location
San Diego, Ca
I have been testing out the drip-feed via RS232 option on my Tree 325. My program is just over 5000 lines, a simple facing operation, then outside profile cut (rectangle), and lastly an engraving operation on the top face. The problem I am running into occurs a bit sporadically.

Error: 131 "Next character not N"

This is very strange, in that the program error pops up at different spots during the program. It doesn't seem to be stuck at one specific line. I noticed that if I am slower doing a manual tool change (program stops at M6 and I have to change tools manually, then cycle start to resume) then the error will occur earlier in the program.

After I discovered this I decided to perform a test. I restarted the program and decided to run through without actually performing the manual tool changes required. Instead, I just hit cycle start at each tool change in an attempt to "keep up" with the program feed from my laptop. This actually worked, the program ran flawless, no errors.

Perhaps I have a setting incorrect inside the DNC software I am using to deliver the program to the machine? I am using ProDNC 5.0.

Does anyone have experience with a similar issue?
 
I'd say to single-block through it next but 5,000 blocks, that'd take a while :)

My next thought would be handshaking .... also, is your cable a full serial cable or is it one of those 5-lead cables ? And are you using software handshaking or hardware ? Is there a buffer size setting you can increase in the software ?

Since N is the first character in a block, sounds like there is a timing problem between the end-of-block signal and the next block's N. Can you drop the speed one notch, just for testing ?

Some serial cards are kind of cheesy, too :(
 
1. Single blocking was mentioned to me by a friend of mine and yes, would take forever. I would like to know how to set this up for future diagnosing. I am guessing there should be an option in the DNC software to allow this? Or is it on the machine side as far as enabling single-blocking (have to push cycle-start for each block)?

2. The serial to usb data cable is a Keyspan, which is recommended by Pro DNC. Should I be using something different?

3. Handshaking-is there a way to test/make sure this is happening bet3the machine control and the computer/software?

4. Parity and Baud rate-can anyone go into detail on these?

Thanks!
 
I think you need to slow down your baud rate. It sounds like your program is download is outrunning your machine. It has been a long time since I had to drip feed but is seems like I had to play with the speed to get it to work.
 
Appreciate the input. If I remember correctly, Baudrate is set at 4800 currently. I was given settings when I purchased the machine. I will double check later this afternoon.
 
1. Single blocking was mentioned to me by a friend of mine and yes, would take forever. I would like to know how to set this up for future diagnosing.
This is communication between two computers and it's really hard to see because it happens so fast ... they do make instruments but they are expensive.

They make cheap serial testers with little lights that show what's happening, but they are only good for basic tests and making sure you are getting your signals. No way you can watch them in action and see "oh look ! It's sending before the handshake !" unless you are Superman :)

Might be worth grabbing one just to check the basics but isn't going to solve this problem, I theen.

You could try transmitting the files to a laptop connected via your data cable and see if it comes through correct. But that isn't foolproof because the lappy might have bigger buffers or a faster serial com chip than your control so it isn't a foolproof test.

The serial to usb data
Eek. You just added another layer of hidden complexity. I would definitely be using a real serial card. I have never had any luck with any kind of usb adapter. If you get into this and talk to real professionals who do firewire, serial, even ps/2->usb they say most commercial products are shit, don't follow standards, work half-ass, etc etc. I have yet to find even one usb->ps/2 adapter that follows the standard, which means they flat do not work for me (SGI is not peecee.) But they should ... crap products.

Handshaking-is there a way to test/make sure this is happening bet3the machine control and the computer/software?
Yes, but expensive. Easiest quik-n-dirty is just to slow it way down, see if that fixes the problem, then go up a notch and up a notch until it kacks again. Then drop back one. I have had better luck with hardware handshake. I ran serial cables a good 100 feet successfully, which is not supposed to work, with good wire and hardware handshake.

Which reminds me ... how far are you running this, and it's not parallel to any other wiring, right ? No lighting or electric wiring next to your serial cable, no welders with a shared ground, the ground lead/shield on your cable is connected at ONE end not both, shielded cable, all that ?

4800 baud isn't real fast tho, unfortunately. If that's where you are, 2400 might give you starvation at the machine. Try and see ....

IMO hardware handshaking, a full serial cable instead of the abbreviated ones, and a high-quality serial card will work much better than your usb thing.

Or just experiment with speeds until it seem dependable enough :)
 
Appreciate the input. If I remember correctly, Baudrate is set at 4800 currently. I was given settings when I purchased the machine. I will double check later this afternoon.

That sounds like what we used for loading and unloading programs but I am pretty sure I slowed it down for drip feeding. As long as your PC matched your CNC you should be able to use any of the settings.
 
The following is not specific to the Dynapath control, but to RS-232 comms in general....

Reducing baud rate is almost always a band-aid fix to improper handshaking. That can be a hardware or software issue and sometimes tough to determine which. For uploading and downloading the machine memory I've found using software handshaking (XON/XOFF) and a simple 3 wire cable to be fine on all the controls I have regularly used. For drip feeding, I always switch to hardware handshaking and an appropriately wired cable when using a USB-RS232 adapter.

The Keyspan USB-RS232 adapter is supposed to be good. I've not used that brand but Moxa is a good one. I have used that at 9600 baud to drip up to 4 meg programs with no data loss using hardware handshaking. Before getting the Moxa adapter I tried 2 others and found they would drop data. I've also found that PCMCIA and PCIExpress card to RS-232 adapters work well on laptops equipped with either of those ports.

I've not used the software you have but I'm sure it is very good. It is a product of the same company that makes DNC4U which is my favorite comm program.
 
Emailed a friend of mine that was doing comms in fruit warehouses. Long runs.
Here is his reply with come editing.

"The long runs I did were RS-485, not RS-232. You may be right about it being caused by noise. Grounding at one end is the accepted standard, but I don't think you are going to be able to diagnose with out putting an oscilloscope or something on the line, like we did at XXX fruit. Even there, the signal that looked better performed worse.

If it's outside noise, you will probably get random junk even when you are not transmitting. Is that the case here?"

So beg, buy or steal a decent oscilloscope. It doesn't have to be very fast.
Check the line with no signal transfer and see how much noise you have.

The try the same thing with a signal. It is at least a place to start. ;-)
Hang in there.
 








 
Back
Top