RS-232 transfer errors are destroying our machines

You pay hundreds of thousands of dollars to get a state of the art machine yet have to rely on one lousy parity bit for error checking? In a short time we have had two major transfer errors, the first one was spotted early but the second one resulted in a major crash. Is there any kind of redundancy or CRC checksum to use for data transfer via serial port, for Fanuc control (31i)? Thus far the only solution to combat this issue has been to transfer the program to machine and back to PC and compare the transferred file with the original one.

316head said:

You pay hundreds of thousands of dollars to get a state of the art machine...

Click to expand...

Oh boy, here we go again ....

I've been sending files to a Brother HS3100 since '97, an HS50A since '01, a Haas SL10, Minilathe and Minimill since '02, a Haas VF4 since '06 ... All via RS232.
To date, not one transmission error that has not been flagged by the control upon reception.

At the same time, I would not even think of setting up (again) a rig to send files to my '07 Fanuc OiTc via RS232.

I know how to do it, I know what it takes, I know how to make it work.
I just don't fucking care anymore, and that says it all!

What software are you using on the PC side? Are you doing simple transfers or drip feeding?

For example, I have seen Hyperterminal exhibit some extremely undesirable behaviour when drip feeding that caused lost data with no error at the machine (timeout waiting for CTS from the control and send anyway). Proper DNC software doesn't have this problem.

On a 31i you surely have better options for transferring programs?? Ethernet, USB, or at the very least PC Card?

Thanks for the replies.

I actually just recently started digging into the problem, it wasn't my problem but after the major crash I was asked to make sure it won't happen again. The serial ports are on the motherboard, so they are as "true" as possible, however the cables are in abysmal condition. Still, shouldn't the probability of two bits flipping (thus rendering parity useless) during data transfer be pretty much non-existent? I'm starting to believe the DNC software is faulty, because I haven't had any transfer glitches myself ever and the software (which will remain anonymous) is substandard, but very common in my country. I will also check out alternative methods of program transfers.

Thanks again.

Make sure the baud rate is correct for the machine if it's not set properly it could effect your programs receipt in various ways many of which wouldn't throw an alarm.

How fast are you sending/receiving? I run 4800 baud on everything here. Haven't had a problem. I usually start seeing errors at 9600. Check your handshaking protocol.

wouldn't it be nice if someone made a control that checked for syntax errors in real time as a program was downloaded?

Oh yeah Heidenhain did , 30 years ago.

The only time I have ever seen errors is when trying to download a program that is from a newer control[or CAM for a newer control] into an older control.

going back to Terminal in DOS

but Fanuc is great I get it............

Does your 'state of the art' machine not have an Ethernet connection?

the abysmal condition and the length of the cable both cause data loss in transfer....its that simple....the way to check this? get a short cable brandy new and see if any data loss.....if not then get a brandy new LONG cable that is rated for long transfer data...we had the same problemo....we had a contarctor install new long dtat transfer DNC cables....and now some of the machines are a quarter block away with no data loss

316head said:

Is there any kind of redundancy or CRC checksum to use for data transfer via serial port

Click to expand...

A CRC check is performed at a higher level in a transfer protocol. Your RS-232 is the data link level.

I made the mistake of transferring a program written offline on a dos computer into a Fanuc controlled machine lower case letters will not transfer. May not be the problem, but I will throw it out there in case.

What does Fanuc say about this, and why won't the boss believe Fanuc?

I have fought with this occasionally over the years.

There is a fairly specific relationship between the length of the cable and the rate that you can send data. The shorter the cable the faster you can transfer. Push the limit and you will start to see errors.

Having a bunch of programs running on the DNC computer can also cause issues. I have no idea why or how, just empirical evidence. I have dedicated computers at each machine (close) and they only run the DNC program. I haven't had any problem using old, obsolete computers for the DNC terminals.

I use both the transfer program from Mastercam and the free one from ONECNC. Both seem to run fine.

I use a shielded cable, and make sure it isn't routed in the same area as my AC lines. Not sure of it helps or not, but a machine shop is a noisy environment, so every bit helps.

If your cables are in bad shape, there's no telling what kind of electronic signals are being received while you're transferring data. I had no idea how much that kind of stuff mattered until I worked in a place that specialized in electrical stuff and the signals involved.

Most of the above is good advice. RS-232 is pretty tolerant of poor conditions and what works for some will be a headache for others. Be sure that your comms settings match exactly and your handshaking method is supported properly by your hardware and cable configuration.

Often when RS-232 links are being set up, the program used is pretty short. The tech gets that to transfer both directions and calls the job done. That is no way a sufficient test of reliability of the connection. I test comms reliability with a 4meg file of incremental .01" moves in all 3 axes. There are equal number of moves in both directions so at the end of the program the machine should be back to 0 on all 3 axes if no data was lost. I set the feedrate override to the point that the control starts to starve for data at whatever baud is being used so that handshaking is occurring constantly. If a setup makes it through 3 or so test runs like that I can be sure that the link integrity is good.

Good that your RS-232 ports are native to the motherboard. USB to RS-232 converters are often a source of trouble. I went through 3 different brands to find one that worked 100% of the time.

If your RS-232 runs are longer than ~50 feet it is a good idea to invest in low capacitance data cable. Be sure that your cables are shielded. Braid is preferable to foil. Shield connected to ground on one end only. Be careful about how the cables are run. A problem area I've seen is putting cables close to fluorescent light fixtures.

DNC4U is my favorite software. Super flexible and works perfectly with every control I've ever tried it with. There are other good ones out there too.

All that being said, your 31i control should have Ethernet connectivity. Make the switch.

gustafson said:

wouldn't it be nice if someone made a control that checked for syntax errors in real time as a program was downloaded?

Oh yeah Heidenhain did , 30 years ago.

Click to expand...

So did Haas ... for a long time.

But then the Next-Gen was born....

gustafson said:

wouldn't it be nice if someone made a control that checked for syntax errors in real time as a program was downloaded?

Click to expand...

Syntax checking does not prevent data loss from causing a crash. The following two lines have acceptable syntax, one crashes, the other does not.

G0 Z7.058
G0 Z.058

if your cables are long then slow the BAUD RATE down to like 4800 or 9600...make sure both baud rates are the same...I used 9600 since ours are so long....started out using 4800...any higher and data transfer would suffer....so that's new cable and set baud rates lower than what they are on now...one notch at a time...until no data is lost and that's the rate....capeesh?

Vancbiker said:

Syntax checking does not prevent data loss from causing a crash. The following two lines have acceptable syntax, one crashes, the other does not.

G0 Z7.058
G0 Z.058

Click to expand...

the odds of a rs232 error giving you acceptable syntax are incredibly slim

more likely it would send a line like
G0 Ztrumpisamoron
than perfectly send an acceptable ascii symbol

it is the controls fault

gustafson said:

the odds of a rs232 error giving you acceptable syntax are incredibly slim

more likely it would send a line like
G0 Ztrumpisamoron
than perfectly send an acceptable ascii symbol

it is the controls fault

Click to expand...

That's not been my experience. Usually seen a dropped character. If an address got dropped then syntax checking should catch it. Since there are many times more numeric characters sent, the odds of a lost numeric value are much higher.