I don't follow your reasoning of G10 being a queue buster. it shifts the origin - completely predictable. it will happen at the right time when it gets to the motion side of linuxcnc.
Tool changes - if you stop linuxcnc to jog then you are not running in auto mode any more. You can't pause and jog in linuxcnc currently, without using hacks to works around the motion component. And of course these decisions must be made for the best compromise, my point was that the are reasons to keep queue busters to a minimum. Chris ________________________________ > > G10 and tool changes are not real queue busters - the answer is predictable. Well, here I disagree completely! G10 L1, G10 L10, G10 L11, G10 L2 are all queue busters, or at least should be. Changes of fixture tables should stop readahead, so any location that uses that fixture table will change location. Even if that might be predictable, if it is executed at the wrong time, all result will be rubbish. You have to distinct between setup of a fixture offsets (which usually happens in MDI-mode) and moving an actual active fixture to another location (I guess G10 L20 will be this one - so it is the only one, that might be not a queue buster), which might be part of the gcode file. For me, toolchange is of cause a queue buster. No question! Even if you use manually tool changes, you need to jog the tool away from workpiece, change the tool, apply new tool settings and narrow the tool tip to the location it was before. Only with atc this can be automated. And even with atc it makes absolutely no sense, optimize the path from before tool change with the path from after tool change - so what is the sense of making tool change not a queue buster? _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
