temperature_probe: probe thermal drift compensation

[Arksine]

This adds a temperature_probe module that supports configuring a temperature sensor for use with inductive probes. This module implements the smoothing algorithm present in heaters and provides a temperature drift calibration procedure. The module is intended to be generic, it can be used with any kind of inductive probe, where the calibration logic is farmed out to the probe specific implementation. Also included in this PR is an implementation for the probe_eddy_current module.

The calibration procedure works by using the bed to heat the probe and requesting a manual probe before each sample. This is intended to filter out thermal expansion. Samples are taken at a specified temperature interval, by default this is set to every 2C. The best calibration is achieved by taking samples across the widest temperature range possible. After a manual probe, the probe_eddy_current module will take samples every .5mm, up to 4mm. These samples are used to create a series of 2nd degree polynomials at each height.

Compensation uses the current frequency and coil temperature the find the upper and lower polynomials, then performs linear interpolation to calculate the correct frequency at the target temperature (ie: the temperature of the coil during PROBE_EDDY_CURENT_CALIBRATE).

Attached is a plot of the "stock" height calculate vs the corrected height for a probe that has a good temperature calibration. This plot was measured by using the bed to heat the probe and performing a probe every 30 seconds, after which the height reported by the probe is collected. PROBE_EDDY_CURRENT_CALIBRATE was performed with the probe around 35C.

For comparison, I also collected data at a 1kHz sample rate. In addition, this data was collected with PROBE_EDDY_CURRENT_CALIBRATE close to 60C:

What stands out most in the above data is that the linear regression of the z-height is closer to the z_offset of .5.

This PR is built on #6558, so we likely need to address any outstanding issues with that PR first. Specific commits for this PR start at 108985cdc8af6c7cd315120b19b9fa06a9af2351. The last two commits are minor fixes to probe_eddy_current, one fixing a stale attribute name and one slightly bumping the delay time after a probe to avoid "Unable to obtain probe_eddy_current sensor readings" errors. If necessary I can drop these commits from this PR.

[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.

[Arksine]

For those wondering about the status of this branch, I'm currently working on rebasing and resolving conflicts against the master branch. My goal is to push an updated version this weekend (by June 22).

[smwoodward]

For those wondering about the status of this branch, I'm currently working on rebasing and resolving conflicts against the master branch. My goal is to push an updated version this weekend (by June 22).

Are we able to move off the BTT branch of klipper?

[Arksine]

I have updated this branch to bring it in sync with the current master branch. It should not be necessary to perform a new PROBE_DRIFT_CALIBRATE after updating to the newest implementation, however it will be necessary to perform a new PROBE_EDDY_CURRENT_CALIBRATE.

Another change to be aware of is that there is no longer a SCAN_MODE parameter in BED_MESH_CALIBRATE. Instead there are two new options for the METHOD parameter, scan and rapid_scan.

[KevinOConnor]

Thanks for working on this. Sorry for the delay in responding.

In general, this seems like useful functionality. I have some high-level questions that would help me finish reviewing.

It looks like the temperature compensation algorithm works by creating 9 z mappings at z=0.05 to z=4.55 (0.500mm between each mapping). Each of these Z mappings can translate a temperature to the expected ldc1612 sensor frequency at the given Z height. The mappings are implemented using a quadratic formula (expected_freq = c*temp*temp + b*temp + a). Each mapping is obtained by finding the least squares solution for a, b, c given all the (temperature, freq) pairs measured at the given Z height. During runtime, the code compensates for temperature by adjusting a measured frequency - it finds the appropriate Z bucket given the current temperature and measured frequency, finds the expected frequency range for that Z bucket if the temperature was the nominal calibration temperature, and then interpolates the measured frequency back to the expected frequency at nominal temperature given those ranges. Did I understand this system correctly?

What is the expected user workflow for this system? Are users expected to run PROBE_DRIFT_CALIBRATE on each printer, or is it expected that most users will populate the temperature settings from some upstream source? If the latter, do you have examples of tuned calibration settings?

In some of my previous tests, I got the impression that the ldc1612 was sensitive to both coil temperature and bed temperature. Is it expected that: a) bed temperature isn't a big contributor to drift, b) bed temperature does contribute to drift but it is easy for users to stabilize the bed temperature prior to probing, c) bed temperature does contribute to drift but accounting for coil temperature is still better than nothing, or d) something else?

