Lift Z option only works for first extruder

[platsch]

Version

1.2.9-257-g08a2775

Operating system

x86_64 GNU/Linux

Behavior

The Lift Z option always applies for the first extruder (id 0), values for Lift Z and Only lift Z for any other extruder are ignored.
This behaviour is hard-coded in GCodeWriter.cpp:
target_lift = this->config.retract_lift.get_at(0);

Is this a bug or is there any reason I overlooked?

[lordofhyphens]

Suspect that it is a bug.

[lordofhyphens]

I usually don't run into this problem myself as I run only a single extruder and use firmware retraction, which has a lift baked in as an option.
I suspect that it's usually not a problem for most people because the two hotends are close enough in requirements w/r/t z that it's hard to tell the difference as well.

The other thing I can think of though to do it like this is to avoid head crashes, as on switch it would retract, lift for extruder 1, change tools to 2 and then use extruder 2's "lift amount" and restore. I'm not sure offhand how much impact actually fixing that to cover that case (which is pretty important :))

[platsch]

I frequently use multiple extruders. For most plastic extruders this is not a real problem, but it is not exactly user friendly to have an option that only works in special cases.
However, for liquid extruders, i.e. syringe or pressure dispensers the different z offset is actually important. The obvious workaround is to increase the lift for both extruders, but since the plastic extruder often covers the largest share of printing time it is nice to reduce the movements for the slow z-axis as good as possible.

I locally fixed this by providing the correct extruder id to get_at(0) and didn't observe the head-crashing scenario so far. The lift() method stores the lift-distance and restores the old value even after switching the extruder. unlift() doesn't use any config values.

I can submit a pull request for this, but it's a simple replacement of the static extruder id to get_at(this->_extruder->id) in 3 lines.

[lordofhyphens]

Go ahead and make the PR. I would rather you have the credit in the log. We can put some tests together and see if it can be broken as well.

[lordofhyphens]

@alexrj any particular reason lift always did the first extruder or cam this be merged in?

[alranel]

Code-wide it looks fine, and I appreciate the test case.

The reason for always using the first extruder's value was consistency, as the lift behavior during a toolchange is probably undefined (correct me if I'm wrong). The retraction before a toolchange probably still uses the old lift value, doesn't it?
However I think this change is still more useful than the previous behavior so I'll merge it. Thank you for your work.

[platsch]

@alexrj I don't understand the question. The lift behavior is (and always was) generally well defined for toolchanges and works as it should. As I explained, the current lift is stored per extruder and unlifting works in every situation. I think it was only a wrong argument.

How is the retraction affected by the lift?