Bed leveling/Z probe is allowed with T1 when dual X axis carriage is enabled

[oysteinkrog]

It is possible to execute G28/G29 when T1 is selected and X axis dual carriage mode is enabled.
This is/can be dangerous I think, as at least on my machine the Z probe is on the T0 carriage.
I suggest either auto-switching to T0 (and then switching back when finished) or disallowing Z probing when T1 is selected.

[Alex9779]

This is similar to what I wrote at the end of #4266.
Homing with T1 is also possible with a single carriage and after that positions and software end stops are bricked when switching tools...

[oysteinkrog]

I'm looking at BCN3D's Marlin fork. They implemented both strategies, some of their custom gcodes for calibration wizards etc give an error if attempted when in T1, and some gcodes such as G28 switch to T0 and then switch back afterwards.

[Alex9779]

Ya that would be the ultimate way to save which tool we are on before G28 then set back. But for my use cases I don't see a point for that. I execute G28 on every new print, it would just add some more reliability to switch to T0 when doing G28 because then it doesn't matter which tool was active before, the homing and the coordinate system will be always fine.
I can't image a use case where you have T1 active home and then wanna continue with T1. This is all done by my files I print and before printing I wanna purge and prime all tools involved in the print that follows...

[oysteinkrog]

Auto-switching to T0 and not switching back is probably not ideal though, could confuse slicers etc.

[Alex9779]

Ya if you switch automatically back the user is still responsible to know what the current selected tool is when executing that function.
On an LCD there is no indication at least non that I know. And the ability to switch tools was introduced recently and is not active by default.
So I vote for just the reliable easy way of resetting the tool to T0 when executing G28. That way G28 is something like the reset command before each print and I have the impression it is meant jus as that...

[thinkyhead]

This makes sense. If we opt to switch the tool back after G28 it will have to be a "moveless" tool-switch, because many times after G28 the tool will want to move where it cannot.

[thinkyhead]

#4360 attempts to address the G28 case. If this works, it can be extended to G29 as well.

[Alex9779]

I just have to add that it is sad that BCN3D uses Marlin, identified a problem, fixed it but didn't at least open an issue here to call attention to that issue...

[thinkyhead]

but didn't at least open an issue

It's more common than we would like. I could name some vendors, but it would be a long list, many of whom are people we like and admire. That said, there are a few notable exceptions who like to contribute. My general theory is, most of these vendors hire an intern for a week to "make Marlin work!" and then they never touch Marlin again. I can sort-of understand why some might withhold submitting pull requests, given the pace of changes in Marlin in the last couple of years. So once in a while I go hunting through forks to see if there's anything I can bring in myself.

[jbrazio]

Fixed by #4360

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.