How would a typical user utilize SET_PROBE_DRIFT_ADJ_FACTOR?

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle.

Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

Thanks again! -Kevin

[smwoodward]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle.

Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated.

It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

[Sineos]

It seems the Beacon and Cartographer are using different approaches (or I have understood them wrong)

Basic Calibration:

• Beacon
• Cartographer

Both are using the paper test and only at one temperature.

Extended Calibration:

• Beacon: n/a
• Cartographer

In Cartographer, an automated process takes various frequency samples at different temperatures and computes profiles from them. No manual paper method is required.

For Beacon, I did not find such a procedure. It seems they rely on a factory-built calibration profile.

I cannot assess the accuracy of either product, but Cartographer appears to have the advantage of not requiring the paper method. It is likely that applying the manual paper method multiple times in a row will result in a significant measurement error due to the inherent limitations of the human user, who is unable to perform the paper method with the precision and accuracy required.

[Arksine]

Hi Kevin, thanks for the review.

It looks like the temperature compensation algorithm works by creating 9 z mappings at z=0.05 to z=4.55 (0.500mm between each mapping). Each of these Z mappings can translate a temperature to the expected ldc1612 sensor frequency at the given Z height. The mappings are implemented using a quadratic formula (expected_freq = ctemptemp + b*temp + a). Each mapping is obtained by finding the least squares solution for a, b, c given all the (temperature, freq) pairs measured at the given Z height. During runtime, the code compensates for temperature by adjusting a measured frequency - it finds the appropriate Z bucket given the current temperature and measured frequency, finds the expected frequency range for that Z bucket if the temperature was the nominal calibration temperature, and then interpolates the measured frequency back to the expected frequency at nominal temperature given those ranges. Did I understand this system correctly?

This is correct.

What is the expected user workflow for this system? Are users expected to run PROBE_DRIFT_CALIBRATE on each printer, or is it expected that most users will populate the temperature settings from some upstream source? If the latter, do you have examples of tuned calibration settings?

Its expected that the user run PROBE_DRIFT_CALIBRATE for each printer. I compared data from multiple BTT Eddy probes and drift was not consistent between them, so I don't believe it is going to be possible to provide a factory preset. That said, it may be possible that future iterations of the Eddy or other probe designs based on the ldc1612 are able to deliver a preset.

In some of my previous tests, I got the impression that the ldc1612 was sensitive to both coil temperature and bed temperature. Is it expected that: a) bed temperature isn't a big contributor to drift, b) bed temperature does contribute to drift but it is easy for users to stabilize the bed temperature prior to probing, c) bed temperature does contribute to drift but accounting for coil temperature is still better than nothing, or d) something else?

In my testing bed temperature was not a significant factor with regard drift. Coil temperature and distance from the bed were the primary factors. For example, below are two plots captured with the bed at 85C AND 110C respectively. This data was captured with the bed and chamber preheated, using a printed mount that decoupled the probe from the gantry. The mount put the coil approximately ~3mm above the bed.

85C

110C

How would a typical user utilize SET_PROBE_DRIFT_ADJ_FACTOR?

I used it to disable thermal compensation by setting a factor of 0 during testing. As I hinted mentioned, it may be possible for some probe designs to deliver a stock calibration and tweak the result by adjusting the factor. I need to do more testing, but it might also be useful for tweaking calibration when switching build plates.

That said, I 100% understand if you want to remove this functionality until we receive confirmation with regard to its usage.

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle.

