View Full Version : dnc transfer trouble

Joe Black
11-07-2005, 05:33 PM
hi. i am having trouble transferring files from my fanuc 15m. every so often a line is missing and or blocks and lines aren't transferred either. i have the settings as per the settings pages from editCNC. can anyone point me in the specific place to adjust settings please..

thank you in advance

11-07-2005, 09:16 PM
051107-2036 EST USA

Joe Black:

I think you are in the wrong thread. Machine Controllers, Software, and controllers maybe a better place. But some questions and comments.

By DNC do you mean drip feed via RS232? If this is the case, then your communication is from Computer to CNC.

Are your errors really quantized to a block (record) or do you have random errors within a record? My definition of record is a line of data ending with CR, LF. This record could be from 0 to any number of bytes. You might define a block as ending with a EOB character and maybe there are never any CR, LFs.

You need to indicate your serial communication parameters, cable length, and whether you have electrical isolation between the RS232 ends. Note I am assuming you are using RS232. Is this correct or not?

Continuing my assumption. If handshaking is not working correctly then this might cause the problem. You always want to set the Computer RS232 UART FIFO buffer to minimum. Microsoft defines this as 1. Whether you are using XON/XOFF (software handshake) or RTS/CTS (hardware handshake) you may overflow the receiving buffer in some CNC's that have very small receiving buffers by not disabling the the Computer UART FIFO.

Somewhat of a mystery why the errors are whole blocks.

Maybe your control throws away any record that has one or more byte errors per block. In HAAS machines certain types of errors cause an entire block to be placed in parens. In HAAS other errors abort the data transfer without any indication of where the error is.

For some general information on RS232 communication and Noise see our web site www.beta-a2.com .


Joe Black
11-08-2005, 04:40 PM
HI sorry about the wrong thread. the site is a little confusing and im only new to it. What i am talking about is just the transferring and backing up of my NC machine programs. I can't actually drip feed as the machines don't have enough buffer to hold data before it is used and the machine stop starts as some of the information intricate. The problem im getting is when i backup my machine programs, some of the data within the blocks is lost. (very dangerous if i have to reload the programs). i find that the data is fine for the first maybe 2/5 of the transfer and then i start to lose the data. i am not an expert on cnc's, i don't know what CR,LF is, although i have seen it in the software setups page. i am using rs232 with a cable being about 30meters long. i don't know where to tell the machine the cable length. the errors are random as i compare 2 separate transfers of the same backup. i use fanuc controllers. if you could help more that would be a appreciated. if you would to email me direct so i can get out of this thread its red_bmw@hotmail.com thank you

11-08-2005, 08:07 PM
051108-1907 EST USA

Joe Black:

Let's concentrate on your data transfer from CNC to Computer.

You indicate that your cable is about 30 meters ( 30 x 40 = 1200 inches, or 100 ft ). That is long for RS232. However, the length you can work with is a function of baud rate, cable capacitance, and driver and receiver characteristics.

A bigger problem may be electrical common mode noise voltage between the CNC and Computer.

You are indicating that you get a least 2/3 thru a program transfer before errors develop. This does not logically correlate with either noise or a cable length problem. From noise and length problems the errors should be more uniformly distributed. You have not indicated file sizes. If the files are very small like 1 kbyte, then your 2/3 may not tell us much. If your files are 1 megabyte or more, then the 2/3 characteristic is very important.

CR, LF refer to Carriage Return, and Line Feed. In old fashioned typewriters the CR-LF function was performed by one lever. However, if you did not pull hard you could perform the line feed function alone. I believe the Teletype machine was the first machine to explicitly separate these two functions. Computer communication evolved from the Teletype machine. Different computer operating systems today use one or the other or both CR and LF to end a record. A record is loosely one line of data.

At what baud rate are you operating? How many data bits? What type of parity check? And how many stop bits? I am assuming that your CNC and Computer are both set exactly the same for these parameters. I do not think you would get as much data transfer as you see if this were not the case.

Can you make a short cable, maybe 10 ft, put the Computer next to the CNC, derive AC power from the 3 phase to the CNC thru a transformer, and connect the chassis of the Computer to the CNC chassis with a #12 wire? Then run the test. This should eliminate ground noise, and cable capacitance problems.

What operating system, computer, and communication software are you using? Is editCNC the communication software? If it is the communication software, then is there any other that you could use?

