I thought I'll update you on where I am with my branches related to toolchanging, and what still needs to be done.
All this consists of several different pieces, some of them intended to work together, some are alternatives. - the iocontrolv2 component. This is a midlife booster shot for toolchange through iocontrol. It fixes some issues and provides new options like toolchanger fault communication, but overall it stays in the - somwhat rigid - original framework, which is: all actions during a toolchange are issued by the interpreter, and interpreter and iocontrol(v2) are driven by various inifile options to modify behaviour as needed. This is in master, and I consider it workable. Documentation is still only the wiki page http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ToolchangerProtocolProposal . - the toolchange-in-gcode-by-oword subs part This is an alternative, much more flexible way of defining what happens during a toolchange, and does away with the old, fixed-sequencing, fixed-options approach. Basically 'if you can express it in Gcode, it could become part of the toolchange process for your machine'. this is in master, and I am migrating my machine to it to demonstrate the dogfood salesman eating his own stuff. Documentation is at this point really only the configs/sim/owordm6-ui.ini and related files. It is new code, beware. This is what I believe will be the long-term solution. Note there are still some restrictions with it (see below)- but it's ok to work this code if you can live with these issues for now. - the state save/restore (M7x) branch This would enable subroutines to protect a caller against changes of modal codes. It has been discussed here, and implemented, but not in master. It works, but hasnt seen a lot of usage. Documentation is only in some example gcode files and regression tests at this point. This goes to the core of the interpreter execution model. It isnt that complex, but it does have breakage potential, as cradek already deplored. - the introspection-through-named-parameters branch This will give more introspection capabilites through read-only named parameters, in particular state as reflected by modal settings, and allow even finer grained control over state save/restore than the M7x approach. It's useful in its own right, I think. Not in master. Works ok - it's mundane code without much breakage potential (or so the say). Documentation in progress. The last two pieces are intended to support the toolchange-in-gcode-by-oword but are applicable in general. -- Now the list of open issues. - a really tricky part of exception semantics is how state save/restore should be handled during aborts. See next email message. I think I know how to do this properly now, but I'd appreciate some feedback. There's nothing broken with the current code, but it needs to be improved to make more sense visavis aborts, and be clearly documented. - as always, documentation - I'm working on that. - long term, I think iocontrol(v2) should be deprecated as the toolchange-gcode stuff matures. This implies a major rework of how tooltable i/o is done - it needs to be migrated to the interpreter eventually. It isnt a functional change, but a prerequisite for getting rid of iocontrol. - unrelated to this code, but related to toolchange: M19 spindle orientation. I'm interested in it, but it really shouldnt touch much of the above. That's pretty much the shopping list for now. -Michael Restrictions with the toolchange-in-gcode-by-oword-subs code: ------------------------------------------------------------- 1. Note that the Tx and M6 replacement subroutines are essentially 'spontaneously called' from the interpreter when a Tx/M6 is encountered - think of it as if you wrote "o<t_replacement_sub> call [tool-number] [tool-pocket]" instead of an 'T<toolnumber>', and "o<m6_replacement_sub> call" instead of a 'M6' command. This means that any modal changes in these subs will be reflected in the main program. The M7x save/restore and introspection-through-named-parameters code is designed to help with that, but this isnt in master yet. So currently you need to take care of that yourselves, or at least be aware of it. 2. Since it's gcode it can be aborted by hitting 'escape' in axis, the halui.abort pin and probably others. To enable cleanup if a toolchange is aborted, there's an extra 'abort handler' which is called on *any* abort in EMC, and has a parameter describing the reason. This can be used, among others, to reset HAL pins to a defined state. This is in master, too, and works, but sort of a suprising feature. 3. Surprisingly, the iocontrol component is still around when you use toolchange-in-gcode-by-oword-subs. The reason for this is that all tooltable I/O is concentrated there (for now). ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
