Skip to content
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

No repeatable temperature calibration possible #1167

Closed
RacingHell opened this issue Sep 17, 2018 · 8 comments
Closed

No repeatable temperature calibration possible #1167

RacingHell opened this issue Sep 17, 2018 · 8 comments

Comments

@RacingHell
Copy link

RacingHell commented Sep 17, 2018

3.4.0 final / MK3

In the past I read a lot of pinda calibration and stahlfabrik's ideas to stabilize the cal.data by manual analysis (not tested by my own till now). I have trouble on bigger prints since ever, where the 1st layer drifts away (dependent on X/Y coordinates - no clue if pinda drifts that much while bedleveling due to faulty cal.data), I did some own tests. I can't assign the recent results to my initial issue - missing abilities to dig deep enough into the prusa-matrix. But maybe there's something to check in the calibration code.

Execution of temp. calibrations in following sequence, DELTA=difference to previous cal.point:

old calibration data before FW update:

>>>M861 ?
SENDING:M861 ?
PINDA cal status: 1
index, temp, ustep, um
n/a, 35, 0, 0.00
0, 40, 6, 15.00 [DELTA:6]
1, 45, -1, -2.50 [DELTA:-7]
2, 50, 0, 0.00 [DELTA:1]
3, 55, 12, 30.00 [DELTA:12]
4, 60, 33, 82.50 [DELTA:21]

after FW update and M861 Z (reset+temp.cal.off):

0, 40, 31, 77.50 [DELTA:31]
1, 45, 35, 87.50 [DELTA:4]
2, 50, 41, 102.50 [DELTA:6]
3, 55, 48, 120.00 [DELTA:7]
4, 60, 73, 182.50 [DELTA:25]

retry 1:

0, 40, -24, -60.00 [DELTA:-24]
1, 45, -21, -52.50 [DELTA:3]
2, 50, -11, -27.50 [DELTA:10]
3, 55, -6, -15.00 [DELTA:5]
4, 60, 16, 40.00 [DELTA:22]

retry 2:

0, 40, 0, 0.00 [DELTA:0]
1, 45, 4, 10.00 [DELTA:4]
2, 50, 14, 35.00 [DELTA:10]
3, 55, 19, 47.50 [DELTA:5]
4, 60, 41, 102.50 [DELTA:22]

retry 3:

0, 40, -16, -40.00 [DELTA:-16]
1, 45, -14, -35.00 [DELTA:2]
2, 50, -9, -22.50 [DELTA:5]
3, 55, 0, 0.00 [DELTA:9]
4, 60, 23, 57.50 [DELTA:23]

after 2nd M861 Z (reset):

0, 40, -17, -42.50 [DELTA:-17]
1, 45, -18, -45.00 [DELTA:-1]
2, 50, -14, -35.00 [DELTA:4]
3, 55, -5, -12.50 [DELTA:9]
4, 60, 17, 42.50 [DELTA:22]

after 3rd M861 Z (reset+temp.cal.off):

0, 40, 15, 37.50 [DELTA:15]
1, 45, 20, 50.00 [DELTA:5]
2, 50, 24, 60.00 [DELTA:4]
3, 55, 33, 82.50 [DELTA:8]
4, 60, 57, 142.50 [DELTA:24]

Correlations in the measured cal.datas are visible, but expected rocksolid values on every retry I am missing. The values are jumping a lot. Under 50° I can't figure out any consistency. Sending M861 Z and starting calibration with temp.cal. off brought esteps back into similar values.

Any suggestions/ideas?

@stahlfabrik
Copy link
Contributor

Hi,

yes the automatic temperature calibration has been bad since the release of the MK3. It is unreliable, unrepeatable and the results are worse than leaving the machine uncalibrated.

That is why there are (known to me) three different ways of calibrating the temperature compensation table manually. All of them yield result which are 100% better than the results of automatic process.

So yes, your issue is totally valid. Still, I want to let you know that you are not dependent of the automatic process!

https://github.com/PrusaOwners/prusaowners/wiki/Manual_print_based_PINDA_temperature_calibration
2.https://github.com/crzcrz/prusaowners/blob/master/First_layer_and_PINDA_temperature_calibration_with_calipers.md
3.
https://github.com/PrusaOwners/prusaowners/wiki/PINDA_Temperature_Calibration_with_Electrical_Continuity

