Re: G-code processing speed
hello doc
Is this still a problem with more modern control?
yes, unfortunately it is ...
Do they intentionally slow down G-code processing speed?
yup, the slower the processing speed, the more expensive the cnc; each new okuma machine is really slow, and it comes with a little fat ninja squeezed inside the electrical cabinet
Is there any way to get around this problem?
maybe ...
do you use :
... G10* XCZ, *=1, 2 or 3 ?, or
... G01 XCZ ( in this case, feed value will not be constant, and a bit of math is required; a wrong feed value may lead to downtime )
...... what code syntax do you use ?
also toolpath discretization may lead to cnc succumb, thus if small segments are used, than the cnc won't be able to reach the programmed feed, and downtime will appear
if segments are normal ( thus the cnc can reach and maintain the programmed feed ) and if feed is too high, some "round corners" may appear : for example, if you wish to turn a square with sharp corners, is better to use a lower feed; using a high feed may lead to round corners ( the rounding may not be simetrical, like a round chamfer )
write 1-2..4 lines of CXZ feed, and use a tick-tock timer to check the duration of those feed lines; real duration should be close to expected duration; if this happens, than your code syntax is ok now you may reduce the length of the segment, and check times again ... at some point, you will encounter cnc succumb ( real time > expected time ); now you may reduce feed, and check the times again ( difference between "real" and "expected" duration should reduce )
have you done such tests ? so to determine the "succumb" zone ? kindly
Ladyhawke - My Delirium, https://www.youtube.com/watch?v=X_bFO1SNRZg