Feature request: Mark tool change as failed

[khenderick]

Hardware setup

On my toolchanger setup, I have microswitches on the toolhead and on all docks. This allows me to check various conditions before (or during or after) the attempt to pick up or dock a tool (Is there currently a tool on the toolhead? Is the wanted tool in the dock? Is the tool on the toolhead? ...).

Problem

I can abort the tprex.g, but RRF still assumed the tool as active. Similar for the other tool-change scripts.

Expectations

RRF should understand a tool change failure and allow correct future behaviour.

Possible solution

• Introduce a general "unknown" tool state. When the system is in this state, RRF does not know whether a tool is docked or not, and has no clue on how to continue. All subsequent tool-change related commands will fail.
• Introduce new g-codes:
  • Mark a tool as active Edit: Tx P0 can be used, see comments below
  • Mark a tool as inactive Edit: T-1 P0 can be used, see comments below
  • Mark general tool state as unknown
• When the tool-change related script
  • Finishes without explicitly calling one of the above g-codes; success is assumed and the tool states are as would be expected for the respective script
  • Is aborted without calling one of the above g-codes; mark the general tool state as unknown
  • Finishes or is aborted but one of the above g-codes was called; assume the tool states are now correct, and the system can act accordingly.

This would allow:

• Detect pre-requisites and ignore the attempt. For example during tpre0.g it seems T0 is not at its dock. T0 is marked as inactive and the script is aborted.
• Detect something is going wrong during a tool pickup. For example, when the toolhead moves to the tool, detects the tool, locks and moves back, it suddenly fails to detect the tool on the toolhead. This could indicate the locking failed. The script is aborted (with or without explicitly marking the general tool state as unknown - as this is optional). As the tool might be somewhere between dock and toolhead, future tool-changes are blocked.
• ...

[Diamondback2010]

I am in a similar position and would like to see something like this as well. Currently I literally forcefully shut down the printer when I detect an non working toolchange.

[jaysuk]

as a work around, when you abort you could also run T-1 P0 which would unload the tool but not run the tool change scripts

[khenderick]

That actually worked great and solves most of the problems I mentioned, thanks.

Updated my initial feature request mentioning these commands. I'll nevertheless leave the ticket open as a request for making/adding a general "unknown" state, as this might still be a valid option.

[T3P3]

the solution to this should be considered as part of the work to resolve:
#949