Question about G29

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.