Octoprint: [Brainstorming] How to handle gcode script errors

[kantlivelong]

Currently a variable error in a gcode script will cause the script to not run. This can be problematic/dangerous in certain scenarios. (e.g. start script does homing/probing and errors, gco continues to run, hotend crashes into bed)

There are a handful of ways that this could be approached but I'm not sure which would be best.

My ideas:

1. Abort the entire print on error. (Possibly make this an option per script?)
2. Provide an abort function and require the script to do the sanity checks.

[joshwills]

Modified from IRC:

Some commands won't cause a print/printer issue if they do not receive a variable; M117 for instance should just not display anything to the LCD if the variable isn't filled properly. Other commands (temperature setting, moves, tool switching, etc.) _will_ cause trouble if not filled. If a black-/white-list was implemented of commands that are "safe" if unfilled, and definitely "dangerous" if unfilled, then option 1 above could be implemented while still avoiding print stops on non-critical errors.

[ntoff]

When has any host program ever done any sort of script checking? I'm all for being safe but how far do you want to go?

There comes a point when a user must take responsibility for checking their gcode, especially if they're customising the start script and don't know what they're doing. How many checks and popup boxes do you want to put into octoprint (with accompanying settings pages to disable the warnings) before all that processing becomes a burden on the users and the hardware running octoprint?

Should we sit and wait for 2 hours before every print so octoprint can parse the entire file and check for weird errors and pop up things like "hey, I noticed you've got a temperature of 270 degrees at line 10, are you sure that's what you want?". Or another check and another popup "It looks like your acceleration values are too high for a cartesian machine, this could cause print quality issues, are you sure you wish to proceed?"

If you're talking about octoprint's own built in variables, who's to say someone hasn't written a plugin to extend them at some point? If you check for variables that don't exist in vanilla octoprint and just refuse to run, but the variables were added by a plugin, what then?

To me, anything manually entered into anything, anywhere, any time, should be up to the user to check over and ensure they have the correct information entered. There's far too many variables (no pun intended) to ever cover every single situation that might arise in the future, and you could end up blocking something legitimate.

[kantlivelong]

@ntoff

Plugins can now provide gcode script variables which is why I bring this up as it could become a problem in the future. I'm all for dropping the error handling on the user but IMO at a minimum we need a way to abort the print if an error occurs.

Something simple like:

{% if variable is not defined %}
{% abortPrintJob() %}
{% endif %}

[foosel]

I think the abort callback option sounds like the better of both options. It still puts the responsibility on the shoulders of the person writing the script (that should match what @ntoff said and what I also agree with) but also allows graceful handling of errors.

The only problem is, I'm not entirely sure how to do it. Templates get evaluated on the whole, then enqueued. I'm not sure how to tell Jinja here, "btw, when you see something that looks like this, cancel the print". It's been a while since my last deep dive into Jinja.

Alternatively we could also just add some general commands interpreted by the system, e.g. @cancelPrint (it might make sense to see what other hosts support here). In that case you'd have something like:

{% if variable is not defined %}
@cancelPrint
{% endif %}

but you could also just type that into the terminal if you are feeling like it and it would do the same. So no custom handling for the GCODE scripts.

[kantlivelong]

That makes sense to me. Could be worth implementing a handful of commands.

• @cancel
• @abort (alias of @cancel)
• @pause ( #324 )
• @resume

[foosel]

I remember that repetier host has a set of these. Might make sense to look for a list and try to match up identifiers instead of creating a competing set.

[kantlivelong]

https://github.com/repetier/Repetier-Host/wiki/Host-Commands

Not very many based on the above. Seems like we would want to handle @pause differently for OctoPrint. (e.g. Resume with @resume instead of a dialog.)

[foosel]

I need a bit of help here to determine the status of this... I marked it as solved after implementing host commands, but do we actually consider it solved?

[Jonty]

I have just had an extremely annoying situation where my prints repeatedly failed because I had a plugin referenced in the gcode "before print job" section that I'd uninstalled, and my printer was no longer bed levelling because the gcode script wasn't executing. It took me ages to figure this out.

Errors in custom gcode really need to be flagged up somewhere - personally I'd expect the job to fail and a dialog to pop up. Could things like broken templates be flagged up at the time you attempt to save them in settings?