Polynomial Temp Compensation for Probes?

evan38109

As of RRF v3.1.1, we can pass G31 a temperature coefficient, C, when using an inductive probe like a PINDA v2 to offset the probe's variance at different temperatures. In practice, though, the relationship isn't linear, and the temperature effect yields increasing offsets at higher temperatures.

How about an additional optional parameter, (D?), that is the factor for a second-degree polynomial for temperature compensation? The additional compensated height would then be C * temp + D * temp^2.

I find that I can sufficiently approximate the relationship with a second-degree polynomial. (A third-degree polynomial is better, but second-degree gets close enough for FFF printing.)

I model this (messily!) in RRF3 with some conditional GCode. I have a G831.g script that approximates the model with a series of short linear segments, and call it just before homing Z, leveling the bed, or measuring a mesh:

if sensors.analog[2].lastReading < 25       ;       temp < 25°C
    G31 P500 X23 Y5 Z{ 0.65 + 0.000 } H2 S20 C0.001685
elif sensors.analog[2].lastReading < 30     ; 25 <= temp < 30
    G31 P500 X23 Y5 Z{ 0.65 + 0.008425 } H2 S25 C0.007815 
elif sensors.analog[2].lastReading < 35     ; 30 <= temp < 35
    G31 P500 X23 Y5 Z{ 0.65 + 0.047500 } H2 S30 C0.013945 
elif sensors.analog[2].lastReading < 40     ; 35 <= temp < 40
    G31 P500 X23 Y5 Z{ 0.65 + 0.117225 } H2 S35 C0.020075 
elif sensors.analog[2].lastReading < 45     ; 40 <= temp < 45
    G31 P500 X23 Y5 Z{ 0.65 + 0.217600 } H2 S40 C0.026205
elif sensors.analog[2].lastReading < 50     ; 45 <= temp < 50
    G31 P500 X23 Y5 Z{ 0.65 + 0.348625 } H2 S45 C0.032335
elif sensors.analog[2].lastReading < 55     ; 50 <= temp < 55
    G31 P500 X23 Y5 Z{ 0.65 + 0.510300 } H2 S50 C0.038465  
elif sensors.analog[2].lastReading < 60     ; 55 <= temp < 60
    G31 P500 X23 Y5 Z{ 0.65 + 0.702625 } H2 S55 C0.044595
elif sensors.analog[2].lastReading < 65     ; 60 <= temp < 65
    G31 P500 X23 Y5 Z{ 0.65 + 0.925600 } H2 S60 C0.050725
else                                        ; 65 <= temp
    G31 P500 X23 Y5 Z{ 0.65 + 1.179225 } H2 S65 C0.056855

This works pretty well, but it is a bit hacky. I find myself sprinkling G831 calls all over homez.g, homeall.g, bed.g, print start scripts, etc. A polynomial factor would be easier and cleaner.

