Skip to content

PR: Enable multiple z_thermal_adjust sections #6855

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

garethky
Copy link
Contributor

@garethky garethky commented Mar 13, 2025

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:
Screenshot 2025-03-13 at 2 27 40 PM

@@ -1262,6 +1264,10 @@ See also: [extended g-code commands](G-Codes.md#z_thermal_adjust).
#max_z_adjustment:
# Maximum absolute adjustment that can be applied to the Z axis [mm]. The
# default is 99999999.0 mm (unlimited).
#sensor:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a suggestion: It should be possible to reuse any existing sensor by:
sensor_type: temperature_combined

So, it may not be necessary to reimplement same functionality here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that does work with config like this:

[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

I can remove the sensor option. I think this idea of a sensor_list is great for the frame expansion as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to remove the sensor stuff. That makes the PR really short now. 😄

@garethky garethky force-pushed the pr-z_thermal_adjust-sensors branch from c9f7a08 to d640d26 Compare March 13, 2025 20:10
@garethky garethky changed the title PR: Support re-using sensors in z_thermal_adjust PR: Allow multiple z_thermal_adjust sections Mar 14, 2025
@garethky garethky force-pushed the pr-z_thermal_adjust-sensors branch from d640d26 to 1b4fd00 Compare March 14, 2025 00:25
@garethky garethky changed the title PR: Allow multiple z_thermal_adjust sections PR: Enable multiple z_thermal_adjust sections Mar 14, 2025
@garethky garethky marked this pull request as ready for review March 15, 2025 00:14
@garethky garethky force-pushed the pr-z_thermal_adjust-sensors branch from 1b4fd00 to d3a6967 Compare March 25, 2025 16:36
@KevinOConnor
Copy link
Collaborator

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

-Kevin

@alchemyEngine
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Collaborator

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

Multiple `z_thermal_adjust` sections may now be defined in config to compensate for different sources of z thermal expansion that happen at different rates.

Signed-off-by: Gareth Farrington <[email protected]>
@garethky garethky force-pushed the pr-z_thermal_adjust-sensors branch from d3a6967 to ade7a4d Compare April 14, 2025 16:55
@garethky
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants