Make switching toolhead compatible with cartesian printers

[DerAndere1]

Description

SWITCHING_TOOLHEAD only worked for printers where the bed moves in z direction.

This PR adds two settings to specify Z positions above- and at the toolhead dock:

// Safe toolchange start Z position.
//#define SAFE_TOOLCHANGE_START_Z           200

and

//#define SWITCHING_TOOLHEAD_Z_POS        100         // (mm) Z position of the toolhead dock.
                                                      // Leave disabled if bed can move in Z direction

In addition, this adds an option to alow toolhead switching mechanisms that work in Z direction (the toolhead is placed onto the dock in Z direction):

//#define SWITCHING_TOOLHEAD_Z_CLEAR       60         // (mm) Minimum distance from dock along Z for unobstructed X axis if the tools are placed onto the dock in Z direction

Note: HOTEND_OFFSET values, set with M218, are the opposite of tool length offsets you would typically set with G10 in other firmware. Thus, tool offset compensation in Marlin works as if G44 is active! This works opposite of the usual G43! So HOTEND_OFFSET corresponds to negative tool lengths. E.g. if tool 0 length is 0mm and tool 1 length is 20 mm, you need #define HOTEND_OFFSET_Z {0, -20} (set via G-code with M218 T1 Z-20)

Requirements

• printer where the toolhead moves in z direction, relative to the frame
• SWITCHING_TOOLHEAD

Benefits

• Makes Switching toolheads compatible with machines that have a bed at constant Z hight and a toolhead that moves in Z direction. Toolhead docks can be mounted on the printbed (for bed-slingers) or on the frame.
• Allows toolhead switching mechanisms where the tool is placed onto the tool dock in Z direction. This corresponds to automatic tool changing spindles used for CNC mills.
• makes SWITCHING_TOOLHEAD compatible with HOTEND_OFFSET: The TOOLCHANGE_*_POS is defined with Extruder 0 (T0) as the reference tool.

Configurations

ToolchangeConfig.zip

Related Issues

#8080

[sjasonsmith]

I was having trouble understanding why it wouldn't work with cartesian printers, but I think I understand now.

• It would have already worked for a Cartesian configuration such as an Ender 5, where the bed moves in the Z direction.
• It would have NOT worked for something like an Ender 3, where the X carriage moves in the Z direction.

If my interpretation above is correct, then it isn't actually related to Cartesian vs. Core XY. It only matters whether the Z axis has to move to reach the parking position.

Can you confirm whether that is correct, or if I am missing something in my understanding?

[DerAndere1]

You are absolutely right

[sjasonsmith]

@DerAndere1 can you describe what the mechanical machine looks like for this? Is this some home-made, or an off-the-shelf mechanism you can provide links to?

I'm trying to picture what type of machine this is designed for, and whether this solution might rely on assumptions that don't work for other designs.

Since you are doing your Z movement at the end, I am picturing something like a CNC router that has a gantry design, where it is actually setting tools down onto holders on the bed.

I can also picture scenarios where a printer might need to move up to a dock. Imagine a Voron-style design where the entire X/Y axis move up and down to a stationary bed.

I don't want to drag this down imagining infinite complexity and variation for it, but seeing what you're work with would help understand the use-case better.

[DerAndere1]

I am trying to make the switching toolhead feature as generic as possible, before actually building the final machine. I test this with a Prusa i3-style printer where I mount the tool dock on the print bed, but this setup is for testing only. I have mainly CNC routers with a moving ganty in mind, where the bed is stationary and the tool dock can be mounted on the base plate, close to the end of the Y axis. This includes machine types like the PrintNC or even machines that resemble a Doosan DVF 5000. Or, as you said, a Voron2. Preferably, the machine has enough space to mount the tool dock next to the printbed, at the end of the Y axis.

[DerAndere1]

@sjasonsmith thanks for the feedback. It promted me to revise this PR to include further changes. This is currently in testing phase.

[DerAndere1]

This is working as intended. However, discussion is needed. I think now is the best time to address the issue that HOTEND_OFFSET corresponds to negative tool length. Marlin's, HOTEND_OFFSET only work for a limited set of Configurations anyway, so currently it seems to be rarely used. We could introduce new settings in Configuration.h named TOOL_OFFSET_X, TOOL_OFFSET_Y, TOOL_OFFSET_Z. Then move HOTEND_OFFSET to Configuration_post.h and define it as follows:

