Hi Chris, On Dienstag, 31. März 2020, 17:29:49 CEST Chris Morley wrote: > >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.
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? > So keeping queue buster to the minimum is a desirable outcome. Yes, but situation for optimization should be reasonable. As I understand things, queue busters stand for: stop optimization here, do a full stop and restart path optimization from queuebuster. Cheers Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