A manual probe is necessary to remove the influence of thermal expansion from the frame and bed during the probe warming procedure. A good calibration requires that we collect samples across the widest coil temperature range possible, so unfortunately we can't remove this influence by preheating the printer. In the future, if its possible to use the ldc1612 to perform contact based probing, this operation could be automated.

Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

BTT has users running this code based on the version of probe_eddy_current prior to the recent refactor. General feedback I have received is that it works well when calibrated correctly, however the calibration procedure is difficult.

[smwoodward]

@KevinOConnor Something that I wanted to as or run by you with these new probes, I did install on of the eddy's on my ratrig and I kept the Pinda probe on also, and I moved it to be a z-endstop which works for homing, but is there a way to add the capability to do things like homing and QGL/z-tilt with one probe and do the mesh with the different probe?

[KevinOConnor]

In my testing bed temperature was not a significant factor with regard drift.

Thanks for the responses!

Just to further clarify the impact of bed temperature - the two graphs you provided don't look that similar to me. For example, at 85c bed temperature the probe at 60c seems to report 3.270Mhz while at 110c bed temperature the probe at 60c seems to report 3.269Mhz. Granted that's small relative to the coil swing (1khz for 25c bed temperature change relative to about 5Khz for 25c probe temperature change). I'm not sure it's small relative to our probe Z height accuracy goals though. I think I may be missing something.

-Kevin

[KevinOConnor]

@smwoodward - for questions on using Klipper please follow the contact directions at: https://www.klipper3d.org/Contact.html

-Kevin

[KevinOConnor]

Thanks for working on this. In general it seems worthwhile to add to Klipper.

My main comment is about the interface between module components. What do you think about an alternate interface between temperature_probe.py and probe_eddy_current.py? This PR changes probe_eddy_current to detect and register itself with the temperature_probe code (EddyDriftCompensation:self.temp_sensor.register_calibration_helper(self)). Could we flip that around and have the temperature_probe code lookup probe_eddy_current and call a new probe_eddy_current.register_temperature_compensation(self)?

The reason I think that may be useful is that it seems the probe temperature calibration interface (TemperatureProbe to EddyDriftCompensation) is more complex than the frequency adjustment interface (EddyDriftCompensation to EddyCalibration). Thus if we can move EddyDriftCompensation into temperature_probe.py then I think the code interfaces might be more apparent.

I think we could also move calibration_temp to EddyDriftCompensation. The EddyCalibration code could call a self.drift_comp.note_start_z_calibration() at the start of calibration and call a self.drift_comp.note_finish_z_calibration() at the end of calibration (which could signal to EddyDriftCompensation to store the calibration_temp in the temperature_probe config section during auto save). Thus EddyCalibration would have only a few temperature specific methods (def register_temperature_compensation(), self.drift_comp.note_start_z_calibration(), self.drift_comp.note_finish_z_calibration(), self.drift_comp.adjust_freqs(), self.drift_comp.unadjust_freq()).

I have a few other code comments which I'll follow up with below.

Cheers, -Kevin

[bigtreetech]

@KevinOConnor Something that I wanted to as or run by you with these new probes, I did install on of the eddy's on my ratrig and I kept the Pinda probe on also, and I moved it to be a z-endstop which works for homing, but is there a way to add the capability to do things like homing and QGL/z-tilt with one probe and do the mesh with the different probe?

This is already a standard part of how klipper works but as Kevin said, this is not the forum to discuss questions unrelated to the specifics of this PR which are dealing with thermal comp.

[Arksine]

Just to further clarify the impact of bed temperature - the two graphs you provided don't look that similar to me. For example, at 85c bed temperature the probe at 60c seems to report 3.270Mhz while at 110c bed temperature the probe at 60c seems to report 3.269Mhz. Granted that's small relative to the coil swing (1khz for 25c bed temperature change relative to about 5Khz for 25c probe temperature change). I'm not sure it's small relative to our probe Z height accuracy goals though. I think I may be missing something.

