Chris, unfortunately G10 doesn't send any "motion" commands, it directly changes the work offsets in interp (where they live), and if the changed offset is active, sends canon commands to update the current offset values. Those commands never make it to motion. Canon is basically synchronized with interp, but task and motion lag behind.
As you said, the offset values are predictable at readahead time, in canon / interp. From motion's perspective though, it's NOT predictable what the offset values are, because there's no information in the command / tag other than the offset number. Motion itself doesn't care about this since it doesn't need to know what the offsets are (all commands have already been converted to absolute positions). However, it matters when you try to rewind the interpreter on abort to match the state it was at the aborted line. To properly restore the interpreter, all of its state has to either be constant during readahead, or the change captured in the state tag. Making G10 a queue-buster keeps the offset values constant during a particular read-ahead. >From motion's perspective, I think there are two ways interp state can be "unpredictable" (or maybe not fully determined?): 1. State unpredictable due to physical interactions (e.g. probe, toolchange) 2. State unpredictable due to implementation choices (e.g. state tags not carrying the full offset table) I think treating G10 and similar as queue busters fits the predictability paradigm if we think in terms of motion. -Rob On Tue, Mar 31, 2020 at 2:39 PM Chris Morley <[email protected]> wrote: > 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 > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
