Michael, Please see my interlineated comments (is that a word?)
On 4/12/2012 7:24 AM, Michael Haberler wrote: > Ken, > > you're raising an important point, which would be very useful beyond stepping > back in time for RFL; for instance for MDI-while-paused. > > I'd like to take the opportunity to think loud about this, with the faint > hope that a workable plan emerges. > >> If I had my choice (and a team of programmers who would listen to me and >> do it my way), I would want a system that kept a record of every line >> that was executed. The display would be able to be scrolled backwards to >> select a line. If the line were a subroutine call, it would be possible >> to show just the call (hiding the actual subroutine lines) or to expand >> the call (showing the subroutine lines). >> >> One could then select the line one wished to run from. Of course, when >> displaying this, it would be possible to show the values of all >> registers, subroutine arguments, and other variables as they existed at >> the time of the line execution. > If I understand you correctly this means 'keep a trace of the execution so > you can step backward in time and restart at a previous state' (potentially > with changes to this state before reexecuting). I think this is really the > same thing what John Kasunich called 'backing up the interpreter' here > http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WhyManualWhilePausedIsHard . > > I've been thinking about this on and off and in theory I see two basic > approaches: > > 1. recording state differences between checkpoints (which could be lines) > such that state differences can be rolled back in time. > 2. reexecuting from the beginning of the program and roll forward to the > point where you'd want to make changes (for instance, where you want to > "RFL", or would want to use a bit of MDI and continue). > > now thinking about the viability of these options. > > lets look at 1): Interp state as per _setup currently has some 140+ > variables, including maps, sets and arrays. Plus, there's some implicit state > in canon static variables, the CRC canon queue, and probably some other > places I havent thought of. keeping state differences for all of these so can > roll them back checkpoint by checkpoint is conceivable, but think it will be > very easy to miss an aspect and create mess. It would be cool from a UI > perspective, I admit. I don't think the situation is as grim as you describe it. The reason is that once we develop a general mechanism to do this, adding state variables should be pretty easy. That means we could fix any mess we create. > > now 2): if it were just for a linear program with no queuebusters, it would > be easy - run-to-line and stop because execution is completely predictable. > > Now, queuebusters like reading HAL pins, probe and tool change make execution > non-predictable. However, it occurs to me that recording the state of 'past > queuebusters' is entirely feasible because that affects some very limited > aspect of the state (the HAL pin vector and timeouts, tool geometry, offsets, > the probe trip point). If that is a valid assumption, then rolling forward > would become possible even with queue busters, at relatively low cost. The > queuebuster operations would actually be interesting optional breakpoints, > for instance to correct tool geometry or other past decisions, and continue > with a CRC move (not entirely sure thats possible, but it would be nice to > have). > > Let's call these queuebuster responses 'sync records' for now, so they have a > name. Technically they contain for: > > - probe: trip flag and trip position > - HAL pin read: the vector of pin values, and timeouts or in-time > - tool change: the geometry of the tool post-change. > > I think the fundamental question really is: > > Is it a safe assumption given: > - any conceivable NGC program > - a constant starting state > - a constant sequence of 'sync records' > > that the end state of the program must be identical? > > If the answer to that is yes, the roll-forward approach looks feasible at > relatively little cost compared to 1). > > Let me clarify why the answer to the above question isnt "yes, of course": it > could very well be that parameters like feed override, which eventually may > impact on the path of a machine but are NOT recorded in the interpreter, have > an impact on the values of the sync records. I havent fully thought through > this; my gut feeling is the answer is "yes", but I'm not sure. That's my gut feeling, too. But if we are wrong, we are back to the same sort of mess we would have with approach one. The big thing going for this approach is that there is much less data to record. But quantity of data should not be an issue with modern computers and disk drives. > --- > > I'm leaving out here completely the aspect of checkpointing and restarting > the motion and TP queues, which is a nontrivial issue in itself. Let's think > this through piecemeal. > > I'd be interested to hear any thoughts on this. To me, the question is, how would the user describe what he wants to do. I think the answer is that he "wants to go back to (for example) just before the tool broke". I don't think a user would describe what he wants as skip the parts that worked up until the tool broke and continue from there. Regards, Ken > > - Michael > > -- > > ps: btw, maybe touchoff should become a bona-fide queuebuster operation in > itself. > > > > > > > > > > > > > > > > > > > >> The above takes care of the re-run from line case. The start from line >> case has the extra quirks that probing and other inputs need to be >> simulated or have the values otherwise specified. >> >> I'm sure that all of this is doable. Most of it is not needed by the >> typical user (heck, it's not clear the subroutines are needed by the >> typical user). >> >> Unfortunately, given the nature of open software developed by a mixed >> group of varying interests, it will not be easy to get this done -- >> certainly not in a single step. It might be possible to do this in >> multiple phases, though. >> >> The first phase would be for someone to step up and build the >> interpreter support. After that was done, we wold need someone to make >> the gui work with that support. >> >> One downside of what I have in mind is that it would require >> significantly more CPU resources to implement. That might mean that it >> would run slowly on ten year old computers with 256Meg of memory. Some >> of us might have to upgrade to five year old computers :-). >> >> Thank you taking this on, Michael. I'm sure that whatever changes you >> make will be an improvement. >> >> Regards, >> >> Ken >> >> On 4/9/2012 8:13 AM, Michael Haberler wrote: >>> I've threatened to do this, and since it is slowly moving towards master, I >>> thought I'd reduce the surprise factor by laying out plan and status: >>> >>> The rundown of what it aims to fix: >>> >>> • GUI's will be able to highlight source location wherever it comes from: >>> main.ngc, an oword subroutine, Python code, MDI strings .. >>> • run-from-line should become more bullet-proof. >>> • run-from-line will work on arbitrary conditions, not just line numbers; >>> from locations in subroutines, or depending on variables. >>> • a new 'Run up to here and pause' GUI option similar to RFL should be easy >>> to add. >>> • a call stack display should be easy to do >>> • the Interpreter's handling of O-words can be firmed up substantially, the >>> following statements should cause an error message during parsing: >>> • a 'return' or 'endsub' not within a sub defintion >>> • a label on 'repeat' which is defined elsewhere >>> • a label on 'while' which is defińed elsewhere and not referring to a >>> 'do' >>> • a label on 'if' defined elsewhere >>> • a undefined label on 'else' or 'elseif' >>> • a label on 'else', 'elseif' or 'endif' not pointing to a matching 'if' >>> • a label on 'break' or 'continue' which does not point to a matching >>> 'while' or 'do' >>> • a label on 'endrepeat' or 'endwhile' no referring to a corresponding >>> 'while' or 'repeat' >>> >>> The gory details: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?SourceContext >>> >>> This *will* eventually affect code I dont know very well, mainly the GUI's >>> (note 'affect' != 'break without further changes', or so I hope). >>> >>> >>> I'd appreciate feedback on this. >>> >>> - Michael >>> ------------------------------------------------------------------------------ >>> For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> _______________________________________________ >>> Emc-developers mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/emc-developers >> ------------------------------------------------------------------------------ >> Better than sec? Nothing is better than sec when it comes to >> monitoring Big Data applications. Try Boundary one-second >> resolution app monitoring today. Free. >> http://p.sf.net/sfu/Boundary-dev2dev >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