You may have looked at my web site because I saw some activity from Australia. If you have not, then look at the page on Noise and Grounding.

When you report back make sure you tell us about all the RS232 settings, and other points mentioned above.


Dan Fritz
11-08-2005, 10:15 PM
From the way I read your posts, it sounds like you're data loss is happening when you're PUNCHING a file from the CNC, and the PC is trying to receive.

You also didn't mention what kind of PC you have (processor type, speed, Windows or DOS, etc.). It would also be helpful to know know what software you're using on the PC side.

Generally speaking, when the PC is not able to receive all the data, it can be that the serial port in your PC does not have a FIFO buffer, or that the RECEIVE buffer is set too low. Gar is correct when he says that the FIFO buffer should be set low, but he's referring to the TRANSMIT buffer, not the receive buffer. A transmit FIFO buffer that's too high will overflow the buffer in the CNC when sending a file TO the CNC, but receive buffer that's too low (or turned off) can create trouble when the CNC is sending to the PC.

Windows PCs from Windows 95 on have this FIFO buffer setting hidden in the Control Panel. The exact path is a little different for 2000 and XP, but here's how to find it:

double-click the SYSTEM icon
(on 2000 and XP) Click the HARDWARE tab, then DEVICE MANAGER button
(on 95/98) click the DEVICE MANAGER tab
double-click on PORTS (COM and LPT) to expose the list of ports under it
Right-click on the COM port you're using for DNC (usually COM1)

For best DNC performance, be sure the "USE FIFO BUFFERS" checkbox is checked, and set the "Receive buffer" to about 3/4 scale, then set the "Transmit buffer" to the lowest possible setting. Click OK many times to exit all these menus. Re-open your DNCs serial port and try again.

Also be sure that your DNC software's "Stop-bits" setting matches the CNC. To find the Fanuc 15s stop-bits setting, look at the SETTINGS/HANDY page for the settings "INPUT DEVICE FG" and "OUTPUT DEVICE FG". There are also two identical settings marked "BG" but these only apply to background editing. Normally all 4 settings are the same number (1, 2, or 3). If they're set to "1", then look at paramter 5111 for the stop-bits setting. If set to "2", then look at parameter 5121. If set to "3" then look at parameter 5131. These parameters can be set to "1" for 1 stop-bit, or "2" for 2 stop-bits. It doesn't really matter what your stop-bits setting is, but it's VERY important that your DNC software be set to match it.

If the FIFO buffer is set correctly and the stop-bits settings match, the only other logical reasons for lost data would be a bad (or tool long) of a cable, or a bad chip (either the transmit chip in the CNC or the receive chip on the PCs serial board.

One other thing can create trouble here. Some older PCs had serial ports that did not have FIFO buffers at all. On slower PCs running Windows, it's VERY important that your serial port have the FIFO buffer capability. A really old serial board (without a FIFO buffer) in a Windows PC is bound to create the trouble you describe. You can buy a new serial board for about $10-$20 at any computer store.

Also, are you trying to save your file on a floppy disk ? That could explain why 2/3 or so of your program comes in OK. When the disk drive fires up to save some data, the PC may not be able to buffer the data that's coming in from the CNC. Try saving on the hard drive to see if that problem goes away.

Joe Black
11-08-2005, 11:06 PM
thanks for the feedback so far. Gar it would be hard for me to do what you said with making a 10mtr cable and take the wiring from 3 phase. i am using win98, editCNC with settings as recomendend. baudrate-2400, data bits 7, stop bits 2, even parity, flow control Xon/Xoff. Xon Char. 17 Xoff Char. 19. parameter settings for fanuc controller. #5001=1, #5002=2, #5003=3, #5110=4, #5111=2, #5112=9, #5120=4, #5121=2,#5122=9,#5130=4,#5131=2,#5132=9. Tv check 0, punch code 0, input device 1(rs232c). the transferred program files are about 290kb. this problem only starts occuring at about 2/5 to 3/5 the way through transferring. i downloaded pc-dnc editor for a trial to see if it works. but when it tries to convert the data after the download it comes up with some runtime error and shuts down. if you need more info just ask. in regards to dan's post. it actually starts transferring and reads the data fine, and completes the transfer, but when you open the transferred file, you can see errors, such as characters missing, blocks joined to next block, lines missing and so on.
i have just setup what dan has described and will let you know how the results are. something just occured to me as i was setting it up. on the same pc there are other people in the factory using a scanner via that pc maybe they had scaned something at a certain point while the transfer is happening. what you think. also i know its not the circuits on the nc as i have 3 and it happens on all. thanks guys for your help so far..

Dan Fritz
11-09-2005, 05:07 AM
From your last post, I see only one setting on the CNC that's different from our recommendations for the 15M control. The parameters 5110, 5120, and 5130 are set to "4", where we always set them to "3". This is a protocol setting, so it may have some effect here.

You said that you tried our PC-DNC Editor and it shut down when trying to code convert the file. This can only happen if there is some kind of totally bogus data coming in. I suspect that the CNCEdit software simply drops the characters, where our software just bombs out during the code conversion.

If setting "3" in those three parameters doesn't do the trick, then I would either find another PC to try or buy a new serial card for the PC you have.

Good luck!

11-09-2005, 02:34 PM
051109-1417 EST USA

Joe Black:

Dan is giving you good information. Yes the transmit and receive FIFOs should be different at the Computer depending upon the Computer software.

Others processing data thru your same Computer at the time you are receiving might cause problems, but again this would not correlate with the beginning of the transfer being OK because those other events would be random to your transfer, and should be evenly distributed in time relative to your transfer start time.

Your baud rate is very low. Have you tried higher baud rates to see if this has any effect on where the failures occur. Once you get your baud rate high enough you will have many errors throughout the file. If you can get high enough for this to happen, then back down to 1/2 that baud rate.

I like the idea from Dan that you are possibly overflowing some large receive buffer in the computer receiving software.

I really do not like the program Hyperterm which comes with Windows, but have you tried it?


11-14-2005, 09:32 AM
Lets look at the cable and how it is run.

1) Is this a home made Cable is it sheilded?

