I have found that G29 is NOT the same as G29 S0.

fcwilt

Setting the Z=0 datum once may not be sufficient because it can change as things heat up/cool down.

Thus it is best to do it at the times I have stated.

As to G29 not working I don't understand how that is possible since the hardware being used should make no different, only the firmware.

But that is assuming that the firmware builds are the same for each platform. That is not something I can determine.

A Former User

This post is deleted!

Phaedrux

@nuramori said in I have found that G29 is NOT the same as G29 S0.:

The G30 S-3 has removed my need to deal with z axis calibration every time I swap them, so after having the command work for me based on a lengthy experimentation period (eliminating having to deal with the nozzle height changes), led to me just leaving it in.

I think this is only working out for you by accident. You can't calibrate the trigger height unless you're the one providing an accurate Z0 point manually. That's where you would jog the nozzle to touch the bed and send G92 Z0 to set the known position and then measure the trigger height either with G30 S-1 (report trigger height) or G30 S-3 (set the current trigger height to what it measures).

Just doing G30 S-3 after a G30 will only give you the same trigger height you had when you initially measured it and set it in G31 Z.

So it's not hurting, but it's not really doing anything.

The intention of G30 S-3 was for use in macros where you would have prompts to set Z0 and then to the trigger height measurement and have it applied automatically, you could also add M500 P31 to save the resulting G31 Z trigger height to config override to be reloaded at each power up.

Regardless, the main point of the thread was around the functioning of G29 and G29 S0.

Can you confirm again for me whether sending G29 with mesh.g not present functions to probe the bed and activate the mesh?

fcwilt

@arnold_r_clark said in I have found that G29 is NOT the same as G29 S0.:

Very Interesting, can you please provide a link to the documentation which provides citation of that fact, I would like to research this further.

From the Duet Gcode documentation:

If G29 is commanded with no S parameter, then file sys/mesh.g is run if it exists, otherwise the command behaves like G29 S0.

I know this is the case on my Duet hardware for firmware 3.2.2 and 3.3.0 with no SBC connected.

Frederick

Phaedrux

@fcwilt Thanks for testing.

fcwilt

@phaedrux said in I have found that G29 is NOT the same as G29 S0.:

@fcwilt Thanks for testing.

I suppose it is possible that the firmware build for hardware other than mine (Duet 2 WiFi, Duet 3 Mini 5+, Duet 3 MB6HC) might have a bug but of course I cannot test that.

What I haven't tested is what happens if you execute a G29 inside mesh.g - that could be interesting.

I use mesh.g for my printer but inside is a G29 S0.

Frederick

A Former User

This post is deleted!

fcwilt

@arnold_r_clark said in I have found that G29 is NOT the same as G29 S0.:

Thank you for the information.

So from the documentation the key word is "IF" as IF no mesh.g file exists then G29 (no additional parameter) automatically morphs into G29 S0 .

Correct.

And if you have a mesh.g file without a G29 S0 (create height map) or a G29 S1 (load height map) then executing G29 will run the file but mesh compensation will not be enabled.

Frederick

Nuramori

@phaedrux I should note I am using an SBC with my duet3. Perhaps that’s the one element that’s making a difference in the results.

Phaedrux

@nuramori said in I have found that G29 is NOT the same as G29 S0.:

@phaedrux I should note I am using an SBC with my duet3. Perhaps that’s the one element that’s making a difference in the results.

Could certainly be the case.

chrishamm

@nuramori Thanks for the report, I am looking into it.