Making the most of limitations of Fanuc based Doosans

[rx8pilot]

Hello rx8pilot,
In practical workshop terms, cable length has Zero effect on data transfer speed. The standard is based on a baud rate of 19,200 and a cable length that is equal to a capacitance of 2500 pF. Further, the standard uses a typical capacitance of 50 pF/ft. Therefore, under the standard, the maximum cable length at 19200 baud rate is 50ft. Accordingly, by using a cable with low capacitance allows you to span longer distances without going beyond the limitations of the standard. When errors occur through exceeding these limitations, they present as dropped characters and not as a reduction in data transfer rate.

If the baud rate is reduced from 19,200, the maximum cable length increases dramatically.

The time taken to transfer a file from external device to a Fanuc Control (or other well established control), is hardly ever caused by the control (I would even say never), hence my comment in Post #7. Normally, delays at the end of each Block and or after each Character, are only available when sending a file from the external device, not when receiving. This is to provide a clumsy workaround for an inefficient UART of the device and more so when using Software Handshaking. Fanuc P/S087 error is caused by the UART of the Sending Device not reacting quickly enough when a Stop Signal (Software, or Hardware) is received. By introducing a delay, the UART has more time to react, but the result is to slow the overall time to transfer the file.

Regards,

Bill

It is true that cable length does not impact the clock rate in any way, but as it gets longer the propensity for errors requiring retries increases. Capacitance is one parasitic element that limits the rise time and thereby limiting practical cable length. Another critical consideration as cable length increases is the tendency for the single-ended signaling to couple noise from all sorts of sources. Even if the cable capacitance is extremely low, you still have to contend with noise. Depending on how the system is set up, errors will either stop the transfer or require resending data - either way it slows things down.

In the bizarre world of Fanuc where they think maximum 19,200 baud is acceptable [in 2007], cable length can be rather long. Before my upgrades, the setup had 100ft cables that seem to tolerate 19,200 just fine [at least after I found the delay parameter of course :-)]

I clearly recall buying my first CNC in 2006. An entry-level machine from an entry-level manufacturer - Haas TM2. It would run serial at 115,200 with a 1MEG of program space standard. Even with 500k programs, the transfer time was insignificant. I am now dealing with high-end machines that have a fraction of the communications performance.

 

[macgyver]

I am glad you figured out what was going on. We had similar problems at my old job with a Fanuc OM, took forever to load a 49k file and also was terrible when drip feeding a program, I trusted that the boss at the time had done everything possible to maximize performance on the download time etc. Fast forward a few years and I was in charge and we were doing alot of surfacing jobs, we had to break programs on to bite size bits etc. So, I got rid of it for a new machine partly because of the program size limits.

Another fast forward, I have my own machine now and I ended up buying a match to the old one with the OM on it. I now had more motivation to figure out the drip feed performance and file loading time. To be honest, it didn't take much. I am running a free dnc program and I set it to match the OM, got a new 25 ft cable made up for me and it works very well. I am sure max for me is 9600, but it loads files in a short time and it will drip feed without any problems at all. I honestly don't know what was wrong at my old job, but I wish I had spent the time to figure it out as I do a good amount of work now that is well over the 49k memory and I have no trouble.

I do know that at the time, neither the boss nor I was on this forum or anything like it, we were basing everything off what the MTB was telling us. I got the software and all the proper settings off this forum, I think without it, I'd be struggling like we did before.

 

[rx8pilot]

I am glad you figured out what was going on. We had similar problems at my old job with a Fanuc OM, took forever to load a 49k file and also was terrible when drip feeding a program, I trusted that the boss at the time had done everything possible to maximize performance on the download time etc. Fast forward a few years and I was in charge and we were doing alot of surfacing jobs, we had to break programs on to bite size bits etc. So, I got rid of it for a new machine partly because of the program size limits.

Another fast forward, I have my own machine now and I ended up buying a match to the old one with the OM on it. I now had more motivation to figure out the drip feed performance and file loading time. To be honest, it didn't take much. I am running a free dnc program and I set it to match the OM, got a new 25 ft cable made up for me and it works very well. I am sure max for me is 9600, but it loads files in a short time and it will drip feed without any problems at all. I honestly don't know what was wrong at my old job, but I wish I had spent the time to figure it out as I do a good amount of work now that is well over the 49k memory and I have no trouble.

I do know that at the time, neither the boss nor I was on this forum or anything like it, we were basing everything off what the MTB was telling us. I got the software and all the proper settings off this forum, I think without it, I'd be struggling like we did before.

For sure - this has been bugging me for the 6 months I have been managing this shop. I believe this system has been in place for 10+ years which is a LOT of wasted time. @Vancbiker's suggestion to look for a delay parameter was ultimately the ticket for the Cimco software. That is the power of having a group discussion. Rather thankful on this end.