2) How is it run are you running it along power conduit or Pips that contain Eletrical Wire thru it?

Sounds like the normal dropping fro interfrence noise.

11-14-2005, 11:05 AM
051114-1056 EST USA


If Joe's problem was noise, then the errors should be uniformly distributed relative to the beginning of the file. But Joe seems sure that the errors do not occur before about 2/5 to 3/5 of the way thru a 253 k file.

This is a large file and at 2400 baud takes about 17 minutes to transfer. If no errors occur within the first 2/5, then that is 7 minutes error free.


11-14-2005, 12:10 PM
Gar that is not always true. I see this all the time with our customers.
Were it will drop characters any time thru the program and some times it is due to what is connected to the power source of the Run.

I have customer for long time it would just due this once in a while. Then come to find that it was only when the Wire EDM was running did they loose characters and it could be right in the middle of the program.

So this why I bring this up.

11-14-2005, 02:32 PM
051114-1411 EST USA


I do not disagree that it is possible for noise to cause data errors. That is my business to minimize such problems.

Joe says he has no errors until at least 2/5 the way thru a file and that is about 7 minutes. I conclude that this means never in the first 2/5. Certainly from his description the probability of an error is very high after 2/5 and very low before 2/5. This does not imply a non-correlated noise source as the cause of the problem.

A random noise source (not correlated with the start time of sending the program ) would be just as likely to occur in the first 7 minutes as each succeeding 7 minutes.

If you can tell me that the wire edm machine knows when I am going to start sending the file and it plans to wait a minimum of 7 minutes before it starts operation relative to the time I start sending the file, then I would consider it a possible cause, otherwise not.

Based on probabilities it makes no sense to go looking for a random noise source problem. The information points in other directions for the primary cause.


Joe Black
11-14-2005, 05:39 PM
the cable is home made. it runs along the ground and is rolled up in some spots. but does not run near power cables. i have changed the baud rate and it still didn't fix the problem. i don't have problems transferring smaller programs. just the big ones.

Dan Fritz
11-14-2005, 07:25 PM
gar is right. There's no reason to suspect random noise in this case.

Are you sure that the ground wire in your cable is OK ? That would be the wire from pin 7 on the CNC side to pin 5 on the PC side (if the PC has a 9-pin plug) or pin 7 (if the PC side has a 25-pin plug). A faulty ground wire can let the ground reference level on the PC "float" with respect to the CNCs ground. This might conceivably cause a situation where the data might come in fine for a while, then (when the ground reference gets more than a few volts out-of-whack) start to malfunction.

If you or someone you know has an oscilloscope, you could have a look at the data line sending data back from the CNC to the PC, using that same ground wire as a ground reference for the scope. If I were there, I would look at the voltage level of the data pulses both at the CNC end of the cable and at the PC end. Any difference would mean a cable problem of some kind.

