G28 error should stop the print

fcwilt

I've noticed something similar.

I have a printer that uses Auto Bed Leveling with three Z steppers.

If there is an error probing, say, the 1st point it does not stop but continues to probe the 2nd and 3rd points.

Only then does it report an error.

Frederick

o_lampe

@fcwilt said in G28 error should stop the print:

report an error

Only report?
There are three different colours in DWC console messages:
green, orange, red
The red colour indicates an error and it should trigger an action, like pause
Otherwise there is no reason to separare warnings from errors

fcwilt

@o_lampe said in G28 error should stop the print:

Only report?
There are three different colours in DWC console messages:
green, orange, red
The red colour indicates an error and it should trigger an action, like pause
Otherwise there is no reason to separare warnings from errors

I wasn't in the console. The message was a standard popup saying there was a probing error.

I simply see no point in continuing to probe additional points once a point fails - the entire process cannot complete so abort it and save time.

Frederick

OwenD

You have the option of checking the success of any GCode issued using the "result" meta-code
result int 0 if the last G-, M- or T-command on this input channel was successful, 1 if it returned a warning, 2 if it returned an error. Meta commands do not change 'result'.

So if you want to abort you just test for a result not equal to zero.

e.g.

G1 H1 Z-9999
if result !=0
    abort "Error occured - job cancelled"

or maybe

G1 H1 Z-9999
if result == 1
    M291 R"Probe warning"  P"Probe reports a warning.  OK to continue, CANCEL to abort" S3
elif result == 2
    abort  "Probe error.  Macro & print cancelled"

Note that in some cases, such as if you are doing automatic bed leveling, then you actually want to continue when the result doesn't equal zero.
This example is given in the bed.g example here.

It's a little hard for the firmware to stop a crash into the bed due to a faulty probe as you've specifically told it to move until the probe triggers.

I can see the argument for automatic cancellation, but I think being able to react as you choose is far more powerful albeit requires more thought on behalf of the user.
It's easy to say that a failure in G28 should cause the printer to stop, but as G28 simply starts the homeall.g macro, any such cancellation won't come till after that macro ends anyway. And in that case, if it calls G28 and the macro returns then wasn't the call to G28 successful? One could argue that it would only be unsuccessful if for example homeall.g did not exist, so in many cases you're damned if you do & damned if you don't.
For mine it's better to get used to coding with the expectation that there may be an error and acting accordingly.

fcwilt

@OwenD said in G28 error should stop the print:

You have the option of checking the success of any GCode issued using the "result" meta-code
result int 0 if the last G-, M- or T-command on this input channel was successful, 1 if it returned a warning, 2 if it returned an error. Meta commands do not change 'result'.

That is good to know - first time I heard it mentioned.

Thanks.

Frederick

o_lampe

@OwenD said in G28 error should stop the print:

It's a little hard for the firmware to stop a crash into the bed due to a faulty probe as you've specifically told it to move until the probe triggers.

OwenD your my HERO!
But in my case the nozzle didn't crash while probing, but after the result was bad.
I mean, why is there a parameter to probe X-times with a probe threshold, when a failure has no consequences?
Funny, that this wasn't discussed earlier? (AFAIK)

o_lampe

@OwenD said in G28 error should stop the print:

G1 H1 Z-9999

I replaced that line with G30 and now I don't get Z=0 datum not set when I load the heightmap.

IMHO the simple result !=0 check will do. In my case I get an error or no message. Checking for result=1 is not necessary.

OwenD

@o_lampe
Yes, G30 is what you need in your case.
I'm on a business trip and only have phone access, so my example was perhaps not the best.
As long as you check result!=0 after each probe you should be good.
The other example was simply to show that there are other options.

fcwilt

@OwenD said in G28 error should stop the print:

Yes, G30 is what you need in your case.

I tested it and it does work. It cluttered my code a bit though. I use M291 a good deal to display progress messages. The abort message doesn't show up in the same way a M291 message does. So as a quick fix for each test of "result" I added a M291 and then abort.

I think further thought will reveal a less redundant approach.

Thanks.

Frederik

OwenD

@fcwilt
My idiom when programming is that if it takes 10 lines of code to do the job, it will take a further 100 lines of code to stop people doing it wrong and fix errors.