[Request] Allow plugins to override error handling behaviour

[zdar]

My printer sometimes triggers Err: MINTEMP. At this point OctoPrint disconnects.
I'd like to ask if there could be an option in configuration to change octoprint behaviour (no disconnect; pause print).

Usually M999 resets the error and print can continue without hassle. With current hard disconnect (causing printer and print reset) lot of salvageable prints is lost.

What would be even more helpful? To be able to define actions to be triggered on errors. For example send command(s), wait for user, etc. But this is more plugin work I guess.

[JustAnother1]

I like the Idea of having hooks so that plug-ins can react to different failure events. They then need to report back if they fixed the issue or if the error is still present.

But the more important question is here why does your printer report the "Err: MINTEMP" at all. Is there something wrong in your printer or your configuration ? I don't think that we want to do a cover up for broken hardware. Or do you have a valid reason / special use case that causes this?

[JustAnother1]

But wouldn't it be better to fix the firmware on your gen6 Board? The firmware could do more averaging on the measured temperature.

Octoprint shows the temperature while printing. How does that look like. Is the temperature basically a flat line (especially if you are not printing) and is cooling down and heating up a smooth curve?

If the firmware gets the wrong temperature once in a while than that could influence the quality of your print. Fixing the firmware would therefore also get you better prints.

[zdar]

Reason for my request is is that Octopi going offline every time any error happens is extremely annoying. I have to reconnect Octopi manually to be able to fix the error (M999 via terminal). And I see no reason for Octopi to disconnect itself after error. The printer still reacts and reports it's state - why to disconnect then?

---

Yes. It is hardware related. I happens almost every time I connect cold printer which points me to something transient on the board. Most probably there is some noise sneaking into temperature sensing of my gen6 (sensor and cabling is Ok). Simply one of many many measurements is off and trips this error.

[foosel]

My I direct your eyes at this under Settings > Serial Connection:

That's been there for a while and unchecking it should do exactly what you are looking for. Has been in there since OctoPrint 1.2.9 if I'm not mistaken.

Right now when this setting is set, an error while not printing will simply be ignored (and if you are printing, the job will be cancelled but the connection will persist). No "Error" event will be fired on the bus either. Maybe changing the latter will already allow to do what you two are thinking about with regards to allowing plugins to react to errors?

---

PS: OctoPi and OctoPrint are not the same thing, one is an SD card image including the other, which is what controls your printer. Please don't use those names interchangeably, it makes support so much harder.

[zdar]

My apologies. Somehow overlooked this. It mostly solves my problem (although I do not like blind error ignore - whitelist would be better).

I'm not fully familiar with OctoPrint code but I belive that plugin should be able to intercept the Error before it reaches this two "final" options (no need for change here). I'm not sure if it is now possible via octoprint.comm.protocol.gcode.received e.g. If error is detected and acted upon before plugin kicks in (and clears it). Maybe dedicated octoprint.comm.protocol.gcode.error would be nice API addition.

[foosel]

It would already be possible to hook into octoprint.comm.protocol.gcode.received, detect the error ("line starts with "Error:" or "!!"), handle it and rewrite the received line to nothing, effectively stopping OctoPrint from further handling it. Those GCODE hooks are basically the first and last thing between OctoPrint and the actual serial interface, so they have a lot of power in manipulating what OctoPrint sends and receives from the printer.

A dedicated error hook indeed might make for a neat addition though (less processing overhead to add dedicated error handling).

[jneilliii]

Not to give you too much of a scare @foosel, but I'll take a stab at that plugin.

[jneilliii]

I have the initial framework up and running. It will process any command starting with the word "Error" received from firmware and has options for disconnecting and running system commands.

The way I tested was with the virtual printer and sending a terminal command !!DEBUG:maxtemp_error. It returns the string "Error: MAXTEMP triggered!" which is a default response being checked by the plugin. Adjust the error message according to your situation/firmware in FirmwareErrorHandler settings.

Please post issues/requests in the plugins repository, which can be found at the link below.

https://github.com/jneilliii/OctoPrint-FirmwareErrorHandler

[foosel]

@jneilliii I don't get scared that easily ;)

Just for the record: !!DEBUG:send <some text> is basically what you are looking for. Will send back <some text>, so !!DEBUG:send Error: Oh noes broken! should result in an Error: Oh noes broken! coming back from the printer.

Still leaving this open however for the error handling hook since it makes sense considering that it won't require every returned line to be parsed by both a plugin AND OctoPrint, and also there are some errors (e.g. line number mismatches and checksum errors) that precede a resend request which do not need to be handled further.

[foosel]

octoprint.comm.protocol.gcode.error is now available on maintenance, soon devel, and will be part of the 1.3.7 release.

[foosel]

Closing as 1.3.7 was just released.