Question about G29

Phaedrux

Instead of just 0 for the S value why not 0.001?

fcwilt

Instead of just 0 for the S value why not 0.001?

Well the description said the two consecutive readings had to match within the S amount.

And the readings from the probe, at least as far as they were displayed, when the differed they always differed by 0.01.

Sometimes the readings matched and the probing at that point ended and it moved on to the next point.

Sometimes it never matched, reported the error and stopped - which is discussed anywhere that I could find. Supposedly with no matches it would average the 10 readings and that would have been fine.

Certainly won't hurt to try different values for S - which I will do.

Frederick

Phaedrux

I was mostly just curyif it behaves the same with a zero value as with a non zero value.

token47

I have this problem also. Something is not right.

The documentation at

https://duet3d.dozuki.com/Wiki/Gcode#Section_M558_Set_Z_probe_type

says that: "The A and S parameters control multiple probing. Probing is repeated until two consecutive probe attempts produce results that differ by no more than the S parameter; then the average of those two results is used. However, if the number of attempts specified by the A parameter is reached without getting two consecutive results within tolerance of each other, no further probe attempts are made and the average result of all the attempts is used."

But, what happens actually is that an error is raised and the G29 stops completely. This happens even when G29 comes inside a gcode from a slicer. So it will probe a few points and abort, then start printing without completing the mesh.. This is wrong and is not predictable behavior. I would expect at least the whole print to abort, if not doing what the documentation says (which would be way better).

I just forced an error turning the S parameter of M558 to S0.00 as @fcwilt suggested. It spits

12:47:58 AMError: Z probe readings not consistent

on the logs and abort. It should do as the doc says and continue. Shouldn't it?

I just noticed this when I saw a G29 failing and the print starting anyway.

Thank you!

fcwilt

Hi,

Thanks for verifying that you can reproduce the same behavior.

Frederick

dc42

I'll change it in the next 2.02RC so that a zero or negative tolerance causes it to average all readings and not treat it as an error.

fcwilt

@dc42 said in Question about G29:

I'll change it in the next 2.02RC so that a zero or negative tolerance causes it to average all readings and not treat it as an error.

That will be grand.

Thank you.

Frederick

token47

@dc42 That is great (and please do it) but it may not solve both problems.

One problem is a way to force doing all the probes and averaging them. Treating 0.00 as a special case to do that will solve this one.

Other problem is having a non-zero value, and still not being able to find two readings whose delta is below that value, even making all the possible readings. It should then just average all the readings, but it gives an error and aborts the G29. This is different from what the documentation says it should do.

I think this second problem is a bug, what do you think?

Thank you!

dc42

i agree that it does not accord with the documentation. What would users prefer: to abandon the mesh probing when the readings are inconsistent, or to use an average? The advantage of abandoning mesh probing in this case is that you don't have to wait for it to finish before you try again.

fcwilt

@dc42 said in Question about G29:

i agree that it does not accord with the documentation. What would users prefer: to abandon the mesh probing when the readings are inconsistent, or to use an average? The advantage of abandoning mesh probing in this case is that you don't have to wait for it to finish before you try again.

Perhaps another parameter which determines the behavior of the existing parameters?

That would allow existing config files, etc to function as things are now but allow for new behaviors without using special values.

Frederick

token47

@dc42 I like being able to choose between both, as @fcwilt said. But, if forced to choose, I would prefer for it to follow documentation (average all readings and not abort). That is a must when you send a G29 from the start script of a slicer, unless the whole print would abort too (what happens today is that the G29 aborts and the print continues).

brunofporto

@token47 @dc42

Maybe configure like this:

Negative values: measure and if differ more than the S parameter use the average and print the error - but go on printing with the average.

Zero: Always use the average

Positive: Cancel print if measure something bigger than S parameter.

SupraGuy

I can't see a way that the G29 command can abort the print job, given that there aren't any conditionals in gcode, unless it forces some kind of fault condition that shuts down the firmware requiring a reboot. Until such time as gcode has an "if" statement, but I don't see that coming soon.

I don't know that I'd want to average all values either. If I get one false trigger at Z=5, then 9 good triggers at -0.2 < Z < 0.2 my average will be about 0.5 too high. Personally, I'd rather that have a 0 entry in heightmap.csv for a "didn't probe there." which ought to cause the firmware to average the points that surround the bad probe point. Of course it depends on how many times you get a bad value from your Z probe. If yours is prone to false triggering (Which is the reason for multiple probes,or so I thought) then you could get some really wild average values.

So my preference would be to use a median value, rather than a mean, under the hopes that there would still be more good readings than false triggers.

brunofporto

@supraguy Agreed.

dc42

@supraguy said in Question about G29:

I can't see a way that the G29 command can abort the print job, given that there aren't any conditionals in gcode, unless it forces some kind of fault condition that shuts down the firmware requiring a reboot.

There are already situations in which a fault stops a print job, such as trying to move axes before they are homed, or trying to move outside the print area when the machine is in CNC or laser mode. So a failing G29 could be treated in the same way.