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
