PR: Enable multiple z_thermal_adjust sections

[garethky]

This came up when developing load cell based probing but I believe its also works with any kind of nozzle probe, e.g. Voron Tap. There is a thread on the Discourse here

The Problem

Probing temperatures are limited based a couple of factors: The glass transition temp of the filament and the melting temperature of the bed surface. So probing is carried out at about 140-160C. Printing temps for PETG might be 290C. So there is, potentially a 150C temperature increase between probing and printing.

Investigations on my printer shows that the rate of thermal expansion for the nozzle is -0.000465mm per degree C. Over 150C that is 0.069mm / 69 microns or about 35% of the thickness of a first layer. The general result of this is first layers that are too low.

Proposed Solution

• Extend z_thermal_adjust to support compensating for multiple components in the printer. So the Frame and the Nozzle can be compensated and the machine can adapt enclosed open conditions.

Example Config:

[z_thermal_adjust nozzle]
temp_coeff: -0.00046459
sensor_type: temperature_combined
sensor_list: extruder
combination_method: max
min_temp: 0
max_temp: 400
maximum_deviation: 1
max_z_adjustment: 0.5

[z_thermal_adjust frame]
gcode_id: ZFARME
temp_coeff: 0.0088
sensor_type: Generic 3950
sensor_pin: T1
min_temp: 0
max_temp: 120
max_z_adjustment: 1.0

I've been testing this in conjunction with load cell probing and the results have been very encouraging. The effect is temperature dependent and easy to measure. A GCode script can measure the nozzle length via probing over a range of temperatures and then produce the thermal coefficient through linear regression. I probed the aluminum bed surface directly with a clean nozzle and no filament loaded. For PCB beds you might have to put a steel surface on top, like the uncoated side of a steel sheet.

The real test is comparing first layers of materials at different temps. I've been testing swapping between PLA and PETG. With other variables removed (keeping the door open, using the same print surface) this lets me swap filaments and get very similar results between them.

Using a macro to record the nozzle length over a temperature range and derive the expansion coefficient through linear regression yields a plot like this:

[KevinOConnor]

Thanks. I'm not sure I'm a good reviewer for this. @alchemyEngine - do you have any comments?

-Kevin

[alchemyEngine]

Hi all, sorry for the delay on my end.

@garethky Really cool feature! Thank you for this, I think this functionality would be extremely beneficial to those using nozzle probes.

Using a macro to record the nozzle length over a temperature range and derive the expansion coefficient through linear regression yields a plot like this:

I find the measurement pattern really interesting here, with one consistently lower than the other. Looks like the nozzle is cooling slightly while contacting the aluminum bed?

On a higher level, I'm not sure if this fits in with the intended functionality of the z_thermal_adjust module: print time continuous adjustment of the Z coordinate space. If I understand correctly, this is only utilized during probing to dynamically adjust the probe offset, and as such would be better suited to piggybacking on the probe code, or as a dedicated module.

In summary I think their functionality is largely unrelated, and as such I don't think it would be wise to link their code. I'm open to discussion, however.

[garethky]

I find the measurement pattern really interesting here, with one consistently lower than the other. Looks like the nozzle is cooling slightly while contacting the aluminum bed?

The lower ones were taken as the nozzle heated up, the higher ones as it cooled down. I read this as the time delay required to get the nozzle and the heatbreak temp to stabilize. Its just longer than the 1 minute that I waited when I collected the dataset. But linear regression across both should give a better result.

If I understand correctly, this is only utilized during probing to dynamically adjust the probe offset, and as such would be better suited to piggybacking on the probe code, or as a dedicated module.

So the way I'm using this is, I set the zero the reference temp at the start of the bed mesh. The bed mesh is captured at a lower temp, 140C to 190C. Then the nozzle heats up to printing temp for the print. At that time, print time, the module is automatically compensating for the nozzle expansion. It's on for the whole print, but really its stays constant after the nozzle reaches printing temp. I did it with a macro before but that's kind of silly when [z_thermal_adjust] exists.

On a higher level, I'm not sure if this fits in with the intended functionality of the z_thermal_adjust module: print time continuous adjustment of the Z coordinate space.

This is a much simper change to get merged vs building a whole new module and justifying its existence. If I wrote a new module I'm not sure how it would differ from this one, other than the name?

Maybe a good argument is multi-tool/multi-material printers have different extrusion temps per toolhead. Maybe that could be something that a new module could handle more easily. But you could do that by just setting up a different [z_thermal_adjust] section for each toolhead and enabled/disable them when a tool change happens.

[alchemyEngine]

Then the nozzle heats up to printing temp for the print. At that time, print time, the module is automatically compensating for the nozzle expansion.

Of course, that makes sense: it's simpler to compensate at print time, otherwise you'd need to pass your target print temperature in during probing. Of course, that could be done via PRINT_START macros, gcode commands, etc, but wouldn't be very elegant.

It's on for the whole print, but really its stays constant after the nozzle reaches printing temp.

You could recycle the Z height cutoff parameter to freeze the compensation after the first layer so it's not bouncing around during the print.

Maybe a good argument is multi-tool/multi-material printers have different extrusion temps per toolhead. Maybe that could be something that a new module could handle more easily.

Also a good point.

Alright, I'm sold on a conceptual level. I'll dig into the code when I'm back at home base next week and start an initial review if @KevinOConnor is on board as well.

[KevinOConnor]

Alright, I'm sold on a conceptual level. I'll dig into the code when I'm back at home base next week and start an initial review if @KevinOConnor is on board as well.

At a very high-level, I don't see a harm in allowing multiple z_thermal_adjust config sections. I don't know one way or another if that is useful for nozzle compensation. So, I'm hoping you and Gareth can decide.

Cheers, -Kevin

[garethky]

I made a small update to the PR to print the component name in the console when SET_Z_THERMAL_ADJUST is invoked. If the config doesn't use component names there will be no change.

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.