>From my way of thinking, readahead of the interpreter is fine, as long as it >does not affect the state of the machine (and fixture settings is machine >property). The interpreter may only prepare all stuff for the task executor, >but as with current f-word behaviour, it is completely wrong, changing values >that motion or others will rely on.
In principle queue busters are code that you can't predict the answer to. for instance probing is a queue buster because you don't know when the probe will trip. G10 and tool changes are not real queue busters - the answer is predictable. As Rob said they did it so they don't have to pass a huge amount of data around. A reasonable compromise. Queue busters stall motion, so if you are machining very small moves you want to stock pile as many motion commands as needed to keep the machine moving smoothly. So keeping queue buster to the minimum is a desirable outcome. Chris _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
