Since the V2 Toolchanger is now implemented in the iov2 component, this page mutates into a documentation of iov2.

For an overview of the old toolchange process, see ToolChange.

Toolchanger I/O protocol - proposed redesign

Requirements for a revised toolchanger protocol

1. EMC-originated abort and toolchanger fault: iocontrol should be able to reliably abort a change operation in progress (tool-change asserted). A toolchanger may at any time signal a fault which will abort the next M6. For instance, a toolchanger finding an empty pocket during a prepare operation should be able to signal a fault to iocontrol, and iocontrol act appropriately when the M6 change operation is executed.
2. communicate abort/fault cause : let iocontrol/EMC know why toolchanger caused an fault, and why iocontrol/EMC aborted. This is for UI purposes. It would be a candidate for a #5xxx parameter, and selective display in the UI.
3. no race conditions between iocontrol and toolchanger: the protocol between iocontrol and toolchanger must be unambigous with respect to which operation is signalled, and if a change operation is aborted or complete.
4. consistent view of state: Both parties must have a consistent view of the state at any point in time with respect to aborted versus completed, and tool number and pocket
5. 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.
6. Backwards compatibility: A toolchanger ignoring the iocontrol emc-abort line and sticking to old handling will "continue to work" (subject to race condition)

Semantics of abort and fault

• Difference between an abort and a fault:
  • 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 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.

• EMC-caused abort during M6 change phase: The result of an aborted tool change shall be: EMC aborts at the M6 line and falls into manual mode. The current tool is still considered loaded (change to new tool was not comitted). The toolchanger shall have the same tool number considered loaded as EMC. This means that the program can be restarted exactly at the M6 line with run-from-line, as this will cause a re-do of the change operation.

• Toolchanger may fault iocontrol at any time: The fault and its reason code is signalled to iocontrol. The next tool change (M6) will fail and abort the program.

 ; 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

Outline of revised Toolchanger protocol operation

HAL lines for iocontrolv2 -> toolchanger protocol support:

• emc-abort: BIT,OUT: signals emc-originated abort to 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.
• emc-reason: S32,OUT : convey cause for EMC-originated abort to toolchanger. Usage: UI informational. Valid during emc-abort True.
• 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.

HAL lines for toolchanger -> iocontrolv2 protocol support:

• toolchanger-fault: BIT,IN: toolchanger signals fault. This line is contionuously monitored. A fault toogles a flag in iocontrol which is reflected in the toolchanger-faulted pin.
• 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: UI informational. Read during toolchanger-fault True. Non-zero values will cause an Axis operator operator message or error message, see below.

Other:

• toolchanger-faulted: BIT,OUT: signals toolchanger-notify line has toggled and toolchanger-reason-code was in the fault range. Next M6 will abort.
• toolchanger-clear-fault: BIT,IN: resets TC fault condition. Deasserts toolchanger-faulted if toolchanger-notify is line False. Usage: UI - e.g. clear fault condition button.
• state: debugging pin reflecting internal state

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.
• [TASK] IO_MSG : printf-style template for operator display (positive toolchanger fault codes) . No quoting needed. Example: IO_MSG = Toolchanger message %d . Default: toolchanger message %d .
• [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), CHANGING(2), WAITING_FOR_ABORT_ACK(3).

HAL wiring

See the wiring example v2_gladevcp_postgui.hal . This connects iocontrol to a 'toolchanger' implemented as a gladevcp panel and shows the usage of all pins.

Prepare - related pins

This 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 pins

The start-change and start-change-ack lines are new. If you dont use that signal in the toolchanger, jumper in HAL as follows:

 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 pins

Either 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 toolchanger

If 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.

NB: emc-abort is only signalled after EMC is out of the initial ESTOP.

Communicating a toolchanger fault to EMC

To signal toolchanger faults to EMC, wire the toolchanger-fault pin, and optionally the toolchanger-reason and toolchanger-ack pins. As stated above, a toolchanger fault will fail the next M6 operation.

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 : An operator display message will be sent using the IO_MESSAGE template described above.
• toolchanger-reason < 0 : An operator error message is displayed by using the IO_ERROR template.
• toolchanger-reason = 0 : Silent - neither message or display.

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.

Test-driving iov2

There 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

v2_gladevcp_postgui.hal should give a good idea about wiring iocontrolv2.

The race condition in the old iocontrol-based toolchanger :

Let's assume steps 1-6 are identical. Then the operator aborts, e.g. by hitting the Escape key.

• (6) The toolchanger completes the change and asserts tool-changed
• (7) The abort causes iocontrol to deassert tool-change. The abort makes EMC think the tool load didnt complete.
• (8) The toolchanger sees the drop in the tool-change and in response deasserts tool-changed.

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.