[FeatureRequest]: Automatically calculate new axis limits on a tool change with the given offsets

[benecito]

Is your feature request related to a problem? Please describe.

As discussed in https://forum.duet3d.com/topic/30583/software-limits-prevent-negative-tool-offset-on-idex-printer we still think it would be more reasonable to automatically calculate right axis limits after a tool change based on the offsets stored.
We have a somewhat working solution for now, but as we need to restore positions (also see #807) there is a lot of movement when changing tools. If we use T0 P0 on a tool change to avoid those movements, we can't reach Z0 on some setups.
The whole thing rather feels like a workaround than a solution.

Describe the solution you propose.

Automatically calculate new axis limits on a tool change with the given offsets. Maybe make this optional with an added parameter in the T* command

Describe alternatives you've considered

See above

Provide any additional context or information.

Ex. Photos, mockups, etc.

[dc42]

Please can you describe your machine so that we can see why you want this feature. The M208 limits are the limit of the hear reference point, from which the tool tip offsets are specified. For many (perhaps most) 3D printers, changing the machine X and Y axis limits when the tool X or Y offset changes would be completely the wrong thing to do; and although changing the Zmin limit might be appropriate, changing Zmax would also be completely wrong.

[benecito]

I'm with you that in a lot of cases does not make sense for X and Y but in some cases it also might make sense.
Nevertheless we're only having issues with Zmin.
The machines we are talking about are IDEX machines with two tools sitting on one X carriage but individually driven. The left tool is always tool 0 and our "master" without offsets. Should the right tool sit higher and you want to print with it in the first layer as standard it will not reach Z=0 or Z=0.2mm or so and thus print midair. The other way round this would also allow you to crash tool 1 into the bed if it was longer. We've for now come across this by changing the Zmin value in the tool change files. This in general works, but as we also need to restore positions in a tool change for printing this creates a lot of (unnecessary) movements.
To make tool changes mid print more reliable we call a clean0/1.g macro which again waits for the tool to be heated for cleaning to make sense.
So when switching tools manually it happens that a tool moves all the way across the bed for cleaning, then all the way over agin to restore the position and then to the position it was supposed to go to. In theory you could come across this by setting the tool with the P0 parameter but then T1 can maybe not reach Z0 or what I noticed today and is more frustrating:
If T1 is longer and selected and I start homing (probe mounted to tool 0) we obviously need to select tool 0. To avoid unnecessary movements we do so with T0 P0 which agin results in tool 1's axis limits still being applied to tool 0 and the probe thus not reaching the bed on our second slower probing cycle.

[Braintoe]

@benecito I just stumbled upon this topic since it seems to be something similar to what I am doing once during calibration on my printer (the second hotend will be leveled relative to the first in a second step in my case). But I do not see why it would not work to also apply this during a print for each hotend... Here is what I do, in case it helps:

• during calibration, an updated z axis limit that includes the offset is stored in a separate file
• this limit is then read when booting the printer

Since you have two different offsets for each nozzle, it gets a little mroe complicated, but noch much... In your case, I would

• define a global variable in config.g that you can use
• store the measured offset alone in a macro file with echo >"z_hotend_[number].g" "set global.hotendzoffset="^{var.zcalibvalue}^"", one file for each hotend
• and add a conditional gcode function to each tool changing macro that calls the macro file, calculates the updated value of z with these variables and the current z value available in move.axes[3].machinePosition and then sets the z axis value as needed.

Unless I overlook something, this should have the same effect as your request has.