[FR] Bed levelling - prevent print if deviation is greater than X

[totalitarian]

OK so I have installed a piezo probe. Occasionally it gets a false trigger and seriously screws my mesh up. I suggest that we set a deviation limit, so for example, if the distance between my highest bed point and lowest bed point is more than 2mm, the printer will say probing failed. Personally I think this would be a good safety measure to prevent crashes/failed prints.

[fiveangle]

Good idea ! Makes me wonder if it isn't implemented somewhere in the code already (although I don't immediately see anything).

[thinkyhead]

I've also been thinking about this. So, something like…

#define FAIL_ON_DEVIATION 1.5   // Assert min / max probe heights can differ no more

If this is checked on every probe, you could effectively abort probing by blocking the probe.

In general, I very much want to improve the niceties of Marlin so that its behavior "out of the box" is more smart. Or, at least offer options to customize behavior to make Marlin respond more intelligently to events. For example, if you blocked the probe and aborted probing, there could be an option to set G-code to execute in that event, which might default to "G91\nG0 Z10 F999\nG90".

In line with that, I'm trying to concoct a system so you can customize the Info Screen and put each element where you want. So, instead of XY, how about Total Extrusion? That could be an option. You could put custom graphics around the screen… or, whatever. The way we now have M600 happen in response to filament runout is good, but might need to be more "friendly" in explaining why it stopped, etc. That kind of spit and polish goes a long way to improving the day-to-day experience of using Marlin.

[totalitarian]

I agree - UX needs a little tune up to make 3d printing more friendly. The latest prusa i3 mk3 and their fork or marlin is certainly trying to achieve this.

Anyway, would love to see this implemented. Looked through the source this morning but unsure where to even begin will hacking in this feature.

[maciek134]

I can take a look at this, but I don't have any Marlin-operated printer at the moment, so someone else would have to check if the changes work in practice.

[thinkyhead]

Personally I think this would be a good safety measure to prevent crashes/failed prints.

True. Of course if your G-code contains G29 the failed G29 won't stop the print. It will just continue after it fails.

[sr005307]

Just like a blind bulldozer, the nozzle scraps the bed severly.

Please update this feature.

It seems that it only takes a few line of codes.

[thinkyhead]

For full host safety if G29 seems to be giving bad results, best thing would be for Marlin to go to kill() requiring a hard reset.

[AndrewTilson]

Ok im looking at how i can contribute to this project and starting with this issue as its marked "good first issues" I have spent probably a hour now looking through the code trying to make out where this logic would go. Best i can tell is it needs to go in marlin_main.cpp inside of 2nd gcode_G29 near the end im guessing right after or before z_probe_end_script inside of the OLDSCHOOL_ABL elif and inside of the first gcode_G29 MeshSet case? I come from a c# background so im finding myself googling a lot like what is the inline keyword. Also im confused by the gcode_G29 method existing twice inside of marlin_main.cpp. Im not understanding how when this is called it knows which instance of this method to execute when called. Sorry if any of this is considered beginner questions.

[Roxy-3D]

Also im confused by the gcode_G29 method existing twice inside of marlin_main.cpp.

Some of them are stand alone .cpp files. There are 5 G29's....

[AnHardt]

@AndrewTilson We do make intensive use of the 'C PreProcessor' CPP to decide what parts of the code are compiled in and what are excluded.

[Roxy-3D]

It is fine to add things to Marlin_main.cpp to prototype and check stuff out. But anything large like a new G29 should be broken out into its own file. We are actively trying to shrink the size of Marlin_main.cpp. So, if it is a few lines of code to supplement something else that Marlin_main.cpp is already doing... Fine... But we don't want to be adding a lot of bulk to it.

[AndrewTilson]

Thanks @Roxy-3D. I figured out the multiple methods as they are defined one in the if and the other in the else block. :) I will keep looking more at this tonight to see if i can help with this issue/feature add. Is the expectation that it errors out like out of temp does and the arduino must be reset after this error?

[Roxy-3D]

Pretty much... any error detected should let the user know about the problem and ideally the firmware should recover. But for really bad problems... kill() will shut down the printer.

[thinkyhead]

I favor the approach of using kill() if the deviation is severe enough during a single probe to cause the probe to go below the bed. We could actually limit the probe so that it will never go more than 1 or 2mm below the bed. This can prevent damage in many cases.

We don't want to go to kill() in the case of the probe going too low until the probe has been raised back up again, obviously, so that's a consideration.

If the G29 completes but there's too much deviation overall then we don't have to go to kill() and can just throw up a "Err: Bad Mesh" message and reset the mesh to zero.

[evg-zhabotinsky]

Just a thought: The initial issue was about probe triggering prematurely / randomly. Probe moves towards the bed when it happens, so it cannot have crashed yet. Consequently, nothing should be stopping us from simply redoing that single probe that seems to be too far off. Kill()ing should be reserved for when probe triggers late or not at all, to avoid ramming the bed. As for retrying, there already is an option of averaging multiple Z-probes for every point (which isn't implemented for the initial Z homing, by the way), and I'm pretty sure it could be easily augmented to throw away bad samples.

[thinkyhead]

when probe triggers late or not at all, to avoid ramming the bed

We now have a helpful setting Z_PROBE_LOW_POINT to prevent the probe from going so far past the bed that it can cause damage.

I'm pretty sure it could be easily augmented to throw away bad samples

It's a good concept.

[boelle]

@totalitarian did the new setting Z_PROBE_LOW_POINT do the trick?

[jball1997]

Is this issue still open or should it be closed?

[totalitarian]

Sorry people, appreciate the effort but after nearly 2yrs, I no longer have a marlin based printer so can't comment if the issue is resolved.

[thinkyhead]

No worries. This extra bit of just-in-case bounds-checking is on the TODO list but we have been taking our time so as not to bloat this feeping creature too rapidly.

[Geno117]

This issue is just waiting testing or confirmation, is that right? If not, could I have a go at it?