DNC error 111 / OneCNC NCLink
I would like to get my DNC up and running on my Dialog 4 and make a free solution available to everyone.
I have installed NCLink from OneCNC and it works well in mode 14.
Ross has been so kind as to send me the full program from the "FP3NC, Dialog 4. Transfer large programs" tread.
I can activate the upload from the PC. It waits for the Dialog 4 to get in DNC mode (awaiting handshake). When I activate DNC, the Dialog reports error 111 right away.
According to the error list and troubleshooting guide that Martin Peitz made available, error 111 means timeout. Weird as there is loads of data. It may mean that it expects something else.
Does any of you happen to know what might cause an error 111?
Does any of you use NCLink for DNC? I wonder if it will work with DNC.
I have now tried lots of combinations of DNC software, bit rates, databits, handshake and parity. All same result: If I start as iin Ross' split file, with $%2000, at the third character, the Dialog reports error 111.
I don't see why DNC should work at all in Mode 14. I thought DNC was all about Mode 15. Mode 14 works fine for uploading one file at a time (which I would not call DNC), but I don't think you can chain files together in that mode. Ross knows.
No, I agree. But I assume that mode 14 can be used to verify the cable and communication.
It may still be a communication issue, or it may be the Dialog that is set up wrong or needs a reset.
I use a program called DNC4U for upload/download to my Dialog 4. It's a klunky program, but it works. I think I use 4800 baud, 8 bit, no parity. I recall having to cut the handshake pin on the plug to get things to work. I borrowed some RS232 diagnostic tools including an oscilloscope, to get it worked out.
I will try with DNC4U too (if it's free).
You may have the same cable problem I originally had.
The handshake wires were swapped. I mounted a LED on the handshake signal, attached an oscilloscope, replaced the driver on the RS232 board until I decided to measure from the PC port to the driver IC pin on the board. That's when I realized that my cable was wrong. I have not yet investigated if the cable specification, that is circling around, is correct.
Now I can upload at 9600 baud without delays and without errors in mode 14. Only problem is mode 15.
I think it's time to reset the Dialog. It may hang in some odd mode.
When I have DNC up and running I will publish the whole truth about DNC and cables.
Have provided all this info before , but will post it again.
First off if doing transfers using the single program transfer in mode 14 think it is safer to use 4800 Baud. Errors will happen depending on length of the cable and the working environment....for me using a slower rate and having greater confidence that some data was not missed or corrupted is worth a bit of extra time.
There is no sure way to guarantee that the data is not corrupt when doing a transfer and when running a machine moving about under rapids i need a better percentage of success, so the 4800 is my vote to increase the chance of success.
When it comes to the DNC transfers, the stop/start flow control works better and as such higher rates are possible and more reliable...i just don't wish to muck about changing the computer and control settings when i alternate between the DNC and the normal file transfer modes...
Once the DNC feature is turned on in mode 14 you have to set the transfer settings all the same between the computer and the control. Be careful here. Windows can take control of port settings even though the transfer program is set to the correct values it does not guaranteed that the actual transfer values are what the program have been set to!!!!!!!!
I use the following for all file transfers both DNC or file memory transfer..
8 data bits
1 stop bit
The cable setup for the DNC to work (taken directly from the "AutoDNC" manual)
Computer DB9 port.........................Control RS232 port
Pin5.............................................. .Pin 7
.................................................. ....Pin 6 Tie together
.................................................. ....Pin 8 Tie together
.................................................. ....Pin20 Tie together
This setup works..........has been fine for me for years.
Once yoiu have this all set the drill is this:
Set the DNC to "ON" in mode 14 going into the "RS232" setting area. set the transfer values as well.
Do not mess about with the Timeout or Rep-count values.
Should be :
Timeout1: ON 3.......Off 6
Timeout2: ON 24.....Off 48
Rep-Count: ON 3.......Off 10
Once you set the DNC to "ON" Hit the "Acknowledge" key to exit the DNC setup window.
Change to mode 15 and toggle the top choices to "IN"
Hit the "Acknowledge" key (white dual diamonds and the letter "J")and a highlighted window will appear.
Enter the program number (only numbers)
Then press the "Transfer" key (green diamond with arrow)
The control will request the program from the computer and the transfer will start to the control.
Once the transfer has begun, you can switch modes (13) to set the program to be active. (be sure to wait until at least 3 full sections have finished loading before making the first program section active).
Once the program is active you may switch to mode 4 or 5 and jog the machine to your setup points and go to mode 10 to set your tool offsets etc....then to mode 9 to begin running the program...the file transfer will continue in the background.
You can go back to mode 14 to see how many sections have transferred...all while the file is being loaded.
Error 111 means that the computer is not sending to the control or the control does not understand what was sent.
Transfer program not able to send the program....should be a way to verify that the computer is indeed sending once the request has been made from the control. You can't start the transfer from the computer, it must be called from the control!!!
Cable is not correct....
Settings on the computer and control do not match.
Hardware problem on the DNC side of the control.
Don't believe there is anything more to the DNC setup and opeeration than the above.
It is true that you can send bad data to the Dialog, and it will accept it, and then hang. Been there, done that. I've encountered some very wacky behavior just by uploading a file with a bad character, like GO instead of G0 (G-zero) for a rapid move. A full reset is a good idea.
To tag further into your post Rich, there is no real check that data bits are not dropped or lost as well. Using parity i am told by "smart" computer types is no real check and in fact may increase the chances of sending/receiving errant data...again that is why i favor a slower transfer rate.
The Dialog RS232 port is pretty crude by current standards and the chips that run it are not too smart....
It is true that character can be lost. I have been lucky so far, the Dialog has seen it as illegal code. I hope I'll never loose a decimal point....
It also true that the Dialog design isn't up to modern standards, and yes, slower will be safer. Also with DNC, the transfer rate doesn't really matter, transfer is faster than milling.
When it comes to the cable, it is very strange. I have the corrected cable in my hand. Mine now has PC pin 7 and 8 swapped compared to your AutoDNC manual Ross. Before two inputs were connected together and two outputs were connected together. I have investigated this very very carefully and I'm 100% sure that these two signals are correct now. Before the transfer rate was very unstable due to the floating inputs, now it's stable as expected.
I think the Deckel would benefit from a fibre connection (insensitive to noise). I will probably design one in the not too far future, so let me know if anyone wants one.
I just had a very nasty experience. It may help others with a totally dead control one day, so here it is:
I followed the reset procedure on dialog5.com, and I took all IC's out of their sockets and reinstalled them to clean the contacts. Then the Dialog was totally dead, blank screen. Took it all apart, checked everything and assembled it again 5 times. Still totally dead.
Then I realized that there is a solder bridge next to the positive terminal of the battery on the RAM board. I removed the solder to disconnect the battery and get rid of any content in the RAM. Soldered it again and powered up. Now it works and all parameters are reset to default.
The bad news is that DNC still doesn't work.
I don't know where to go next. I may design a logic analyzer that will fit under the CPU so that I can reverse engineer the software of the control.
This is exactly how I do it. And now with DNC4U.
Originally Posted by AlfaGTA
This is the only thing I'm not sure I understand. How does it request the file? I start the transfer on the PC. The Dialog halts it using handshake. When I press transfer, the transfer starts.
Originally Posted by AlfaGTA
With the file you were so kind as to send me, I type 2000 as the program number. After receiving the third character, it fails.
If the file transfer does not start from the computer when the control requests it ...that i believe is your problem.
The transfer must i believe be started by the control and the transfer program must respond by sending the file. Your last post sounds as though you are sending the file from the computer directly...this will not work i think.
The setup of the Dialog DNC is different from most any other machine tool. Commercial DNC software may not respond correctly to the control's request for the file to be sent....This is i believe unique to the Dialog machines so perhaps a program available on the net that is "generic" DNC will not understand the format of the sample file i have sent you.....
You might be able to "trick" the control and computer by first sending the request from the control in mode 15 and then start the send on your PC manually......might work.
There might be another issue you are fighting....
That sample program i sent you is an inch program, and i am willing to bet your machine is set to run metric..
Change the machine to run in inches and try the transfer.....
(mode 16, press the "I" key)
that's a couple of very good ideas, I will test it when I get home from work.
I have tried sooooo many combinations, including changing your program to metric, but now that you mention it, once I have seen it fail, I have stepped back to the file that was verified to work, the one you sent me. This could very well be one of the problems that I'm fighting. I haven't used the Deckel in Imperial mode, so I thought it would change to Imperial automatically when it received the first $ character.
Also, I have tried a lot of different transfer timings, but it may indeed be that the Deckel needs some special DNC software. If I won't have more success soon, I will have to call DMG and ask them if they can come over and verify that the Dialog works with their software. Originally, I thought that I may be able to convince them to give me another copy, but as I understand it now, I also need a license dongle.
Rich, do you use AutoDNC for mode 15, or only for mode 14? How are your settings?
I cannot use Mode 15, as I do not have the proper Dialog firmware for DNC.
I have now had the Deckel set to Inches. Still same problem. I now feel convinced that the problem is related to the DNC software.
I wrote an email to the AutoDNC people a few days ago, asking if they still offer a Deckel solution. No reply.
I just wrote an email to Jaertek asking if they have an evaluation version of their DNC software available.
I will probably also call DMG tomorrow.
Send me your email address (via private message is fine), and I will send you some Dialog code that I know uploads fine to my machine. Have you been sure to zero out the six characters near the top of the file, for example (($%36/0000B8) -> ($%36/000000)) and the four characters at the very end (17D7 -> 0000)? See code below. Also, try downloading a hand-entered file from the Dialog to the other computer.
T1 R0.4375 A L0 A
N10 G17 T1
N20 G0 X0 Y0 Z0
N30 F8.0 S+1250
N40 G76 F8.0 S+1250 G3 X1.502 X0 X0.1 Y1.15 F4.0 Z-0.19 Z-0.19 Z-0
N50 G0 Z4