I can explain the discrepancy. When collecting data it became immediately apparent that I needed to decouple the probe from the gantry to remove the influence of thermal expansion. BTT designed a mount that encases the probe and places the coil ~3mm above the surface. My collection procedure was to preheat the chamber, connect the probe and place it roughly in the center of the bed, collect data, then remove when done to allow the probe to cool down.

Since the probe isn't fixed, small deviations can change the nominal frequency. Conditions such as the PEI being slightly thicker in one area, imperfections in the printed mount, imperfections in the build plate, etc can all influence then nominal frequency. Put differently, I could collect two data sets at 110C and they would show the same minor deviation.

My main comment is about the interface between module components. What do you think about an alternate interface between temperature_probe.py and probe_eddy_current.py? This PR changes probe_eddy_current to detect and register itself with the temperature_probe code (EddyDriftCompensation:self.temp_sensor.register_calibration_helper(self)). Could we flip that around and have the temperature_probe code lookup probe_eddy_current and call a new probe_eddy_current.register_temperature_compensation(self)?

Sure, that wont be a problem.

The reason I think that may be useful is that it seems the probe temperature calibration interface (TemperatureProbe to EddyDriftCompensation) is more complex than the frequency adjustment interface (EddyDriftCompensation to EddyCalibration). Thus if we can move EddyDriftCompensation into temperature_probe.py then I think the code interfaces might be more apparent.

Ah, you would prefer me to move the entire EddyDriftCompensation class to temperature_probe.py? The primary reason I organized it the current way was to keep the temperature probe generic. For example, an implementation for standard inductive probes could be adapted to use the same calibration procedure. In my estimation it made sense to keep the eddy probe specific code in probe_eddy_current.py. That said, I don't have a problem moving it if that is your preference.

Edit: After looking at it and some further thought, I agree that it makes sense to move the drift compensation helper to temperature_probe.py. If we want or need to add support for additional probe types, we can add those to temperature_probe.py as well.

I think we could also move calibration_temp to EddyDriftCompensation. The EddyCalibration code could call a self.drift_comp.note_start_z_calibration() at the start of calibration and call a self.drift_comp.note_finish_z_calibration() at the end of calibration (which could signal to EddyDriftCompensation to store the calibration_temp in the temperature_probe config section during auto save). Thus EddyCalibration would have only a few temperature specific methods (def register_temperature_compensation(), self.drift_comp.note_start_z_calibration(), self.drift_comp.note_finish_z_calibration(), self.drift_comp.adjust_freqs(), self.drift_comp.unadjust_freq()).

Sound good. I'll work on that change. In addition, I'll address each review comment individually as I go along.

[Arksine]

I have pushed some updates, the changes of which are outlined below:

• moved the Polynomial2D class from mathutil.py to temperature_probe.py
• moved the EddyDriftCompensation class from probe_eddy_current.py to temperature_probe.py. The probe_eddy_current module now contains a "dummy" class serves as the default when no temperature probe is registered.
• Reversed registration logic. The temperature_probe now registers the compensation helper with the underlying probe implementation by calling its register_drift_compensation() method.
• Moved calibration temperature tracking from the probe_eddy_current.EddyCalibration class to temperature_probe.EddyDriftCompensation. Eddy Probe Calibration calls the suggested note_z_calibration_start() and note_z_calibration_finish() methods of the compensation helper.
• Use one temperature reading for each batch of ldc samples received when applying drift compensation.
• Remove the debug file output
• Remove the thread lock in TemperatureProbe. Use the suggested method of storing the smoothed, min, and max tempertures in a tuple for atomic writes. Implement the suggested _check_kick_next() callback to avoid a potential race when calling "TEMPERATURE_PROBE_NEXT"
• Rename all gcode commands prefixed withe PROBE_DRIFT_ to TEMPERATURE_PROBE_
• Remove the SET_PROBE_DRIFT_ADJ_FACTOR gcode command
• Implement TEMPERATURE_PROBE_ENABLE gcode command. Report the current enabled state in TemperatureProbe.get_status()
• In the TEMPERATURE_PROBE_CALIBRATE gcode handler, catch self.printer.command_error when calling _move_to_start().

