dnc transfer trouble

[Joe Black]

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

[gar]

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]

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

[gar]

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]

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:

Click "START", then "SETTINGS" then "CONTROL PANEL
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)
Click PROPERTIES, then PORT SETTINGS, then ADVANCED

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]

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]

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!

[gar]

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?

.

[cadcam]

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.

[gar]

051114-1056 EST USA

cadcam:

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.

.

[cadcam]

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.

[gar]

051114-1411 EST USA

cadcam:

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.

.