There was a discussion on #emc-devel today on how the current toolchanger protocol behaves, and how it could be developed. Let me write up my view to start collecting requirements. This is my ideas only, so if folks have different requirements please throw them in. In particular, I have no experience with random toolchangers.
Problems: - Jeff noted that the current protocol suffers from a potential race condition when tool-change or tool-prepare operations are aborted by EMC. The consequence could be that the external toolchanger, and the iocontrol component have different 'views' about the state of affairs, namely wether the tool was changed, or the change aborted or completed. - while it is now possible to abort change/prepare operations immediately and reliably from the EMC side, there is no obvious way how that should be done from the toolchangers/machine side. A candidate would be E-Stop - I think its unsuited because an aborted toolchange is not the same as an Estop, and it limits the usefulness of the abort: if the abort only can be caused by an Estop through the external toolchanger, this Estop might cause the axes to move, meaning that the program cannot safely be restarted, or run-from-line. Programmatically it is possible to have a toolchanger script to cause an abort by executing emc.command.abort(), but the suitability of the halui.abort pin is a bit questionable (signal goes into a different process, which might cause more synchronization problems downstream). - IMV it is clearly desirable to have a way to cause such abort from the toolchanger, both as a protection measure or as a feature to be able to safely restart-from-line, which I see as a big plus That said, I think requirements include: my must-haves: 1. at any time, the toolchanger and the iocontrol component must have a reliably synchronized view of the the other party's state. 2. The semantics of both EMC-caused and Toolchanger-caused aborts must be clearly defined (pin protocol, effect on EMC, requirements for TC). 3. there needs to be a means for the toolchanger to abort a prepare or change process reliably through HAL pins, and have details conveyed to EMC. 4. an aborted toolchange operation must be idempotent in terms of internal state and restartable without skipping a program line, that is: EMC has not changed tools, and the toolchanger either issued the abort, or got it reliably signaled. A restart of the M6 operation will cause exactly the same sequence of events as a previous run. usability: - reliable state synchronization which also works with external hardware will involve more pins and possibly more internal states. it should be possible to just 'jumper out' unused parts of these synchronization processes, similar to the prepare-loopback mechanism. (this btw rules out bidirectional notify/acknowledge handshake pins because they cannot be jumpered to cause the same effect) so, what's missing or wrong here? -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
