a couple of thoughts... From a software engineering perspective this has been solved many decades ago. It is problems like this which motivated register caching in operating system calls. The first thing that I would try if it were me is to implement a proper context switch as part of the subroutine entrance/exit. Doing this will require that you save some combination of state variables (absolute/relative positioning, etc.) and decide what happens within the subroutine can be exported out. This is basically the same as option 3 below, but automated.
just a thought... EBo -- On Wed, 2 Mar 2011 22:13:56 +0100, Michael Haberler wrote: > a persisting problem with G-code subroutines is the fact that > modifying active G-codes, feeds etc modifies them for the calling > code > too - typical example: probe or tool length offset routines often > switch to relative mode and change feed. Probe routine done - dang, > should we restore absolute mode? what again was the feed? > > IMO it is next to impossible to write G-code subroutines which do > *not* trample on interpreter state, for the simple reason that there > is no way to find out the current state from within the interpreter. > > I see several solutions to this issue, not necessarily disjoint: > > 1. mirror the active codes in named read-only parameters. So we would > have, among other: > #<_g20> and #<_g21> imperial/metric (values 0.0 or 1.0) > #<_g90> and #<_g91> absolute /relative mode > #<_f> - return current feed value > .. > 2. mirror same active codes in a range of #5xxx parameters - less > coding, more arcane, same effect > > 3. provide a, say, M-code to save the current active G/M-codes, feeds > and speeds in the interpreter stack frame, and either restore on > return from subroutine, or explicitely restore with another, say, > M-code. > > > > I am going to do one of these anyway because I'm just too pissed off > not to do it. > > let me know which one you prefer/consider useful. > > -Michael > > > ps: > for an example for 1) - #<_vmajor>, #<_vminor> - see > src/emc/rs274ngc/rs274ngc_pre.cc around lines 718-734 > There many several examples for 2) - like #5070 - probe tripped plus > a ton of others > There is no example for 3) so far. It might be more convenient to > use. > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT > data in > Real-Time with Splunk. Collect, index and harness all the fast moving > IT data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new > business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
