lets talk g10 L2 it shifts the origin to what ever you ask it to. when rs274 interpreters that it sends a motion command to shift (change if you like)the origin. When motion gets the command that is when the origin is changed - so it is synced..
How is changing the origin not give a predictable answer? and if it does then you don't have to stop the filling the queue. the interpreter knows the origin changed and makes all it commands based on that. Motion will know when it gets the motion command to change the origin. I can probably figure out a way to break though rules using HAL pins to enter data into G10, if that can be done. That could certainly be a queue busting situation. But if you are doing that they you are probably doing something wrong anyways - remap would be the way and in remap you can set it as a queue buster (AFAIK) G43 yes you probably could screw that up with a g10 l10 in the wrong place. But again I used those for example for the concept that queue busters are not a free lunch to add willy nilly :) But pilotpath sets these as queue busters and it's seems to be working fine for them... Chris ________________________________ From: Amit Goradia <[email protected]> Sent: March 31, 2020 5:43 PM To: EMC developers <[email protected]> Subject: Re: [Emc-developers] improve synchronization between backend and UI On Tue, 31 Mar, 2020, 9:43 pm Chris Morley, <[email protected]> wrote: > > 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. > Chris, G10 does not shift the origin only, it changes the offset value. This change needs to be synchronised between rs274 and task and motion. G5x applies the origin shift. 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. > G43 is generally applied behind a txx my which is a queue buster. Also g43.x gets the offset value dynamically. So it should be a queue buster as only rs274 has access to that value. Same for g92. Anything that gets dynamic values from the NGC program or elsewhere should be a queue buster like g38.1 automata > > 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 > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
