WIP - being edited. Everything below requirements not yet settled except race conditon description. |
Since the V2 Toolchanger is now implemented in the iov2 component, this page mutates into a documentation of iov2. |
For an overview of the current toolchange process, see ToolChange. |
For an overview of the old toolchange process, see ToolChange. |
#handshaked signaling an abort/fault: from emc to toolchanger, and from toolchanger to emc to make sure an abort is reliably signaled in both directions, and optionally cause lock-step behaviour. Handshaking is optional and can be jumpered in HAL if not needed. |
#handshaked signaling an abort/fault: an abort signaled by emc to the toolchanger, and a fault indicated from the toolchanger is handshaked to assure reliable signaling, and optionally force lock-step behaviour. Handshaking is optional and can be jumpered in HAL if not needed. |
** An abort is originated by EMC and will always cause immediate termination of the program, and the interpreter goes into idle mode. An abort is passed on to iocontrol with an assoicated reason code, and will terminate a tool change process under way. It is signalled to the toolchanger together with the reason code. ** A fault is a notification from toolchanger to iocontrol together with a reason code. A toolchanger may fault at any point in time. A fault indication will cause the next M6 to abort. |
** An abort is originated by EMC and will always cause immediate termination of the program. The interpreter goes into idle mode. An abort is passed on to iocontrol with an associated reason code, and will terminate a tool prepare or change process under way. It is signalled to the toolchanger together with the reason code. ** A fault is a notification from toolchanger to iocontrol together with a reason code. A toolchanger may fault at any point in time. A fault indication will cause the next M6 to abort (to be precise, as soon as the start-change pin is about to be raised). |
*emc-abort-ack: BIT,IN: Acknowledge line from toolchanger for previous signal, or jumpered to abort-tool-change if not used in toolchanger. |
*emc-abort-ack: BIT,IN: Acknowledge line from toolchanger for previous signal, or jumpered to abort-tool-change if not used in toolchanger. NB: after signaling an emc-abort, iov2 will block until emc-abort-ack is raised. |
|
*start-change: BIT,OUT: asserted at the very beginning of an M6 operation, before any spindle-off, quill-up, or move-to-toolchange-position oeprations are executed. *start-change-ack: BIT,IN: acknowledgment line for start-change. |
*toolchanger-fault-ack: BIT,OUT: handshake line for above signal. will be set by iocontrol after above fault line True is recognized and deasserted when toolchanger-fault drops. Toolchanger is free to interpret the ack; reading the -ack lines assures fault has been received and acted upon. *toolchanger-reason: S32,IN: convey reason code for toolchanger-originated fault to iocontrol. Usage: UI informational. read during toolchanger-fault True. Negative values will cause an Axis operator display like io fault <toolchanger-reason-code> . |
*toolchanger-fault-ack: BIT,OUT: handshake line for above signal. will be set by iov2 after above fault line True is recognized and deasserted when toolchanger-fault drops. Toolchanger is free to interpret the ack; reading the -ack lines assures fault has been received and acted upon. *toolchanger-reason: S32,IN: convey reason code for toolchanger-originated fault to iov2. Usage: signal wether to continue or abort the program, plus UI informational if negative. Read during toolchanger-fault True. Non-zero values will cause an Axis operator operator message or error message, see below. |
iocontrolv2 design overview |
iocontrolv2 configuration ==INIFILE options === * [EMCIO] PROTOCOL_VERSION : either 1 or 2. Defaults to 2. Setting to 1 will emulate old iocontrol behaviour. * [EMCIO] EMCIO : use iov2 here. You need to explicitly enable the start-change protocol by adding the " -support-start-change" option; otherwise the start-change pin remains low and start-change-ack is ignored. The reason for this is better backwards compatibility. * [TASK] IO_ERROR : printf-style template for operator error display (negative toolchanger fault codes) . No quoting needed. Example: IO_ERROR = Toolchanger fault %d . Default: toolchanger error %d . * [EMC] DEBUG : To get a (quite detailed) trace, set either the RCS debugging flag (0x00000200) in the ini file, section EMC, value DEBUG, or use the new iocontrol debugging bit (0x00001000). The former will turn on RCS debugging messages all over EMC, the latter only for iov2. The state pin reflects iov2's internal state, which is one of: IDLE (0), PREPARING(1), START_CHANGE(2), CHANGING(3), WAITING_FOR_ABORT_ACK(4). HAL wiringSee the wiring example v2_gladevcp_postgui.hal . This connects iocontrol to a 'toolchanger' implemented as a gladevcp panel and shows the usage and current values of all pins. Prepare - related pinsThis is unchanged WRT the old iocontrol behaviour. If you do not need the prepare/prepared signals (for instance, a manual toolchanger), jumper them as follows: net tool-prepare iocontrol.0.tool-prepare iocontrol.0.tool-prepared Start-of-Change indication - related pinsThe start-change and start-change-ack lines are new. If you dont use that signal in the toolchanger, jumper in HAL as follows (this is needed only if the " -support-start-change" option is explicitly given to iov2): net start-change iocontrol.0.start-change iocontrol.0.start-change-ack This feature was requested by skunkworks and helps speed up toolchanges by maximizing parallel operation of toolchanger and spindle change preparation. Change - related pinsEither wire to the toolchanger as with the old iocontrol, or - for instance for simulator mode - wire change and changed pins for immedate change acknowledgement: net tool-change iocontrol.0.tool-change iocontrol.0.tool-changed Communicating EMC-originated aborts and reason codes to the toolchangerIf EMC signals an abort for whatever reason, this is reflected in the emc-abort and emc-reason pins. The toolchanger is expected to acknowledge the emc-abort pin by raising the emc-abort-ack pin - iov2 will block until this is done. If you do not need the abort handshake feature, jumper them as follows: net emc-abort-ack iocontrol.0.emc-abort iocontrol.0.emc-abort-ack The emc-reason pin is considered valid during emc-abort being true. The reason codes are as follows for EMC-internally generated aborts (see emc.hh ca line 321): // types for emcIoAbort?() reasons enum EMC_IO_ABORT_REASON_ENUM { EMC_ABORT_TASK_EXEC_ERROR = 1, EMC_ABORT_AUX_ESTOP = 2, EMC_ABORT_MOTION_OR_IO_RCS_ERROR = 3, EMC_ABORT_TASK_STATE_OFF = 4, EMC_ABORT_TASK_STATE_ESTOP_RESET = 5, EMC_ABORT_TASK_STATE_ESTOP = 6, EMC_ABORT_TASK_STATE_NOT_ON = 7, EMC_ABORT_TASK_ABORT = 8, EMC_ABORT_USER = 100 // user-defined abort codes start here }; iov2 adds one more code, namely EMC_ABORT_BY_TOOLCHANGER_FAULT (101) which is signaled when an M6 aborts due to the toolchanger-faulted pin being true. Communicating a toolchanger fault to EMCTo signal toolchanger faults to EMC, wire the toolchanger-fault pin, and optionally the toolchanger-reason and toolchanger-ack pins. The toolchanger-fault triggers the fault condition, which is reflected in the toolchanger-faulted pin. This condition can be cleared by asserting the toolchanger-clear-fault pin, provided the toolchanger-fault pin is false. The value of the toolchanger-reason pin is used as follows: * toolchanger-reason > 0 : The toolchange process is not completed and the program continues, however parameter #5060 is set to 1.0 to indicate the fault. Parameter #5601 contains the value of the toolchanger-reason pin. * toolchanger-reason = 0 : the program is aborted * toolchanger-reason < 0 : the program is aborted and an operator error message is displayed by using the IO_ERROR template. Other than that, toolchanger-reason underlies no further interpretation. The usage of the toolchanger-fault-ack pin is optional. It will become true when toolchanger-fault is raised and the toolchanger-reason pin has been read by iov2. |
timing diagrams - being reworked |
Test-driving iov2There is a an emc-sim configuration available which uses a gladevcp panel to show what is happening, and exercise every single aspect of the toolchange process. |
run in configs/sim: emc axis-iocontrolv2-demo.ini |
Reason Codes: |
v2_gladevcp_postgui.hal should give a good idea about wiring iocontrolv2. |
Use +/- for abort/fault predefined: aborted by EMC aborted by ESTOP aborted explicitely by User fault caused by no tool in pocket fault caused by invalid pocket number fault caused by tool changer jammed user-defined starting at XXX / -XXX Usage Scenarios ==Backwards compatible (fire & forget) === * jumper abort-tool-change and abort-tool-change-ack lines in halcmd * just connect an old-style toolchanger as you used to Paranoid* connect abort-tool-change and abort-tool-change-ack to corresponding toolchanger inputs * connect toolchanger-notify and toolchanger-notify-ack to corresponding toolchanger outputs * observe 2PC protocol iocontrolv2 -> toolchanger: **monitor tool-*-aborted lines during tool-change and tool-prepare true: TBD |
The race condition in the current iocontrol-based toolchanger : |
The race condition in the old iocontrol-based toolchanger : |
For an overview of the old toolchange process, see ToolChange.
; example fault behaviour: ; prepare tool 42 T42 ; toolchanger gets the prepare number and starts to prepare ; gcode executes ; the toolchanger signals fault to iocontrol ; gcode still executes normally ; change to tool 42 which should have been prepared M6 ; program would abort at this line because of the previous toolchanger fault
Other:
The state pin reflects iov2's internal state, which is one of: IDLE (0), PREPARING(1), START_CHANGE(2), CHANGING(3), WAITING_FOR_ABORT_ACK(4).
net tool-prepare iocontrol.0.tool-prepare iocontrol.0.tool-prepared
net start-change iocontrol.0.start-change iocontrol.0.start-change-ack
This feature was requested by skunkworks and helps speed up toolchanges by maximizing parallel operation of toolchanger and spindle change preparation.
net tool-change iocontrol.0.tool-change iocontrol.0.tool-changed
net emc-abort-ack iocontrol.0.emc-abort iocontrol.0.emc-abort-ackThe emc-reason pin is considered valid during emc-abort being true.
The reason codes are as follows for EMC-internally generated aborts (see emc.hh ca line 321):
// types for emcIoAbort?() reasons enum EMC_IO_ABORT_REASON_ENUM { EMC_ABORT_TASK_EXEC_ERROR = 1, EMC_ABORT_AUX_ESTOP = 2, EMC_ABORT_MOTION_OR_IO_RCS_ERROR = 3, EMC_ABORT_TASK_STATE_OFF = 4, EMC_ABORT_TASK_STATE_ESTOP_RESET = 5, EMC_ABORT_TASK_STATE_ESTOP = 6, EMC_ABORT_TASK_STATE_NOT_ON = 7, EMC_ABORT_TASK_ABORT = 8, EMC_ABORT_USER = 100 // user-defined abort codes start here };
iov2 adds one more code, namely EMC_ABORT_BY_TOOLCHANGER_FAULT (101) which is signaled when an M6 aborts due to the toolchanger-faulted pin being true.
The toolchanger-fault triggers the fault condition, which is reflected in the toolchanger-faulted pin. This condition can be cleared by asserting the toolchanger-clear-fault pin, provided the toolchanger-fault pin is false.
The value of the toolchanger-reason pin is used as follows:
Other than that, toolchanger-reason underlies no further interpretation.
The usage of the toolchanger-fault-ack pin is optional. It will become true when toolchanger-fault is raised and the toolchanger-reason pin has been read by iov2.
run in configs/sim:
emc axis-iocontrolv2-demo.ini
v2_gladevcp_postgui.hal should give a good idea about wiring iocontrolv2.
Let's assume steps 1-6 are identical. Then the operator aborts, e.g. by hitting the Escape key.
Since there is no other signaling mechanism than the tool-change and tool-changed lines, the toolchanger has no way to decide wether the drop of the tool-change line is an acknowledgement of the change, or an abort.