Mark, one more question occured to me as I'm thinking this through:
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. > > 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. > > 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? so far the M7* codes saved and restored state at the *current* call level, and thus either caller, or callee could protect state by bracketing with a M70/M71 pair at their respective levels. Your M70.1 would implicitly refer to state from a *different* call frame, which means it needs to be clarified wether this to be used at the caller level, or the callee level (tick one box only ;-). In theory I'd see either: o100 sub .. fiddle with state, but no M7* code here o100 endsub M70.1 (magically protect caller context against subroutines fiddling with state - protection by caller) o100 call OR: o100 sub M70.1 (protect caller against any state changes ...fiddle... ... o110 return (causes automatic restore of state) ...fiddle... 0100 endsub (also causes automatic restore of state) o100 call (note callee explicitly protects calling context) I think the latter is the way to go. This implies an M70.1 would be meaningless at the top level because there's nothing 'to return to' or 'endsub from'. I guess that should cause a warning, and have no effect - if you would want to save state at the global level you'd have to use M70. -Michael ------------------------------------------------------------------------------ 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