I believe that covers everything. This change moves all drift compensation related items in the autosave from the probe_eddy_current section to the temperature probe section. Testers that don't wish to redo their calibration can manually update the section (generally it isn't recommended to modify the autosave, but it seems appropriate for this purpose). For example, the autosave section should now contain a snippet that looks like the following.

#*# [temperature_probe btt_eddy]
#*# calibration_temp = 42.919721
#*# drift_calibration =
#*# 	3265957.923222, -161.557392, 0.448391
#*# 	3256524.613344, -106.776906, 0.145617
#*# 	3249162.938671, -68.684932, -0.075612
#*# 	3243413.959281, -44.068844, -0.206610
#*# 	3238864.481265, -26.708818, -0.301046
#*# 	3235263.558343, -15.621579, -0.355331
#*# 	3232252.151603, -4.210931, -0.421378
#*# 	3229739.335973, 7.083410, -0.497587
#*# 	3227831.886549, 9.409186, -0.497820
#*# drift_calibration_min_temp = 32.18233127179636

[KevinOConnor]

Thanks. It looks fine to me. If there are no further comments I'll look to commit in a few days. I guess I'll look to do a "squash and merge".

-Kevin

[Arksine]

Thanks. It looks fine to me. If there are no further comments I'll look to commit in a few days. I guess I'll look to do a "squash and merge".

Sounds good. I just removed the if temp check, and did a fixup on the commits so you can rebase and merge if that is your preference.

[bigtreetech]

Hi @KevinOConnor. Just checking in and seeing if there is anything that we can do to help get this merged. We know that there are quite a number of users who would love to see this in mainline.

Thanks so much for all of your efforts.

[KevinOConnor]

Thanks. I committed this change. I was just giving a few days to see if others had comments.

Cheers, -Kevin

[qqqwqk]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle. Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated.

It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

[smwoodward]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle. Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated. It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

I don't think the thermal loss is that great to the coil temperature from what I saw, I can say that the thermal loss of the air in the chamber would extend the required time in heating up the coil as the chamber environment would need to heat back up to keep increasing the coil temp. There would still be a good amount of radiation heat transfer because of the distance between the bed and coil, but the convection transfer would take time to regain the temperature once the chamber is closed again.

[qqqwqk]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle. Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated. It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

I don't think the thermal loss is that great to the coil temperature from what I saw, I can say that the thermal loss of the air in the chamber would extend the required time in heating up the coil as the chamber environment would need to heat back up to keep increasing the coil temp. There would still be a good amount of radiation heat transfer because of the distance between the bed and coil, but the convection transfer would take time to regain the temperature once the chamber is closed again.

I'm just raising an idea: maybe thermal expansion of the frame and bed should not be taken into account when calibrating the probe, which would simplify the manual work of calibration(As far as I know: Not even Hannibal would try to cook his fingers). Thermal expansion should be considered as a separate item (perhaps we should consider using z-endstop to try to detect/calculate thermal expansion)

[smwoodward]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle. Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated. It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

I don't think the thermal loss is that great to the coil temperature from what I saw, I can say that the thermal loss of the air in the chamber would extend the required time in heating up the coil as the chamber environment would need to heat back up to keep increasing the coil temp. There would still be a good amount of radiation heat transfer because of the distance between the bed and coil, but the convection transfer would take time to regain the temperature once the chamber is closed again.

I'm just raising an idea: maybe thermal expansion of the frame and bed should not be taken into account when calibrating the probe, which would simplify the manual work of calibration(As far as I know: Not even Hannibal would try to cook his fingers). Thermal expansion should be considered as a separate item (perhaps we should consider using z-endstop to try to detect/calculate thermal expansion)