A normal RS232 signal would have data pulses that go from a "low" of -3 to -30 volts DC, and a "High" of +3 to +30 volts DC. The +/-3 volt level is the bare minimum for a legal RS232 signal, and the +/-30 volt level is the voltage at which the IC chips are likely to blow. A normal level for the Fanuc is about 12 volts. The actual voltage doesn't matter, so long as it always stays between +/-3 and +/-30 volts.

You should always see about +12 volts or -12 volts on the wire going from pin 2 on the Fanuc to pin 2 on the PCs 9-pin plug. A signal that "floats" around relative to ground means that the ground wire itself is the problem.

I've seen serial ports where the IC chip is damaged, but the signal gets through anyway. The signal might go "high", then go to zero volts instead of going negative. The opposite can happen where the signal goes "low", but never goes above zero volts. This is usually a blown IC in the CNC control, or a bad power supply to the ICs.

Have you tried using another PC, or plugging a $10 serial card in your current PC and using that COM port ? That would eliminate a bad COM port in the PC as a possible problem.

The Fanuc 15 has 3 internal COM ports, and you could shift to another one by moving the internal serial cable to a different Honda plug inside the CNC cabinet, then setting your INPUT DEVICE and OUTPUT DEVICE bits on the "setting" page to match. To give you more specific advice on this, I'd have to know where your internal cable is plugged in now. If you can follow the cable from that serial plug under the flapper door to the CNCs board, let me know what the Honda plug number on the board is.

Joe Black
11-15-2005, 02:22 AM
i will try change the pc or atleast the serial card over the next few days. i am a little flat out at moment. thanks guys

11-16-2005, 08:02 PM
051116-1921 EST USA

Joe Black:

To review --- we are talking about communication from the CNC to a Computer. You never have any errors sending a small file. When you send a long file, for example 250,000 bytes, there is never an error before about about 2/5 of the transfer, or 100,000 bytes. There are no errors sending from the Computer to the CNC, any size file. Other users are sharing the Computer.

You must have all your RS232 communication settings exactly the same at both the Computer and the CNC. I do not expect any problem here because you would never get 100,000 bytes error free, if these were not set equal to each other. The only possibility is that handshake is not working in this direction, and there is about a 100,000 byte buffer in the Computer.

It is unlikely that the problem is hardware or common mode noise.

Other users on the Computer would look like random noise and would just as likely produce errors in the first 100,000 bytes as any succeeding group. However, it would be useful to run a test where everyone was prevented from doing anything to your Computer while you were sending data to the Computer.

If you have any pure DOS machine with a old fashioned, but good, communication program it would be useful to try this.

Under DOS we can and have transferred very large blocks of data at 38.4 kbaud with continuous transfer of this data to hard disk. Here the ram buffers would be of moderate size, like 256 bytes, before the DOS buffer to disk.

Under Windows XP Pro and our E232 RS232 to Ethernet System we transfer very large files at 115.2 kbaud to disk with no errors.

Basically I think you need to try a different RS232 communication program and maybe a newer faster machine and under XP Pro. Also you might try an NT machine because NT does not hog large amounts of processor time like other flavors of Windows.

If your information on the roughly 100,000 byte error free operation is not correct, then it is a totally different ball game.


11-16-2005, 11:58 PM
Go to http://www.shopfloorautomations.com and download the Predator editor that has communications then email me and I will get you 30 day codes to try it with the communications.

Just so Gar knows XP Pro is NT it is NT6 all built on the NT Kernal.

Joe Black
11-17-2005, 02:59 PM
ok, here's what i done. i swap the transfer program from editCNC back to an old (i mean old) dos based program. my windows switches back to dos to run it. the transfer works fine. it comes across at 4800 baud rate. so would this mean my settings on editCNC are wrong? i have set it up as reccomended for fanuc 15m.

11-20-2005, 10:35 PM
051120-2210 EST USA

Joe Black:

Is your editCNC inherently a DOS program? Did you run the exact same program under DOS and Windows?

Is you communication program (transfer program) an integral part of editCNC or is it a standalone program?

As I said before it virtually impossible for you to have the standard communication parameters different at the two ends of the communication path and have error free transmission for 100,000 bytes. At the low baud rates you are working at even if software handshake was turned off at the computer there is little likelyhood of over-running a properly designed buffer. But it is also unlikely that you can independently set handshake values for transmit and receive at the computer. If handshake was set wrong at the computer, then you would not successfully send to the CNC.

