Error Handling Mechanism

[justus2342]

(Yes, I have seen this topic. But it does not answer my question.)

I would like to pause print automatically in case of a problem. That problem could be a failing G29 or a accidental violation of the axis limits during the print. Because those problems are very likely indicators for a failing print and (in case of failed G29) might result in hardware damage, if the nozzle crashes into the print bed.

I worked around a failing G29 with using G32 instead and use a if-metacommand to pause if G29 returns an error. But that is a workaround which does not work, if G29 is called.

I am looking for a general error handling method. Maybe a gcode-file that is called in case of a warning or another gcode-file in case of error.

Is there any system-wide error handling mechanism? Or is there any common workaround to catch errors in general?

[droftarts]

@justus2342 This might be what you are looking for https://docs.duet3d.com/User_manual/RepRapFirmware/Events
Have a read of that page, and let us know if you have any questions.

Edit: you can make the logic conditional using Meta/Conditional Gcode. See https://docs.duet3d.com/User_manual/Reference/Gcode_meta_commands

Ian

[justus2342]

@droftarts Thank you for your reply. Yes, I already found that part of the docs. It says:

An event is one of the following:

• Heater fault
• Filament error
• Driver stall
• Driver error (e.g. over temperature shutdown, short-to-ground, or closed loop driver error failure to achieve the requested position)
• Driver warning (e.g. over temperature warning, or phase disconnected)

Other event types may be added in future, for example MCU over-temperature on a main board or expansion board, or over- and under-voltage.

But this is handling of just those five specific error-types, not errors in general. Or have I misses/misunderstood something? Especially the both cases I mentioned (move outside axis boundaries and G29 error) seem not be to covered.

[dc42]

@justus2342 said in Error Handling Mechanism:

I worked around a failing G29 with using G32 instead and use a if-metacommand to pause if G29 returns an error. But that is a workaround which does not work, if G29 is called.

G29 calls mesh.g if it exists, and if it does not then behaves like G29 S0. So you can create a mesh.g file like this:

G29 S0  ; probe the bed
if result > 0
  abort "Bed probing failed"

Please test this on your machine before relying on it.

G0/1/2/3 out-of-reachable-area errors abort the job if the machine is in CNC or laser mode. In FDM mode they do not, instead they limit the coordinates to the accessible area, because it is not unusual for parts of the skirt to fall just outside the printable region.

[justus2342]

@dc42 said in Error Handling Mechanism:

G29 calls mesh.g if it exists, and if it does not then behaves like G29 S0. So you can create a mesh.g file like this:

That looks really promising! Thank you very much! I did not know about that.

@dc42 said in Error Handling Mechanism:

G0/1/2/3 out-of-reachable-area errors abort the job if the machine is in CNC or laser mode. In FDM mode they do not [...] because it is not unusual for parts of the skirt to fall just outside the printable region.

I see your point, but I would like to catch those errors anyway. At least to throw a warning. Is there any chance?

Maybe the object model can tell me something about the boundaries of the object to be printed? If so, I could check if parts of the print are beyond the printable area before the print starts in start.g

[dc42]

@justus2342 said in Error Handling Mechanism:

Maybe the object model can tell me something about the boundaries of the object to be printed? If so, I could check if parts of the print are beyond the printable area before the print starts in start.g

The OM doesn't know about the boundaries of the object you are about to print when it calls start.g. However, some slicers can put the print object boundaries into GCode commands in your start GCode, so you could check there. See https://forum.duet3d.com/topic/29576/only-probe-where-the-part-will-be-printed to get some ideas.

[justus2342]

@dc42 Thank you. That is a nice starting point, but I do not like it as error catching mechanism. When I use my usual slicer, the print bed size should be set correctly and I expect no problems. But when the gcode comes from somewhere else – for instance I experiment with some other slicing software – that is where I would like to have those errors caught.

However. As far as I understand, RRF cannot help me at the moment. Thus I will close this thread as solved and write something in the Firmware Wishlist section.