Am 08.03.2011 um 01:37 schrieb Mark: > You speak of restoring global state. Do you mean the stack will be limited to > depth 1? This will prevent the use of M70 in nested subroutines.
Mark, no, the state stack is actually the subroutine call stack extended to hold the state, it's intended specifically to work with nested subroutines - meaning at each call level, including global, there's one separate slot for state available. Example: o100 sub m70 (context stored in slot at call level 1) ..fiddle with state... m71 (context restored from slot at call level 1) o100 endsub (global) m70 (context stored at call level 0) o100 call ...fiddle with state... m71 (context restored from slot at call level 0) (while it' possible to save/restore state before and in a call, it might be a bit of an overkill) > Should it be an error for the subroutine use M70 and to end without using > M71? IMO yes, but others here know gcode far better than I. At least, M70 without ending with an M71 doesnt make a whole lot of sense because it's a no-op, so that probably should cause a warning. On the other hand, I felt that always force-restoring state by an implicit M71 is a bit heavy-handed. It does restore ALL state held in active_m_codes, active_g_codes, and active_settings, and this might have surprising side effects: Assume spindle is on, you call a sub, store state, turn spindle off, then restore state and return - this will turn the spindle back on without an M3 or M4 explicitely issued! btw this is the reason why I came up with the named parameters patch for state which Chris just merged - to give finer control of what to save/restore in case M70/M71 is too coarse. The alternative to M70/M71 is to remember each state aspect to be preserved (e.g. absolute mode, speed, feed etc) explicitely in a variable in the sub, and just restore that as needed. > If that will cause an error, what about an M70.1 that causes state to be > restored upon encountering either M71 or the end of the subroutine? your M70.1 suggestion is an interesting idea I had'nt thought of I think it makes it easier to use in case there are multiple returns from a sub; forgetting an M71 might be a hard-to-track error I see a few open questions: - assume you do an M71.1 at the global level. The gcode program ends. Should state be restored in this case? I'm unsure; maybe a warning about using M70.1 at the global level should be issued; the other option is to restore state at M2. - assume you issued an M71.1 at the global level, and the program is aborted for some reason, like an Escape key hit in Axis, or the halui.abort pin. It's kind of like an exception which unwinds the call stack. What should be done? options are: a) do nothing b) only restore the state saved at the global level if any c) simulate a sequence of returns through all levels, restoring in turn whatever valid state was preserved is found at that level My guess would be: use b) if there was a M70 at the global level, else c) I like it - I'll see how I can do it It would need to be something like M73 - the 'decimal notation' (like g17.1) is only available for G-codes, not M-codes. -Michael > > > Mark > > > On Wed, Mar 2, 2011 at 5:39 PM, Michael Haberler <[email protected]> wrote: > Ebo - > > I agree pushing the state (for the purpose of this discussion "the stuff > which can be seen in the 'Active G-Codes' window in Axis") into an extended > stack frame, and restoring that on exit would be a natural paradigm - state > would become an implicitely local set of variables > > ... ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