I just purchased a few licenses of the DNC4U software and the IT dept is installing the PC's, getting them connected to the network and all is looking well for this communications upgrade.

As an example - the last part I programmed and setup was on the 7 axis mill/turn machine. The transfers were 9-12minutes at a time - now reduced to 90 seconds. To get all the way to a production ready setup - I had transferred variants of the program about 20 times. Most parts are not so challenging, but that is around 3 hours of program loading time saved. With the PC's right next to the machines - the machinist also saves the time needed to go back and forth to the programming office to manage transfers.

Lean and mean.

 

[Vancbiker]

......@Vancbiker's suggestion to look for a delay parameter was ultimately the ticket for the Cimco software........

Here is something to maybe consider...

Adding a line delay is a common rookie technique to overcome handshaking troubles. Since there was a 50mS delay set, I can't help but wonder if someone purposely set it that way to "fix" a problem. Before adopting your new setting universally, I would advise doing some thorough testing to ensure there are no handshaking issues or data loss.

 

[rx8pilot]

Here is something to maybe consider...

Adding a line delay is a common rookie technique to overcome handshaking troubles. Since there was a 50mS delay set, I can't help but wonder if someone purposely set it that way to "fix" a problem. Before adopting your new setting universally, I would advise doing some thorough testing to ensure there are no handshaking issues or data loss.

No doubt about it, thank you.

I am making all new cables. The RS232 distance is about 2 feet or so per machine. Last week I wrangled our Director of Engineering (Electrical Engineering)and he was thrilled to participate just because he is fascinated by machining. So we made sure we got the physical layer all worked out and then I brought in my protocol analyzer built into my Keysight MSOX6004A scope. I was able to see the bipolar analog as well as real-time decoding and error based triggering. Overkill? Perhaps....but this system will be vetted to full aerospace standards just for fun, lol.

 

[angelw]

It is true that cable length does not impact the clock rate in any way, but as it gets longer the propensity for errors requiring retries increases.

Unlike XModem (available with HAAS, not available with Fanuc), where a Check Sum is performed, there are no retries. If there is an error, such as dropped characters, framing errors, or others, that's it; finished. The Fanuc control doesn't know what is being sent to it and there is no communication back to the sending device, other than Handshaking. Therefore, you can have a cable as long as you like and the time taken to transfer a file will not be impacted, only errors caused through the drop in voltage as the length exceeds the limitation of the standard and the consequential loss of characters, or handshaking.

You will get all sorts of errors when the cable length exceeds limits and starts to take effect. Dropped data characters, Handshake related errors when DC1/DC3 (Xon Xoff respectively) characters are dropped; these are transmitted in the same way and along the same data lines as any other character, the only difference is that they are handled by the UART and not the Comms Software. Framing errors when Start and Stop Bits are missing. But no increase in the time taken to transfer a file.

Regards,

Bill

 

[EndlessWaltz]

Just cough* bought a compact flash adapter set from amazon. Using cimco and figuring out to change #20 bit at control and off to the races. I have very simple simple simple lathe programs though. But frees up space to load in a larger program at a point I need it.

Good info here though all around in regards to cable length etc. I do understand the frustration as well with shops not realizing they can update things while literally asking Siri something on a phone...when cell phones didn't exist when they may have bought there last cnc.

 

[rx8pilot]

Unlike XModem (available with HAAS, not available with Fanuc), where a Check Sum is performed, there are no retries. If there is an error, such as dropped characters, framing errors, or others, that's it; finished. The Fanuc control doesn't know what is being sent to it and there is no communication back to the sending device, other than Handshaking. Therefore, you can have a cable as long as you like and the time taken to transfer a file will not be impacted, only errors caused through the drop in voltage as the length exceeds the limitation of the standard and the consequential loss of characters, or handshaking.

You will get all sorts of errors when the cable length exceeds limits and starts to take effect. Dropped data characters, Handshake related errors when DC1/DC3 (Xon Xoff respectively) characters are dropped; these are transmitted in the same way and along the same data lines as any other character, the only difference is that they are handled by the UART and not the Comms Software. Framing errors when Start and Stop Bits are missing. But no increase in the time taken to transfer a file.

Regards,

Bill

Bill - totally correct. It seems like a bizarre design oversight in my view. In a situation with RS232 communication errors, you have to count on luck that the error is severe enough to alarm the machine or totally halt communications in some way. If an error is minor, it could conceivably change a critical value that results in an unexpected motion. I can understand that machines from the 80's may not have an error correction scheme [even though every single computer modem of the day had been doing it for decades already]. For machines built in 2007, there is simply no valid excuse for the ultra-simple communications on such a critical piece of equipment. In 2007 tech/pricing the choice to leave out any error correction [even the ancient ones like XMODEM]and a UART/FIFO/BUFFER that can handle 115,200 baud saved FANUC pennies.