[BUG] TOOLCHANGE_ZRAISE behavior change causes messier prints

[DrumClock]

Previously: https://www.youtube.com/watch?v=gH9YIyn2DkQ

Marlin-bugfix-2.0.x 16-7-2020.zip

1. print T0
2. Z axis raise on 2 mm
3. change of tool T1
4. move to the T1 printing position
5. Z axis return on 2 mm

Current: https://www.youtube.com/watch?v=1D9Tc8ZOyaU
Marlin-bugfix-2.0.x ..... from 28-8-2020

1. print T0
2. Z axis raise on 2 mm
3. change of tool T1
4. Z axis return on 2 mm
5. move to the T1 printing position

Current behavior is bad !!!

The material comes out nozzle with moving tool !!!

I didn't make any changes in configuration.h or configuration_adv.h, I just used the latest bugfix-2.0.x
The G-code file is also the same.

[sjasonsmith]

Please attach your Marlin configuration files, as requested by the issue template. Marlin behavior is extremely configurable, and it is very difficult to debug any issue without knowing how the firmware is configured.

[DrumClock]

Hi @sjasonsmith ,
Here are the Marlin configuration files. Configuration.zip
Among other things, these files are also in the link above ( Marlin-bugfix-2.0.x 16-7-2020.zip )

[DrumClock]

Hi,
I tested the latest version of bugfix 2.0.x and it's the same behavior when changing tools.
The previous behavior was definitely lighter for the press, please undo the changes.

1. print T0
2. Z axis raise on 2 mm
3. change of tool T1
4. move to the printing position on tool T1
5. Z axis return on 2 mm
6. print T1

https://www.youtube.com/watch?v=gH9YIyn2DkQ

[DrumClock]

Is anyone solving this?
This GitHub system is a bit strange.
I don't know if anyone is solving it or not or if it is already solved.
There is simply no feedback!

[thisiskeithb]

Keep in mind that all the code here is contributed by unpaid volunteers who work on it in their free time.

I've added a Help Wanted label to hopefully attract attention of someone who has the hardware, interest, and ability to fix/implement the change.

At present, we have nearly 400 feature requests, and nearly 100 bug reports, so some patience is required.

[Quas7]

I am currently on bugfix e817773 and for me on every toolchange (T0->T1, T1->T0) on my single-nozzle setup the Z axis is raised +2mm.
I searched my configs now 3 times for that parameter but after reading this threat, it seems to be hardcoded. ;)

I will try to search through the recent commits to find the actual change in implemenation to role back.

[Quas7]

If someone has time to check as well, I hand selected these commits for the search via 'git log --all --grep=tool'

