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
