Save/Restore leveling on toolchange for singlenozzle too

[studiodyne]

Related issue #17229

• UBL correction must be frozen during tool change
• For all configurations

Not sure it's the perfect solution , but i have fixed this , with very simple preprocessor line
Need to be evaluated by maintainers

[Roxy-3D]

UBL correction must be frozen during tool change

I don't understand why the bed leveling must be 'frozen' during a tool change? During a tool change, a new tool is moved into position and everything just continues from there. Right?

(I need help to understand this!)

[InsanityAutomation]

Im assuming its hitting the off mesh compensation inconsistency thats long since been discussed. In the past we have talked about setting the UBL defaults to the entire movement area in part because of this with G29P3 filling the off plate points. Ive been using this on a CRX with purge buckets, parking off the plate and running a G12X wipe move for months without any issue.

[InsanityAutomation]

Keep in mind this was added explicitly to avoid a similar issue to whats being described with bilinear. There should be no move at all associated with not changing the state.

[studiodyne]

Hi .... I really enjoy , to see some humans here !!!
As you can see in the PR comment , i have saied , that it's a blind fix , and really need expertise to be evaluated

I don't have enough experience to be sure , but my theory is , that tool change cannot resume Z height if under current z . Then , the bedtemplevelingstate include the amount of ubl in the current pos , and now , toolchange can resume under 'real current z ' because ' fooled ' , and after , the value is updated.

I don't know the history of this issue , but , as you can see in the video , DUAL EXTRUSION printing is totally impossible .

I have a question , why single nozzle disabled , in the branch of bedleveling state .... Singlenozzle or multi toolhead it's the same. In the cfg.h , you can set different z offset , but toolchange will disallow this .... If all the nozzle of the carriage don't have exact same offset and if toolchange allow to raise down the higher nozzle , the object on the build plate will explose and pull off because of the second nozzle too low .
Z height is only possible for DUAL CARRIAGE , or any switching tool

Then , why singlenozzle disabled .... and not all zero offset fixed multiple toolheads

I don't have time to work and to search , all additions and substractions of marlin toolchange , if someone have enough experience to explain this bug , it's ok
Make it

But for the moment , i can print in dual extrusion perfectly
May be other machines have issue with this fix

I don't know

[studiodyne]

@InsanityAutomation do you have SINGLE_NOZZLE enabled with more that one extruder , i can't believe you have the same cfg than me , and no bug
My cfg: Avr/single nozzle/2 extruders/purge bucket out of bed/UBL 9x9

[studiodyne]

@Roxy-3D , really sorry for ' Frozen' , but it's a bad translation of the idea that i would explain

[InsanityAutomation]

Yes, single nozzle 2 extruders on a Creality CR-X - https://github.com/InsanityAutomation/Marlin/tree/CrealityDwin_2.0 Can follow the CRX paths here.

The difference likely comes in that we set the ubl area beyond the travel range, so there is no cross out of the mesh area. Thats been known to cause inconsistent behavior in the past.

Single Nozzle should not have any tool offsets applied. If that somehow got broken and the zoffset is being applied / removed I can see something going awry.

[studiodyne]

Please can you make this , make a gcode file , with 1500 toolchange , that use an usb mesh and upload a firmware without my PR
disable park,init,z height, fan and all M217 v0 w0 z0 s0 e0 f0 , just pure toolchange

and see if toolhead resume perfectly
I can't believe how it's possible two same config don't have same bug

Thks

[thinkyhead]

Im assuming its hitting the off mesh compensation inconsistency thats long since been discussed.

Let's see some logs so we know what we are talking about. I refuse to allow a spiral of speculation and debate with absolutely no data on exhibit.

[thinkyhead]

One thing I can tell you about UBL is that it has some quirks and requires a little extra care when turning on and off and when doing moves.

If I may speculate for a moment… maybe after turning UBL on or off it needs a "move to nowhere" to re-jigger UBL into synchronizing itself with the current position and/or the stepper steps position.

Please consider this in your data collection efforts.