Date: Fri Aug 7 18:06:25 2020 -0500
Fix Z height after tool change (#18951)

Date: Fri Jan 10 23:12:21 2020 +0100
Prevent Z misaligment on tool change (#16518)

Date: Wed Oct 9 17:48:00 2019 -0700
Fix tool-change move with hotend offset (#15491)

EDIT:
after switching TOOLCHANGE_PARK there is no more Z-raise (of course, my delta first crashed into the ground with one tower but ok...). Brought #18951 into my focus as the change depends on TOOLCHANGE_PARK on the first brief look.
On the other hand, there are also multiple closed issues with TOOLCHANGE_ZRAISE set to '0' and +Z-raises on tool changes. Might be a completely different issue I face here. Will try non-zero value now and check.

EDIT2:
after setting TOOLCHANGE_ZRAISE to 0.5 I now get +0.5 on every toolchange instead of the +2mm.
I removed the Z_AXIS line of the commit #18951, but there is no change of behavior. Seems to be unrelated.

WORKAROUND:
Setting TOOLCHANGE_ZRAISE 0.001 solved my problem and I will now wait for a proper fix from somebody more capable than me.

[DrumClock]

HI, @Quas7
described above does not even correspond to the problem I mentioned.

The problem is in the transfer when changing the tool, not in ZRAISE.
This is best understood in the videos

https://youtu.be/M4hebAvi800

When the tool is changed, the Z axis returns and then moves to the print position for the second tool.
Te is not good, FW from 16-7-2020 did not do this.

For me, ZRAISE is absolutely fine.

[Quas7]

Yes, it seems to be unrelated to your sequence issue.
I also use a delta-printer that might be the reason for this strange behavior.

[DrumClock]

Hi, @thinkyhead
Is anyone working to fix this error?
Even today's bugfix2.0.x didn't solve anything.

This is a serious problem when changing tools.
Thank you.

[sjasonsmith]

One real challenge is that most people don't have multi-tool printers. One of our most active multi-tool contributors has been too busy with other things to do much this year. If one of you is willing to step up to help resolve some multi-tool issues, I'm sure the community would greatly appreciate it!

[DrumClock]

Hi, please modify the "Z raise distance for tool-change" function as follows to return the Z axis:

1. after completing the SWITCHING_NOZZLE or SWITCHING_EXTRUDER function
   ( now it's only for SWITCHING_NOZZLE )

2. only when the print head is in the print position for the tool being replaced
   (as was the case in FW bugfix 2.0x from 16-7-2020 video: https://youtu.be/M4hebAvi800 )

If you need to test adjustments before PR, I'm fully available.

Thank you very much

[Protean-Man]

I have the exact same problem outlined here: #19150

It has been a problem for months now and I also have had zero success fixing it. What I think is it is related to Bed Leveling (AUTO_BED_LEVELING_UBL) and TOOLCHANGE_NO_RETURN.

What I have found is that if I disable Auto Bed Leveling and TOOLCHANGE_NO_RETURN the issue goes away. This is not my goal though because both of those make massive differences in print quality.

I am quite sure that it has to the with TOOLCHANGE_NO_RETURN. The first layer after a tool change is lifted, the subsequent layer (if no tool change occurs) moves to the proper Z height. Then another tool change occurs and the same results occur with the first layer being lifted and any subsequent layer with the same tool not being lifted.

When I turn off TOOLCHANGE_NO_RETURN it doesn't seem to do this, BUT this is useless for me because the way my system is designed, having the carriage return to the TOOL 0 slot after getting TOOL 1 causes a crash and this is why TOOLCHANGE_NO_RETURN is so very important to have on - even as a default.

I also really wish there was a way to edit the sequence of moves during a Tool Change and have them setup per Tool individually.
An example is the extrude after a tool change function is called too late for me. I would prefer to move it to before the tool is removed from it's storage dock. Editing the order and details of each move would change so many things for me and others.

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[sjasonsmith]

Please refer to the close duplicate for newer configuration files and some videos.
#20648

[DrumClock]

Hi, can someone please address this issue?

[DrumClock]

Hi, @sjasonsmith
even today's update bugfix 2.0.x does not solve the problem of a bad tool change procedure.
Can someone please do this so that it is correct as in the release 16.7.2020?

[github-actions]

This issue has had no activity in the last 30 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 7 days.

[DrumClock]

Hi @thisiskeithb

It's been here since 28 Aug 2020 and no fixes.
I'm using old FM from 16-7-2020 which is fine.

Should I leave it open or should I close it?

[Protean-Man]

I would like this to be open until it can be fixed. I have opened other issues related to this problem that have all gone stale and closed without any changes being made. I appreciate all the work the core devs do and want Marlin to push into the future but without a functioning multi-tool backend I can't see Marlin going beyond the base level of printers. If I could fix it myself I would but I am not versed enough in coding for it.

[DrumClock]

Ahoj, už vím kde je pravděpodobně problém.
Marlin ve verzi ze dne 16-7-2020 nedokončil funkci tool change kdy nevrátil osu Z o nastavenou hodnotu.
Toto při tisku zařídil G-code s výškou vrstvy.

Tato "chyba" však byla pro tisk s více extrudery lepší, protože se hlava vrátila na pozici Z až po přejezdu na
tiskovou pozici.

Tím nedocházelo k "otření" vytékajícího filamentu na jném místě.

[DrumClock]

Navrhuji při tisku nevracet osu Z.
Tuto funkci nechat jen když se netiskne .

[thinkyhead]

Duplicate of #19150

[thinkyhead]

Please relocate discussion to #19150.