Perhaps someone else can speak more about exactly what is going on, but from my understanding the temperature calibration isn't more about thermal expansion as the readings the eddy current sensor change based on temperature. It's a bit different than thermal expansion which would cause the physical parts to change shape. It's more that everything else being equal (sensor being exactly the same distance away from the metal surface no matter the temperature) that if the sensor is reading 2.7 gigawatts (or what ever it is measuring) at 24*, that if the sensor alone goes to 35* it will read 3.7 gigawatts, but nothing else has changed except for the temp of the sensor. Thermal expansion would cause the gap to physically change between the two items.

[qqqwqk]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle. Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated. It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

I don't think the thermal loss is that great to the coil temperature from what I saw, I can say that the thermal loss of the air in the chamber would extend the required time in heating up the coil as the chamber environment would need to heat back up to keep increasing the coil temp. There would still be a good amount of radiation heat transfer because of the distance between the bed and coil, but the convection transfer would take time to regain the temperature once the chamber is closed again.

I'm just raising an idea: maybe thermal expansion of the frame and bed should not be taken into account when calibrating the probe, which would simplify the manual work of calibration(As far as I know: Not even Hannibal would try to cook his fingers). Thermal expansion should be considered as a separate item (perhaps we should consider using z-endstop to try to detect/calculate thermal expansion)

Perhaps someone else can speak more about exactly what is going on, but from my understanding the temperature calibration isn't more about thermal expansion as the readings the eddy current sensor change based on temperature. It's a bit different than thermal expansion which would cause the physical parts to change shape. It's more that everything else being equal (sensor being exactly the same distance away from the metal surface no matter the temperature) that if the sensor is reading 2.7 gigawatts (or what ever it is measuring) at 24*, that if the sensor alone goes to 35* it will read 3.7 gigawatts, but nothing else has changed except for the temp of the sensor. Thermal expansion would cause the gap to physically change between the two items.

heating the coil sensors also heat the bed and frame simultaneously, and during this process the distance between the sensor and the bed does not remain constant.

[smwoodward]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle.

Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated.

It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

I don't think the thermal loss is that great to the coil temperature from what I saw, I can say that the thermal loss of the air in the chamber would extend the required time in heating up the coil as the chamber environment would need to heat back up to keep increasing the coil temp. There would still be a good amount of radiation heat transfer because of the distance between the bed and coil, but the convection transfer would take time to regain the temperature once the chamber is closed again.

I'm just raising an idea: maybe thermal expansion of the frame and bed should not be taken into account when calibrating the probe, which would simplify the manual work of calibration(As far as I know: Not even Hannibal would try to cook his fingers). Thermal expansion should be considered as a separate item (perhaps we should consider using z-endstop to try to detect/calculate thermal expansion)

Perhaps someone else can speak more about exactly what is going on, but from my understanding the temperature calibration isn't more about thermal expansion as the readings the eddy current sensor change based on temperature. It's a bit different than thermal expansion which would cause the physical parts to change shape. It's more that everything else being equal (sensor being exactly the same distance away from the metal surface no matter the temperature) that if the sensor is reading 2.7 gigawatts (or what ever it is measuring) at 24*, that if the sensor alone goes to 35* it will read 3.7 gigawatts, but nothing else has changed except for the temp of the sensor. Thermal expansion would cause the gap to physically change between the two items.

heating the coil sensors also heat the bed and frame simultaneously, and during this process the distance between the sensor and the bed does not remain constant.

That's why you do the paper test to make sure that the nozzle is still at the distance it should be, then it takes readings of the eddy currents at the exact same spot to know how they change. From my understanding the sensor readings change much more drastically due to temperature than thermal expansion affects the measurements.

[qqqwqk]

Why does PROBE_DRIFT_CALIBRATE perform a manual probe at the start of each temperature measurement? My initial thought would be to perform the Z/freq/temp sampling at identical Z carriage positions. I feel I may be missing something subtle.

Do you know if this PROBE_DRIFT_CALIBRATE code is in wide use today? Has there been user feedback on calibration issues, accuracy tests, or similar?

