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
