further to the recent discussion on #emc-devel on tool-change-as-g-code-sub, I think that's an idea very worth following. So I assumed that the Tx and M6 commands are now mapped to O-word subs, and tried to emulate current iocontrol behaviour in g-code; to see how that would look and feel, and which problems arise.
This is what I arrived at. I probably violated a dozen of assumptions and preconditions, so bear with me. Obvious problems were: - accessing the *next* tools number and pocket number in O<T>- probably needs to be a parameter to the T sub as well. #5400 refers to the *current* tool number. Problems when extending this for new functionality, and fixing the race condition: - if one were to extend O<M6> to check an hypothetical tool-change-abort pin, the sub would need to self-abort. How? an M2? - I dont see how an EMC-originated abort could be communicated to the toolchanger. A possible solution would be to introduce a O<abort> sub, which is called whenever EMC executes an abort (really an event callback in G-code. Is that an anywhere realistic idea? a bit generalized it could address many problems.) - motion during toolchange. Under which conditions is it safe to wiggle halui pins and/or do a probe? Is it ok if g-code checked a jog or pin and did a G0<wherever> or g38.X respectively? ; T<toolnumber> command in G-code ; a design mockup. Try to emulate current iocontrol behaviour in G-code. ; ; pin assignments: ; tool-prep-number: analog output pin #0 ; tool-prep-number: analog output pin #1 ; tool-prepare: digital output pin #0 ; tool-prepared: digital input #0 ; ; Tx would be called with the next toolnumber as parameter O<T> sub #<tool-prep-number> = #1 ; how would I get at tool-prep-pocket here? ; assume its a parameter for now. #<tool-prep-pocket> = #2 ; set tool-prep-number M68 EO Q#<tool-prep-number> ; set tool-prep-pocket M68 E1 Q#<tool-prep-pocket> ; raise tool-prepare to signal numbers are valid ; does this have to be 'synchronized with motion'? I dont think so M64 P0 ; wait for tool-prepared pin to rise M66 P0 L1 ; ; now that tool-prepared was raised, deassert tool-prepare M65 P0 O<T> endsub ; M6-in-gcode ; pin assignments: ; tool-change: digital output pin #1 ; tool-changed: digital input #1 ; tool-number: analog output pin #2 ; O<m6> sub #<tool-number> = #5400 ; correct? ; set tool-number pin M68 E2 Q#<tool-number> ; assert tool-change M64 P1 ; wait for tool-changed M66 P1 L1 ; could busy-wait loop here and check a hypothetical tool-change-abort pin ; Q: how does a G-code program commit suicide? M2? ; O<m6> endsub m2 anywhere realistic yet? -Michael ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