#ifndef HOTEND_OFFSET_Z
  #define HOTEND_OFFSET_Z -(TOOL_OFFSET_Z)
#endif

Then extend G10 to support setting- and reporting of TOOL_OFFSET as defined in the NIST RS274-NGC reference

[sjasonsmith]

I've always pictured HOTEND_OFFSET to be widely used on dual extruders with fixed offsets between two nozzles. This would include SWITCHING_NOZZLE configurations.

Do you know how people are typically handling tool offsets with switching toolheads today? I've worked with traditional CNC machines, so I am familiar with the notion of configurating a tool library and measuring/storing tool lengths, but I have never attempted that type of workflow in Marlin. I don't know whether people are doing this all in their headers, or just sending offset information from their slicers to avoid rebuilding their firmware.

[DerAndere1]

I guess so far SWITCHING_TOOLHEADS was a very specific and obscure feature. With this PR it can be used in much more scenarios, including tool carousels (with minor additions). In my fork I can have a mix of Extruders and non-extruder tools, making the feature even more attractive. In general I suspect that many people try to change nozzles and beds and then struggle with setting the offsets in Marlin. People that have not worked with traditional CNC machines likely rely on features built into the printer's display UI. An official guide that documents best practive is missing for Marlin. So they try whatever is available. This leads to problems or confusing- and manual workflows (babystepping, home offset, G92....). People that know traditional CNC probably see Marlins limitations and just make sure their hardware does not need hotend offsets, or they quickly write their own toolchange algorithm instead of fixing the verrrry confusing existing toolchange.cpp

[alfskaar]

Since there is already one I’m adding my files. :-)

2024 04 26 Voron 2.4 Marlin Hydra tool changer
https://www.youtube.com/watch?v=dxacGMmqg3s

Voron_2.4_Marlin_Hydra_tool_changer.zip
"platformio.ini, Configuration.h, Configuration_adv.h, pins_BTT_OCTOPUS_MAX_EZ.h, tool_change.cpp"

; PrusaSlicer > Filament Settings > Custom G-code > End G-Code:
; Filament-specific end gcode
; END gcode for filament
;
; G28 ; home all axes
G1 Z50 F5000 ; lift nozzle to know Z toolchange position

This is maybe the only missing part I need not sure.

"
Configuration.h
#define SWITCHING_TOOLHEAD_Z_HOP_UNDOCK -0.80

see line 590 in tool_change.cpp
// 3.5 Unload tool and drop it in the dock :Alf06
current_position.z -= SWITCHING_TOOLHEAD_Z_HOP + SWITCHING_TOOLHEAD_Z_HOP_UNDOCK;
DEBUG_POS("(3.5) Raise or lower Z-Axis ", current_position); // current_position= X210.00 Y27.00 Z37.00 : (3.5) Raise or lower Z-Axis
fast_line_to_current(Z_AXIS);
"

[sjasonsmith]

@DerAndere1 I encouraged @alfskaar to post about what they were doing here, since it sounded like they had to work through issues similar to what you are working on. You can evaluate whether it provides any ideas that should be incorporated.

I am wondering if this needs user-defined scripts for the various parts of the tool change, rather than variables capable of addressing every design variation.

[DerAndere1]

Thanks for providing a second implementation, @alfskaar . I think that the solution I propose in this PR is more versatile:

1. My SAFE_TOOLCHANGE_START_Z removes the need for his slicer script that adds a G1 Z... to move to the right Z hight
2. My solution can deal with HOTEND_OFFSET

I am wondering if this needs user-defined scripts for the various parts of the tool change, rather than variables capable of addressing every design variation.

That is why I once added EVENT_GCODE_TOOLCHANGE_T .... But wIth this PR and a future PR I plan to prepare we could support tool carousels for up to 254 tools. Adding EVENT_GCODE_TOOLCHANGE_T ... for each tool would bloat the codesize.

EVENT_GCODE_AFTER_TOOLCHANGE could be much more powerful if we had support for Gcode macros, including branching and variables.