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. 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. --- 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. - 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 >> Emc-developers@lists.sourceforge.net >> 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 > Emc-developers@lists.sourceforge.net > 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