I just set this up recently off of their forked version, and what it did at each temperature measurement was to do a paper test with the nozzle, and when I clicked accept it moved and did measurements, then went back to the position and waited till the next temperature which I used the paper again to set the manual probe and it repeated.

It wasn't difficult to do, but it would be nice if there was a different way of doing it than sitting by the printer for 30+ minutes to do the paper test over and over.

I totally agree. the paper testing requires opening the chamber door, which causes rapid loss of chamber temperature and introduces rapid changes in coil temperature.

I don't think the thermal loss is that great to the coil temperature from what I saw, I can say that the thermal loss of the air in the chamber would extend the required time in heating up the coil as the chamber environment would need to heat back up to keep increasing the coil temp. There would still be a good amount of radiation heat transfer because of the distance between the bed and coil, but the convection transfer would take time to regain the temperature once the chamber is closed again.

I'm just raising an idea: maybe thermal expansion of the frame and bed should not be taken into account when calibrating the probe, which would simplify the manual work of calibration(As far as I know: Not even Hannibal would try to cook his fingers). Thermal expansion should be considered as a separate item (perhaps we should consider using z-endstop to try to detect/calculate thermal expansion)

Perhaps someone else can speak more about exactly what is going on, but from my understanding the temperature calibration isn't more about thermal expansion as the readings the eddy current sensor change based on temperature. It's a bit different than thermal expansion which would cause the physical parts to change shape. It's more that everything else being equal (sensor being exactly the same distance away from the metal surface no matter the temperature) that if the sensor is reading 2.7 gigawatts (or what ever it is measuring) at 24*, that if the sensor alone goes to 35* it will read 3.7 gigawatts, but nothing else has changed except for the temp of the sensor. Thermal expansion would cause the gap to physically change between the two items.

heating the coil sensors also heat the bed and frame simultaneously, and during this process the distance between the sensor and the bed does not remain constant.

That's why you do the paper test to make sure that the nozzle is still at the distance it should be, then it takes readings of the eddy currents at the exact same spot to know how they change. From my understanding the sensor readings change much more drastically due to temperature than thermal expansion affects the measurements.

I'm just expressing my opinion and suggesting a way to make it easier to use. After all, doing paper calibration multiple times with the heated bed on is a painful process.

[Arksine]

I'm just expressing my opinion and suggesting a way to make it easier to use. After all, doing paper calibration multiple times with the heated bed on is a painful process.

I understand. Unfortunately the manual probe is required to take valid samples. Without the manual probe the distance between the probe's coil and the bed will change due to thermal expansion. This would result in a calibration that is invalid.

As mentioned previously in this thread, if its possible to implement contact probing using the ldc1612 then the manual probe can be replaced with an automatic probe. Until then, the current solution is the only workable solution for a probe mounted to the gantry.

Another alternative would be to calibrate the probe before mounting/installation. This would require designing a printed holder that sits on the bed, with a single motor capable of moving the probe 4 to 5 mm vertically. This would allow users to preheat the bed/chamber, then insert the probe/holder and perform the calibration.

[Sineos]

Another alternative would be to calibrate the probe before mounting/installation. This would require designing a printed holder that sits on the bed, with a single motor capable of moving the probe 4 to 5 mm vertically. This would allow users to preheat the bed/chamber, then insert the probe/holder and perform the calibration.

Is this so much different from what Cartographer does? It seems to take the profile data at various heights and various temperatures via a macro

[Arksine]

Is this so much different from what Cartographer does? It seems to take the profile data at various heights and various temperatures via a macro

Its possible, I haven't looked at the details of the Cartographer implementation. Since their extension seemed to be heavily derived from the beacon extension I assumed they performed thermal compensation in a similar fashion, where the probe is shipped with some presets in flash memory.

[Sineos]

I assumed they performed thermal compensation in a similar fashion

I have not seen something similar for the beacon. Details here: https://docs.cartographer3d.com/cartographer-probe/fine-tuning/temperature-differential-calibration-beta