Hi Rob, On Tue, 31 Mar, 2020, 10:44 pm Robert Ellenberg, <rwe...@gmail.com> wrote:
> 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 > Did g49 also make this list? I feel that these queuebuster changes should be incorporated into master as soon as possible. This will form the basis of further development in the right direction. Making these changes should not affect the user experience or correct execution of programs. It will only be better when state tags or any such comprehensive work is merged into master. Any opinions on this thought? - automata - 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 <amitgora...@gmail.com> > 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, <rwe...@gmail.com> > 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 <chrisinnana...@hotmail.com > > > > > 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 <reinha...@schwarzrot-design.de> > > > > Sent: March 31, 2020 12:36 PM > > > > To: EMC developers <emc-developers@lists.sourceforge.net> > > > > 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 > > > > Emc-developers@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > > > > _______________________________________________ > > > Emc-developers mailing list > > > Emc-developers@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > > > > _______________________________________________ > > Emc-developers mailing list > > Emc-developers@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-developers > > > > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
