[Home]ToolchangerProtocolProposal

LinuxCNCKnowledgeBase | RecentChanges | PageIndex | Preferences | LinuxCNC.org

Difference (from prior minor revision) (major diff, author diff)

Changed: 62c62
* [EMCIO] EMCIO : use iov2 here.
* [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.

Changed: 75c75
The start-change and start-change-ack lines are new. If you dont use that signal in the toolchanger, jumper in HAL as follows:
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):

Changed: 79c79
This feature was requested by skunkworks and helps speed up toolchanges by maximizing parallel operation of toolchanger and spindle change preparation.
This feature was requested by skunkworks and helps speed up toolchanges by maximizing parallel operation of toolchanger and spindle change preparation.

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