(One more parameter -- E? -- would be even better, for C * temp + D * temp^2 + E * temp^3, but hey, I don't want to get greedy here. At least on my machine, the 2nd-degree approximation gets within 0.01mm error for the usable temperature range.)

dc42

I knew that inductive sensors were sensitive to temperature, but I didn't know they were as awful as that. They are also bigger and heavier than the alternatives. Why does anyone use them?

Phaedrux

@dc42 said in Polynomial Temp Compensation for Probes?:

Why does anyone use them?

They're cheap and have some sort of cachet thanks to Prusa using them.

evan38109

@dc42 said in Polynomial Temp Compensation for Probes?:

...They are also bigger and heavier than the alternatives. Why does anyone use them?

As far as bulkiness goes, the one I’m using is modeled after Prusa’s PINDA2, with a thermistor embedded in the probe. It’s about 7.5mm in diameter by 36mm long. It only weighs a few grams, or 15g with the entire cable assembly on the scale. That’s smaller than a BLTouch, and costs less than half, too (about $15 US / £13.45 GPB, on a quick Googling). Runs on 5V, so it was easy to wire up to a Duet3.

Why did I use it for this project? Well, mostly convenience. This project itself was somewhat less than planned. I’d been going back and forth between building a Railcore or retrofitting my old Prusa MK3S, and ultimately decided to go with the Railcore. But then parts got delayed. While I waited, I got antsy. Needing something to do over a long weekend other than stare at a screen, I finally decided to rip up my already-heavily-modified Prusa MK3S and switch it over to a Duet3 6HC. (Yes, it’s massive overkill for this purpose; I also love it.)

In this case, my main motivation was that I could get the PINDA2 working without redesigning the extruder or ordering more parts. That said, I think inductive probes like these with embedded thermistors may be worth a second look on the merits.

They may have significant temperature drift, but it’s predictable drift. With the thermistor embedded in the probe, I’ve found the compensation to be quite reliable, both before and after the Duet conversion. I’m sure it’s not the most precise probe out there, but I’m used to just hitting print and it works.

Probing is fast, too. Tolerates fast dive speeds, is happy with less than 1mm dive height, and no need to deploy a pin or whatnot. I have no problem setting M558 … S0.001 A20 and even if it has to probe half a dozen times, it still takes less than a second.

I'm no fanboy here, and I'm certainly not claiming that it's the Best Probe Ever. It feels like all the options out there today have some compromises, though. When it comes to inductive probes, you've got compact, lightweight, cheap, fast, convenient, plus reliable and accurate enough for an everyday printer. On the balance, you've got to do some software temperature compensation and avoid magnets. Perfect? Nah. Acceptable? Sure.

There may be better alternatives for a given printer, depending on the compromises one chooses. I’ll head in a different direction with that Railcore eventually. In the meantime, though, the printer is busy laying down plastic. (And that Duet is great!)

Kolbi

@evan38109
Thanks for sharing the macro, is that the complete file?

I am using the same probe (although I have bltouch in wrapper...) and would like to implement something along the same lines.

Cheers,
Kolbi

mendenmh

@dc42 It's probably not the probe... it's probably the bed conductivity. I haven't tried fitting the curve displayed, but I think that since the inductive coupling to the bed will be strongly dependent on the skin depth, that inductive probes will of necessity show this behavior. I would guess an inverse-power law of the height that is linear in the conductivity.

evan38109

Hey @Kolbi,

That's all of it except the comments. You can find the whole source config on GitHub here, along with the rest of my latest config. You'll note that each Z offset entry starts with 0.65 + ... -- that's because 0.65mm is my offset when cool. Makes it easy to find-and-replace if I ever tweak the printer and have a different Z offset.

I have no idea if these specific values are portable to other probes. It may be worth taking some measurements yourself. I started by moving to the center of the bed and homing Z while cool. Next, I measured the height with this ProbePoint.g macro, and plopped the data into a spreadsheet. I then turned on the heater at a low temperature, waited a few minutes for temps to stabilize, and re-probed. I repeated for every degree or so along the appropriate temperature range, bumping up the extruder or bed heater as needed to get to the next temp. The last step was a quick regression in my spreadsheet to determine offsets at each temperature point. If you're not trying to do something fancy, like curve-fitting, you can probably simplify this process by just measuring every 5°C or so and use those offsets directly.

Obviously, you'll need to modify these macros to fit your specific printer and config if you decide to use them.

If you try it, let me know! I'd love to see if this kind of calibration is portable between probes, or if it varies.

Good luck!

Kolbi

@evan38109 Thanks much, really appreciate it. I've just shifted over to duet and still feeling my way around it. I'll give it a go once I get some time - hopefully this weekend. It should jive well with my setup, running a MK3s with Zaribo 10mm upgrade and Mosquito - not really anything 'prusa' left over.
My config files are here: https://github.com/rkolbi/RRF-machine-config-files/tree/master/Prusa MK3s

dc42

I've added this to the work list for RRF 3.3. It may possibly appear in 3.2 as it should be quite simple to do.

T3P3Tony

Another benefit I heard about (but not sure if this is used/still used) is it allowed for detection of the magnets in a magnetic bed. If the magnets are precisely placed (i.e by a repeatable CNC manufacturing process) then orthogonal axis compensation could be used to square up a "not square" frame, to a square bed.

evan38109

@dc42 said in Polynomial Temp Compensation for Probes?:

I've added this to the work list for RRF 3.3. It may possibly appear in 3.2 as it should be quite simple to do.

Thanks, @dc42! You made my morning.

Kolbi

@evan38109 Quick Q: when you said measured the hights (and subsequently put them in a spreadsheet) were you referring to the 'bed probe height' provided by the G32 output?
"G32 bed probe heights: 0.002, mean 0.002, deviation from mean 0.000

Cheers,
Kolbi

Kolbi

@evan38109 I was looking at your macro I wanted to check where my pindav2 measured up at. I made a quick macro to test the probe and make a file containing the current pinda temp and the trigger, then a downloaded (zip) contents, brought it into my mac, did a ls -1 to get a single row list, copied and saved that to a text file with csv extension, and lastly brought it into numbers.

Here's the script:

while sensors.analog[2].lastReading < 60

	G90 ; set true
	G1 Z2 F2000
	M400
	G4 P990
	G91 ; set rel
	while sensors.endstops[2].triggered = false
		G1 Z-0.00625 F300
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S0

	G90 ; set true
	G1 Z2 F2000
	M400
	G4 P990
	G91 ; set rel
	while sensors.endstops[2].triggered = false
		G1 Z-0.00625 F300
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S1

	G90 ; set true
	G1 Z2 F2000
	M400
	G4 P990
	G91 ; set rel
	while sensors.endstops[2].triggered = false
		G1 Z-0.00625 F300
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S2

	G90 ; set true
	G1 Z2 F2000
	M400
	G4 P990
	G91 ; set rel
	while sensors.endstops[2].triggered = false
		G1 Z-0.00625 F300
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S3

	G90 ; set true
	G1 Z2 F2000
	M400
	G4 P990
	G91 ; set rel
	while sensors.endstops[2].triggered = false
		G1 Z-0.00625 F300
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S4

	G90 ; set true
	G1 Z2 F2000
	M400
	G1 Z{(state.restorePoints[0].coords[2] + state.restorePoints[1].coords[2] + state.restorePoints[2].coords[2] + state.restorePoints[3].coords[2] + state.restorePoints[4].coords[2]) / 5} F100	
	G60 S5

	G90 ; set true
	G1 Z4 F2000
	M400


	echo "Pinda at " ^ sensors.analog[2].lastReading ^ " average trigger at " ^ state.restorePoints[5].coords[2] ^ " millimeters."
	echo "Trigs: "^state.restorePoints[0].coords[2]^", "^state.restorePoints[1].coords[2]^", "^state.restorePoints[2].coords[2]^", "^state.restorePoints[3].coords[2]^", "^state.restorePoints[4].coords[2]

	M28 {"0:/macros/Probe Comp/"^ sensors.analog[2].lastReading ^","^state.restorePoints[5].coords[2]}  
	M29

Smoothed:
Screen Shot 2020-07-17 at 9.59.24 PM.png

evan38109

Hey @Kolbi ,

Hmm...not sure what's going on there, but that doesn't look right at all. It definitely shouldn't be going down as temperatures get higher, and the magnitude also looks off, too. I don't know, but I suspect the probing method is not very accurate:

while sensors.endstops[2].triggered = false
    G1 Z-0.00625 F300

I don't understand the intricacies of RRF, but it feels like there's plenty of room for timing oddities there with the command queue.

I much prefer G30 S-1 ... :

G1 Z3                        ; move to first probing height
G30 P0 X100 Y102 Z-99999 S-1 ; probe #1
...

It's cleaner, simpler, more accurate, and it also follows your M558 parameters. I love how it will take samples until it reaches the requested tolerance; it means that each of my "samples" is actually a sample group. For instance, when probing like this, I like to set the tolerance tight, with lots of available iterations and a very slow feed rate:

M558 ... H1.0 F180 T99999 A20 S0.001

For data , I just made a quick Google Doc with columns aligned to make data entry with the keypad easy:

I suppose it would be possible to script that, but...ehh, that's too close to the day job for a hobby.

Kolbi

@evan38109 Yeah, I'm not sure on the scripts accuracy either and I had/have a hard time believing the results too. Or maybe I have a poopy pinda?
I do find it interesting that the detection height goes back down after 43c - even if the method is deemed not accurate, it still shouldn't be seeing a drop in detection height. I also noticed that once the pinda is triggered, you have to move it up a little to get back to an untriggered state.
Eh, it's a rainy Saturday morning here, will likely toy around with it some more.

Kolbi

Ok, made some macro changes and I think I had more accurate results.
Take a look:
Screen Shot 2020-07-18 at 10.28.27 AM.png

Macro:


	G32

	G1 X100 Y100 F2000

	M558 P5 C"^zprobe.in" H1.0 F180 T99999 A20 S0.001              ; Set probing to slow and precise
	M140 S100
	M104 S240

while sensors.analog[2].lastReading < 50


	G30 Z-99999 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S0
	G1 Z2
	M400

	G30 Z-99999 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S1
	G1 Z2
	M400
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S2
	G1 Z2
	M400
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S3
	G1 Z2
	M400
	
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S4
	G1 Z2
	M400
	
	
	G90 ; set true
	G1 Z2 F2000
	M400
	G1 Z{(state.restorePoints[0].coords[2] + state.restorePoints[1].coords[2] + state.restorePoints[2].coords[2] + state.restorePoints[3].coords[2] + state.restorePoints[4].coords[2]) / 5} F100	
	G60 S5

	G90 ; set true
	G1 Z4 F2000
	M400


	echo "Pinda at " ^ sensors.analog[2].lastReading ^ " average trigger at " ^ state.restorePoints[5].coords[2] ^ " millimeters."
	echo "Trigs: "^state.restorePoints[0].coords[2]^", "^state.restorePoints[1].coords[2]^", "^state.restorePoints[2].coords[2]^", "^state.restorePoints[3].coords[2]^", "^state.restorePoints[4].coords[2]

	M28 {"0:/macros/Probe Comp/"^ sensors.analog[2].lastReading ^","^state.restorePoints[5].coords[2]}  
	M29

Kolbi

Granted, I am not sure about the accuracy of the macro, but I did make some additions to it where once it finishes probing on heat up, then it probes on the cool down too. I've run it several times to collect a good average, lots of points. Interesting data. Making me think that maybe I should try raising the pinda temp slower, to stabilize it at every few degrees?

@evan38109 I am curious, what variant of pinda-v2 you and I actually have. I read somewhere there are three PindaV2 variants out in the wild. I am fairly certain I have the latest revision with black wire - it's only about 2 months old as I got it for my Zaribo build. Also would be interested if you ran the macro on your machine to see if it comes close to the data you have already gathered, but if not - I don't blame you

Screen Shot 2020-07-18 at 6.17.33 PM.png
Screen Shot 2020-07-18 at 6.19.28 PM.png


	G32

	G1 X100 Y100 F2000

	M558 P5 C"^zprobe.in" H1.0 F180 T99999 A20 S0.001              ; Set probing to slow and precise
	M140 S100
	M104 S240

while sensors.analog[2].lastReading < 45


	G30 Z-99999 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S0
	G1 Z2
	M400

	G30 Z-99999 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S1
	G1 Z2
	M400
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S2
	G1 Z2
	M400
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S3
	G1 Z2
	M400
	
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S4
	G1 Z2
	M400
	
	
	G90 ; set true
	G1 Z2 F2000
	M400
	G1 Z{(state.restorePoints[0].coords[2] + state.restorePoints[1].coords[2] + state.restorePoints[2].coords[2] + state.restorePoints[3].coords[2] + state.restorePoints[4].coords[2]) / 5} F100	
	G60 S5

	G90 ; set true
	G1 Z4 F2000
	M400


	echo "Pinda at " ^ sensors.analog[2].lastReading ^ " average trigger at " ^ state.restorePoints[5].coords[2] ^ " millimeters."
	echo "Trigs: "^state.restorePoints[0].coords[2]^", "^state.restorePoints[1].coords[2]^", "^state.restorePoints[2].coords[2]^", "^state.restorePoints[3].coords[2]^", "^state.restorePoints[4].coords[2]

	M28 {"0:/macros/probe-comp-going-up/"^ sensors.analog[2].lastReading ^","^state.restorePoints[5].coords[2]}  
	M29	


M140 S0
M104 S0
G4 S60

while sensors.analog[2].lastReading >23
G4 S60

	G30 Z-99999 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S0
	G1 Z2
	M400

	G30 Z-99999 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S1
	G1 Z2
	M400
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S2
	G1 Z2
	M400
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S3
	G1 Z2
	M400
	
	
	G30 S-1
	echo "" ^ sensors.analog[2].lastReading ^ "," ^ move.axes[2].userPosition
	G60 S4
	G1 Z2
	M400
	
	
	G90 ; set true
	G1 Z2 F2000
	M400
	G1 Z{(state.restorePoints[0].coords[2] + state.restorePoints[1].coords[2] + state.restorePoints[2].coords[2] + state.restorePoints[3].coords[2] + state.restorePoints[4].coords[2]) / 5} F100	
	G60 S5

	G90 ; set true
	G1 Z4 F2000
	M400


	echo "Pinda at " ^ sensors.analog[2].lastReading ^ " average trigger at " ^ state.restorePoints[5].coords[2] ^ " millimeters."
	echo "Trigs: "^state.restorePoints[0].coords[2]^", "^state.restorePoints[1].coords[2]^", "^state.restorePoints[2].coords[2]^", "^state.restorePoints[3].coords[2]^", "^state.restorePoints[4].coords[2]

	M28 {"0:/macros/probe-comp-going-down/"^ sensors.analog[2].lastReading ^","^state.restorePoints[5].coords[2]}  
	M29	

M558 P5 C"^zprobe.in" H0.7 F400 T8000 A20 S0.003
M140 S0
M104 S0
G4 S60

Kolbi

Looking at the data for a bit, I believe the curve actually represents the thermal effects on the entire machine and the disparities (saw tooth pattern up/down) represent the probe's ability.

I zip-tied a bltouch3.1 to the extruder and ran the same test, the only problem is that there was no probe temp to base the curve off so I based it off bed temp.
Screen Shot 2020-07-20 at 3.19.42 PM.png

Kolbi

@evan38109 I tackled the temp comp issue by changing to a BLTouch - had to modify the BMGm in CAD but it was worth it, very clean and accurate install. I believe you also have a BMGm, so this might interest you:
Screen Shot 2020-08-01 at 10.40.16 AM.jpg

Cheers,
Kolbi

evan38109

Hey @Kolbi,

Sorry, I have email notifications off and missed your latest posts until I came to the forums to check something else!

That BLTouch mount is pretty impressive. How did you print it? Also: are the files available on Thingiverse or elsewhere? I'm pretty happy with my PINDA for now, but I do tend to get itchy for new experiments...

I'm racking my brain for why your measurements wound up so much different than mine. I've found my PINDA to be pretty darn stable. I've never needed more than +-0.10 babystepping for a nice first layer, regardless of the temperature at which I zero the machine. I'll keep turning it over in my brain, but...I've got nothing.