@RacingHell
Copy link
Author

Hi stahlfabrik,

thanks for your reply. I prepared everything for the third method already.

Would be nice to know, if the firmware method is in work to get fixed.

Grüße

@stahlfabrik
Copy link
Contributor

Interesting choice!;-) Good luck!

@RacingHell
Copy link
Author

RacingHell commented Sep 19, 2018

Did the calibration yesterday. Will need some more testing.

gcode     | index    | temp  | bed temp     | Z-hight @ continuity           | usteps (calc.)
1         |          | 35C   | 60C          | -1,315                         |  
2         | 0        | 40C   | 60C          | -1,375                         | 24
3         | 1        | 45C   | 60C          | -1,380                         | 26 (+2)
4         | 2        | 50C   | 80C          | -1,435                         | 48 (+22)
5         | 3        | 55C   | 90C          | -1,475                         | 64 (+16) <- maybe done incorrect
6         | 4        | 60C   | 100C         | -1,715                         | 160 (+96)

Is there any chance to write a pronterface macro or gcode which does the following?:

  • disable usage of temperature cal.-data
  • reset calibration table data
  • cool down pinda to 30°
  • mesh bed leveling
  • move to the middle
  • move down z until pinda led off
  • get z value
  • set bed temp 100
  • LOOP
  • wait until pinda reaches T=30+i (for i=5)
  • move up z until pinda led on
  • move down z until pinda led off
  • get z value (show it within pronterface)
  • LOOPEND if T>=65

Could this be a way to get a perfect curve? Maybe the the firmware integrated calibration does completely the same, but this would mean the code is buggy. IMO the best method would be to stay within the closed parameter system of Z axis, pinda temp and -switch. Every factor ouside this relationship adds additional failures.

*edited - corrected wrong calculations.

@ledvinap
Copy link
Contributor

@RacingHell : Problem with your algorithm is that it includes bed deformation in measurements.
When the bed starts heating, the PCB expands, but aluminium plate is still cool. Bed corners bend down and center up. Then Aluminium plate heats up slowly, expanding too (about 33% more per dec C than PCB). And when you start printing, aluminium plate is cooled again by y-axis movement.

So at least you should wait long enough before the bed reaches thermal equilibrium before starting measurements, with PINDA far away from bed. Then go close to bed and perform series of measurements and pinda heats up.
Also you probably want to perform the calibration on single bed temperature. You want bed deformation compensated in bed mesh leveling, to it should not be included in probe data.

Just measured deformation at bed center (using dial gauge):
35C stable -60um
85C maximum: 50um
85C stable: 0um (after 7 minutes, but within 10um sooner)

It's over 200um from 85C stable to 45C when measuring at lower right corner.

Using electrical continuity will help, but it will make the algorithm a bit more involved. Nozzle should be heated higher than bed temperature to avoid including extruder thermal expansion.

@CCS86
Copy link

CCS86 commented Jan 13, 2019

Here's my take:

The integrated PINDA temp calibration is introducing external variables into the resultant calibration data, which prevents a repeatable result.

It is probing the same spot on the bed to see how the probe changes its triggering height, as the sensor changes temp. However, this routine is also changing the bed temp, and because of thermal expansion of all the bed/platform components, that same spot physically changes height.

My thought for a more ideal temp calibration:

  • Raise print head to near max height and turn on bed to the highest temp needed for pinda calibration

  • Allow a long enough dwell so that physically all bed components stabilize. Probe is still close to room temp.

  • Now drop the head and probe the bed, creating a point set of height vs probe temp.

  • Wait close to the bed, as the pinda heats up, dwell until the probe reaches the next defined temp and probe again.

  • Iterate the dwell/probe loop until all temps have been populated

@github-actions
Copy link

This issue has been flagged as stale because it has been open for 60 days with no activity. The issue will be closed in 7 days unless someone removes the "stale" label or adds a comment.

@github-actions
Copy link

github-actions bot commented Sep 7, 2023

This issue has been closed due to lack of recent activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants