Saving M208 (axis min/max) values in config-override.g possible?

NeoDue

I finally got my Duet into my Snapmaker J1 - with some additional resistors, diodes and capacitors everything works as intended for now. (Thanks @dc42 for the numerous corresponding hints here in this forum that I could use.)

Now I finally have the chance to try and optimise my gcode version of the Snapmaker calibration routines - and as expected it does not work as intended on a real machine...:

The intention behind the full code of the guided bed leveling routine is to

move to probe point 1,
do six z probes and
take the average of these values which is the reference value
use this value to correct the z axis limit and save that one
move to point 2,
do one z probe, display a message with a bar-graph-like representation of the measurement value that tells the user how to turn the adjustment knobs
wait a couple of tenths of a second (mainly to give the PanelDue time to digest) and go back to step 6 until the measurement value is within a specified range
8 then go on to point 3 and repeat steps 6 and 7 there.

Things that work:

measuring the reference point (abusing G38.2 - G30 keeps spitting out messages that I do not want) and updating with M208 works
the "bar graph" messages pop up as they should with simulated data

Things that do not work (yet):

saving the updated z axis min/max value.

I thought that M500 would do this, but it seems I was wrong.

Does anyone know how to do that...?

Phaedrux

@NeoDue said in Saving M208 (axis min/max) values in config-override.g possible?:

I thought that M500 would do this, but it seems I was wrong.

https://docs.duet3d.com/User_manual/Reference/Gcodes#m500-store-parameters

Any M208 axis limits that were determined using a G1 S3 move

I don't quite understand how you're trying to determine the Z axis min max from your description.

NeoDue

@Phaedrux G1 H3 (I guess, since the notes say that G1 S sets laser power) works with endstops only. What I am doing (or rather must do due to the endstop configuration of the Snapmaker J1 - z endstop at max, z probe at {z min - print plate thickness} ) is

do a z probe (or rather six and calculate the average, to minimise any offset error caused by a drop of filament)
read out its value from sensors.probes[].lastStopHeight
calculate a new z max value
and save it.

I did consider temporarily remapping the z endstop to the z probe since that would be a possible solution for my G30/G38.2 issue, but that would invert the homing direction. Together with the fact that the z probes only work if the corresponding printer nozzle is at a predefined position, I very much fear the possibility that the script might fail for any reason and not reset that remapping - in that case any subsequential homing move would cause mechanical damage... unless I overlook a possibility to reliably solve that

Edit: maybe the gcode makes the whole issue clearer:

; initialisation etc removed for clarity

G1 H2 U115 Y-94 F3200					; move to first contact point
M400								; wait
G1 H2 Z{-global.Druckplattendicke + var.Startheight} F6000	; move bed to measurement height
M400								; wait

; 1. measurement sets z reference for the next two points which then need to be corrected manually by turning the screws
while iterations <=6
	G4 P{var.Waittime}				; wait
	G30 S-1 K1					; measure Z with right hotend
	set var.Referenceval = var.Referenceval + sensors.probes[1].lastStopHeight
	G1 H2 Z{move.axes[2].machinePosition + var.Startheight} F3000				; lift z
set var.Referenceval = var.Referenceval / 6

; update z values
; example:  var.Zmax = 209  -    (-3.98)       -      5   = 207.98
var.Zmax = move.axes[2].max - var.Referenceval - global.Printplatethickness  ; calculate new z max
var.delta_z = move.axes[2].max - var.Zmax	; not really necessary but makes following the calculation easier
if var.Zmax < 216				; unless the new value is not out of bounds
	M208 Z{var.Zmax} S0 			; update z axis max limit
	G92 Z{move.axes[2].machinePosition - var.delta_z}			; update current z value
	; M500												; save axis limit - does not work
else
	M291 S2 P{"the calculated error is "^var.Referenceval + global.Printplatethickness^ "That value causes the z axis limit to be out of bounds."}  R"Abort"

; now the code that tells the user how to turn the wheels on the two other measurement points follows...

But: that is the smaller problem I have. I can circumvent the whole saving procedure if I tell the user to turn the first wheel as well - less elegant but it works. The much bigger issue is this one - I cannot make a probe move without a message even if the gcode dictionary says otherwise...: https://forum.duet3d.com/topic/33675/g38-2-much-less-precise-than-g30-and-moving-wrong-axes-bug

Phaedrux

@NeoDue said in Saving M208 (axis min/max) values in config-override.g possible?:

z endstop at max

If you already have an endstop at Zmax, just use the probe to measure the Zmin point, and then do a G1 H3 move to zmax to measure the full size of the z axis and then M500 will save it.

But maybe I'm totally missing what you're trying to do.

NeoDue

@Phaedrux I fear you lost me there

Let me try to repeat what I understood:

do the bunch of required z probes with G30
calculate the average and use that value to update the current z value with G92
then do a G1 H3 to zmax and let M500 save the value it finds
move z back up and continue with manual bed correction at the other measurement points

Did I understand that correctly or am I wrong?

Phaedrux

That's basically what I do with this macro to measure the length of the Z axis.

; 0:/macros/Bed Leveling/0_Measure Zmax trigger.g
; Automates measuring the Zmax trigger for optical endstop at 305mm
;
M291 P"This will set Z0 and calibrate Zmax height to 305mm" R"Proceed?" S3
M291 P"Homing all axis" T5
G28			; Home all
G90			; Absolute positioning
M291 P"Ready to test Zmax homing?" R"Proceed?" S3
M291 P"Homing to Zmax" T5
G1 Z350 H3 F400		; home to z max and set the trigger height as the M208 Z maxima
M500 ; save the measured M208 Z maxima to config-override.g
M291 P"ZMax homing test complete. Printer will now home all." R"Proceed?" S3
G28	; Home all
M291 P"ZMax calibration complete." S3

And if you didn't want to rely on the probe, you could touch off the nozzle to the bed and set Z0 that way.

M98 P"0:/macros/0_Center Nozzle.g"	; Move nozzle to bed center	
M291 P"Adjust nozzle height until it's touching bed" Z1 S3
G92 Z0 			; set Z0

deckingman

@NeoDue Forgive me but I fail to see the use case of what it is that you are trying to do. Unless the machine undergoes extensive modifications the axes limits will never change. So it seems to be to be a lot of effort in order to avoid typing one single command on one single occasion.

In my humble opinion, the use of config-override.g is something that should be avoided. So many people (including me) have been caught out so many times when they have tried to make changes to their configuration which have had no effect (because those changes are being overridden). They eventually realise that they have to look in two different places to find which configuration command is being applied.

NeoDue

@Phaedrux thanks a lot! Okay, taht would be an option. I will try that. But "just touching" is no option for daily use here, at least for now - my printer has a nozzle contact and four (three flat ones for bed leveling and one square hole for XY calibration) inside the print bed, which massively facilitates tuning the two IDEX printheads towards each other.

This requires however the print plate to be placed above all that before I can print - which then means the z sensor is nonfunctional in that state. Thus, it is not useful for z homing.

@deckingman you are basically right, but the printer I am working on has swappable hotend modules. Whenever I choose another one, I need to recalibrate z - and that means either doing a full bed leveling process (if z max is left unchanged) or updating z max and save that value...

Edit: in case you are curious which calibration I try to recreate here in RRF and therefore in a fully open source environment, take a look at this video: https://www.youtube.com/watch?v=ZNXBElBMDtI&t=140 (you may skip the first 2min). That first set of probes in the back centre will correct Z and then you can turn the front screws (which is where the inability of G30 to not dosplay a message drives me crazy, but that ist another topic here in the forum)

deckingman

@NeoDue Can't you just a different Z offset for each tool (hot end)? That's the normal way of doing it. No need too keep changing the axis limits.

NeoDue

@deckingman Hm, I just follow the "defining tool and z probe offsets" manual here - the tool tip of the x carriage is the head reference point, and the second carriage will be (manually) leveled to that height.

Adding a tool offest which then would be the same for both tools might work however (provided that one is saved then with M500) - I had thought about that earlier but discarded that idea because of the warning in the gcode ditionary "It's usually a bad idea to put a non-zero Z value in as well..."

The printer has to wait today, but I will test that as soon as possible. If that works, I have a solution that does not require a full down-up-cycle of the bed. Thanks!

NeoDue

@deckingman One more question: let's say I have a tool offset of 1mm, i.e. the bed needs to go to -1mm to compensate for that. Which value is the bed motion limit then when this tool is active - 0mm as defined by M208 or -1mm which then would be 0mm for the active tool? If I understand the manual correctly, M208 values will not change - which in turn means I either need to define the worst possible case (shortest hotend module) in M208 and live with the collision risk if a longer hotend is mounted (which makes me fear for the glass plate... ) or cannot use that idea.

dc42

@NeoDue RRF doesn't allow you to save the M208 limits to config-override.g. However, you could save them to a different file in your macro, and then run that file as a macro in config.g.

NeoDue

@dc42 thanks a lot! That sounds like the best option!

(offtopic: Regarding your question on Github about G30: I will add the script later today, I do not have my Github login at hand on my mobile phone.)

NeoDue

@dc42 final update for this: your suggestion works like a charm, thanks a lot!