It seems very much like your editCNC has a problem interacting with Windows. There are many situations where a program will work ok on one version of Windows and not another.

Windows XP probably causes us less problems than other versions of Windows. But XP can sure get in states where your application program gets very little time share time. On the other hand a random failure of Windows is not going to cause your problem. Your problem is more deterministic.

Do try to find a different communication software program that is known to work correctly with your operating system.


Dan Fritz
11-20-2005, 11:25 PM
One little-known fact about Fanuc controls is that they only use Xon/Xoff handshaking when they're RECEIVING data. When a Fanuc is sending data, the only way to get it to pause for a moment is to drive pin 5 (CTS) low. If you set your editCNC software to use RTS/CTS handshaking, it should do this OK. Remember, that Xon/Xoff is the correct setting when you're sending a file from the PC to the Fanuc, so you'll have to set it back to Xon/Xoff to go the other way.

If your editCNC software is a DOS product, it may not work well under Windows. Try booting your PC in "MS-DOS mode" and see if it runs better. If you have a floppy disk drive, you can also just boot it from an old MS-DOS 6.0 or 7.0 disk, then start the DNC software.

Windows NT, 2000 and XP do not let old DOS software read and write directly to the hardware (the serial port), so this could be a compatibility issue. If you're running DOS software under 2000 or XP, try downloading some freebe Windows software just to see if there's a difference. We have a 30-day demo of our PC-DNC Editor that you can try for no $$, just to see if that's the problem. The link to that demo is:


Sometimes, Windows computers go "brain dead" for a second or two while some other task runs (virus checking, Windows update, disk driver read/write, etc.) A DOS program running behind Windows will just get starved for processor time, and may loose data. This is why all new Windows PCs come with serial ports that have FIFO buffers (so data can keep coming in when the processor goes to sleep). What frequently happens is that an old serial board (without a FIFO buffer) gets plugged into a newer Windows PC. That old board might run fine under DOS, but will loose characters under Windows. That shouldn't be your problem because, as gar said, you have good data reception for 100,000 bytes before this problem pops up. Could it be that your editCNC software is buffering that much data before it tries to write to the hard drive? That could be the "brain dead" event that's causing the trouble. Keep an eye on the disk drive LEDs and see if they blink on at about the time you loose the data.

Hope this helps.

Joe Black
11-22-2005, 05:28 PM
thanks for all your input. i will start my trouble shooting soon as i get out of this busy period

11-27-2005, 06:22 PM
I am trying to drip feed to a Dynapath 50 M control. At times I can do this successfully, but more times then not I get error messages,
Buffer Input: parity error.
I have tried different software, computers, cables, cable lengths, Baud rate, and settings, such as character and line delays, parity settings and X on X off, DTR DSR and RTS CTS.
Nothing I have tried will give a reliable handshake. I have talked to Dynapath and they feel it is the mother board. Dynapath feels if I add a hard drive ($800.00) I can eliminate the use of the drip feed and eliminate the problem.
Does anyone have thoughts or experience with this issue?
I would really appreciate your input on this problem.

Thanks in advance for your help.

11-27-2005, 08:54 PM
051127-2036 EST USA


You have provided far too little information.

What is the operating system on your computer?
What is the computer?
Is the serial port built-in, or is it a USB to serial adapter?
Is your computer transmit FIFO set to minimum (probably 1 under Microsoft)?
What baud rate?
What cable length?
What are the serial parameters at both ends?
Do you know the brand of cable and its part number? (for example Belden 8723)
Is it always a parity error?
How many bytes are transmitted before a failure?
What are your file sizes?
What is the AC and separately DC voltage between the chassis of your computer and the CNC machine frame?
How many files and of what size can you successfully send?
Have you had or currently have any other unexplaine control problems?
Are you in a hot climate?
Has the machine ever worked correctly?
Can you send error free to another CNC or computer?

Any errors when sending from CNC to Computer?
How are you connectors wired at both ends?

There are probably more questions to ask, but answers to these might help?


11-30-2005, 08:02 PM
Hello Gar,
Thank you for your reply. Sorry I was not able to answer sooner.
The company has decided to add the hard drive and forgo the anguish of the drip feed method.
I do sincerely appreciate you offer to help.
Thank you again.