[Home]ToolchangerProtocolProposal

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

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

 ; 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:

HAL lines for toolchanger -> iocontrolv2 protocol support:

Other:

iocontrolv2 configuration

INIFILE options

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 wiring

See 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 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 (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 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.

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.

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.

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 :

upload:tool-prepare-and-change-v1-race-condition.png

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.


LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org
This page is read-only. Follow the BasicSteps to edit pages. | View other revisions
Last edited March 29, 2011 1:09 am by MichaelHaberler (diff)
Search:
Published under a Creative Commons License