I don't think the queue-buster changes made it into the state tags branch in master yet. These G-codes and their corresponding canon commands became queue-busters:
- G43 (and G43.x) --> USE_TOOL_LENGTH_OFFSET - G52 / G92 series --> SET_G92_OFFSET - G10 (note G5x commands are not queue busters since the offset values themselves don't change) One hurdle I ran into is that interp still processed the queue-busting command immediately. To make restore-on-abort work as expected, I had to store the current tool and g92 offsets (and the g5x offsets table) in EMC_TASK_STAT, and add some GET_EXTERNAL methods that fetch the values from the task status struct (called during synch() and/or restore_from_tag()). -Rob On Tue, Mar 31, 2020 at 12:42 PM Amit Goradia <[email protected]> wrote: > Hi Rob, > > Can you list all the cannon commands that were made queuebuster's in the > pathpilot code ? > > Are they included in the current state tags branch? > > Thanks for the great work... > > Regards, > > automata > > On Tue, 31 Mar, 2020, 7:51 pm Robert Ellenberg, <[email protected]> wrote: > > > Hi Reinhard, > > > > Thanks for looking into this! I think state tags could solve your issue. > I > > wrote state tags years ago for PathPilot's fork of LinuxCNC to solve > these > > problems: > > > > 1. UI status reflected the "read to" line, not the currently-executing > > line > > 2. When aborting a program, a user would expect the machine to be in > the > > state corresponding to the aborted line (not 10's or 100's of lines > > later) > > > > A state "tag" just captures salient parts of the interp state (e.g. line > > number, commanded feed / spindle speed, various G / M modes) and packs > them > > into a smallish struct. Most outgoing canon commands (including motions, > > tool changes, etc.) are given a state tag when they are added to the > interp > > list. In motion, whenever a new command comes in, the tag gets copied > into > > the motion command. When a motion is executing, the corresponding tag is > > copied into motion's status. If you want to know what the current state > is, > > you look at motion's current tag (if something is executing), or task's > > status. > > > > State tags don't capture all of the interpreter's state, though, because > > they would be huge (work offset values, tool offsets, numbered / named > > parameters). This leads to the following problem: > > > > Some example program: > > ... lines of g-code ... > > N50 G1 X1 Y2 Z3 <-- abort here > > ... more lines ... > > N100 G10 L2 P1 ... > > ... more lines ... > > N200 M5 <-- interp reads ahead to here > > > > Interp reads ahead to N200, but the user aborts at line N50. We can > restore > > the interpreter state from motion's state tag on abort, but the G54 work > > offset is already changed, so the values will be wrong. The solution is > > simple: > > > > 1. state tags must hold any interp state that might change during > > read-ahead > > 2. If some interp state is too big / complex to put in the tag, > commands > > that change it must be queue-busters > > > > For example, PathPilot avoids putting all of the work offsets in the > state > > tag by making commands like G10 a queue-buster. > > > > -Rob > > > > > > On Tue, Mar 31, 2020, 8:50 AM Chris Morley <[email protected]> > > wrote: > > > > > All good Reinhard. > > > > > > You will probably become our new expert :) > > > Statetags needs some investigation - I think pilotpath uses it > > > successfully. > > > I'm not sure if it tags each gcode line or each motion command but i'm > > > sure it could be changed. > > > In the end motion needs know about gcode state for all this to work > > > properly. > > > I'm glad ur interested and motivated! > > > > > > Chris > > > ________________________________ > > > From: Reinhard <[email protected]> > > > Sent: March 31, 2020 12:36 PM > > > To: EMC developers <[email protected]> > > > Subject: Re: [Emc-developers] improve synchronization between backend > and > > > UI > > > > > > Hi Chris > > > > > > > But here is something to muse. > > > > lets take the f code for instance it could be alone or with other > > > commands. > > > > eg. > > > > g1 x 1 f6 > > > > or > > > > f6 > > > > g1 x1 > > > > > > > > So how do you account for that when single stepping? > > > > > > I'm not able to talk about my (possibly) 30th step, before I did the > > first > > > one. > > > I only know the direction, where to go. I have no idea, how many steps > it > > > will > > > take. > > > > > > Reinhard > > > > > > > > > > > > > > > _______________________________________________ > > > 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
