What really limits DNC operation speed?

This is a sort of generic question but since I am running an OMD based machine it could be a good place to discuss this.

I recently adopted DNC operation. The machining operation is smooth but I see slow operation on the complex parts of 3D cuts. Reading articles on DNC suggests that the machine operating speed can be increased by changing various parts of the system but what is really limiting cutting speed? It seems to me that the hardware of the mill would be the limiting factor since it is mechanical whereas the rest of the system is electronic.

So, we have the movement speed of the mechanics of the mill itself, the rate at which the internal CNC computer can operate, the rate at which we can send the G-code over a serial cable and the speed of the DNC computer. Which of these is the limiting factor in an OMD system and what system improvements could help to speed up 3D cuts?

Any insight would be appreciated.

There is 2 things that may restrict the machine movement

1- transfer speed from PC to the control, your machine could wait for the next lines of code to load into the buffer for execution
2- processing speed of the control of each line of info, so if there is many lines within a very short distance, it would give the impression that the machine is slow

#2 is the problem you may be facing

#2 could also be influenced by tolerance control ( slow down/speed up at each endpoint )

Solution: - avoid point to point programming (use lines & arcs), or at least widen the tolerance between points to suit the machining situation (ie roughing, leaving excess material = wide spacing, larger move segment.......finishing = small segment, bit not too small )

I recently experienced the same problem on my mill with an OM-D control .
I got hold of Fanuc "south africa" and there is nothing we can do about it .
These controls dont have look ahead so ill just have to live with it .
Apparently these were "package" controls .
Im going to try Supermans advice next time i do a hectic part .

could add a 'remote buffer unit' (I think they work on a D control too?) we pulled a bunch off of our 0M-Cs just because we didnt use them... they plug into the ribbon connector on left side of the backplane, if the D has one...

Thanks for the replies.
After some delays my system is working again. NOTE If you change to a DNC computer with an ASUS motherboard that includes a remote serial port be careful. The board connectors on the ASUS board are non-standard and you need a specially wired cable between the motherboard and the rear-panel connector. The ASUS manual does not mention this, it merely says you need a cable that is not included with the MoBo, it does not mention that it is a special cable so I just connected using an off-the-shelf part leading to a day of frustration.

In any case, the new computer is capable of exceeding the max serial input rate of the controller, 19200 baud, so I can test different baud rates. In theory if the baud rate is higher than the controller can handle XON/XOFF should take care of the situation.

I will experiment with the tolerance levels as S'man suggested.

I do not really understand what goes on in the CNC internals. There is an input buffer that given a reasonable data rate inbound I would expect should always be full. At the other end is the output to the mechanical systems. Somewhere in between these two there is a computer of sorts using ladder logic to interpret the G-code and turn it into the output required. The ladder logic itself, being electronic, should be able to calculate far more quickly than the hardware can move so it should be able to always have a queue of data available. Where does this look-ahead buffer that Shottie and tc429 mention live in the chain?.

.

Fanuc only buffers three lines as standard, if point to point even at a slow feed, baudrate wont keep up... The high speed remote buffer unit is a board fanuc sells that plugs into the buss, dunno how fast, but its fast... Theres a option bit required to turn it on too... I dont have the number, but it should be in a zero d description manual if available... All ours were on zeroC models, you can probably find one on ebay cheep, they arent real common, but are out there

Heres one, kinda pricey...contact seller for details, i dunno if this is even the one for a zero...let alone if the D model has the blue ribbon connector on its backplane...
Fanuc A16B 2200 0171 Remote Buffer Board | eBay

according to the 0-series description manual the remote buffer board is A16B–2200–0770
that 0171 board fits a Fanuc 15A

Tried 9200 baud today. Worked fine but no perceptible improvement in cutting speed.
A thought did occur to me, if you feed a higher data rate into a small buffer you are likely to get more XON/XOFF activity than if you slowed the data down. Because of the flow-control activity you may actually get faster buffer operation at lower baud rates than higher ones. Of course, getting the correct baud rate would be critical. Does this make sense?

.

Not really...

a very fast transfer speed would only be needed if the buffer is empty

In normal program execution, a control needs to look ahead for 4 lines for cutter compensation to a programmed path
- a buffer could hold 2000 lines of code, where the DNC "tops up" the buffer as the control executes the code at the other end.

A quick test to confirm this event is to see what line number of code is being sent from the PC, and what line number is being executed in the control
- if there is a big difference ....it is not a DNC transfer problem

-another test is to run the same program section loaded into the control, find the cycle time for both

You will find that the bottleneck is the processing speed of the control ie time to execute 1 line of code when compared to the time it takes to travel the programmed distance

Yes i tend to agree with Superman . I think its the processing speed thats slowing things down .
After looking at a program i did in Bobcad, it seems to break arcs up into a whole bunch of arcs instead of just a single arc .
So in my case the machine would pause briefly between the lines of code when cutting very small arcs , after looking at the program i see that there are about 10 lines of G code for about 5mm of movement on the machine .
When i was looking at the screen of the pc it seems like it sends about 4 or 5 lines at a time so yes the control takes in 5 lines at a time and i dont think there is any reason mechanically to slow it down .
I think it either needs to process faster or look ahead further . My thought anyway .

Hi,
This wholly real, the most effect can be for old CNCs (Fanuc 3,6). We for increase the speed of interpolator have developed the new PCB ROM and have taken away the hardware wait state cycles. This has allowed to enlarge the frequency CPU on 36% and has add the speed calculation for CNC.

translation is difficult.

what CNC versions available (Turning / Milling)?

6TB-2 and 6MB-2 possibly?

what Fanuc version is closest emulated? ('M52', etc version) how many chips in the full set?

will your 6MB-2 version support existing machine options such as 5 axis? what is cost?

is this a full rewrite for series 6 (or just Fanuc firmware modified for no wait state, and overclocked CPU)?

Hi,
Sorry, my english is not very good.
Yes, all versions of Fs6T/M software can be burn in two chips of the PCB. Please, tell me your e-mail, I send you information about my development.

The photo and description for Hight Speed ROM in attachment.