Prior to RRF 3.4, conditions that now trigger an event on a mainboard were handled in a range of ways, depending on the issue. Similar conditions on CAN-FD connected expansion boards did not cause the same handling to be invoked. The event system is designed to unify the handling of these (often erroneous) conditions across Duet 2 and Duet3 mainboards, and CAN-FD expansion boards.
In the case of a heater fault the heater is turned off before the event is raised, so a faulty heater is aways turned off
Currently, RRF does not attempt to turn off power to the whole machine in the case of machines with firmware controlled power supplies if the user does not respond to the heater fault. We plan to reinstate this or a similar function in release 3.5
An event is one of the following:
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.
The following are not currently treated as events:
An event has the following properties:
Events also have the following derived properties:
Events are added to an event queue running on the mainboard and processed sequentially, and inserted according to their priority. Higher priority events can jump the queue, but do not jump ahead of an event that's part way through processing. Once an event is processed its removed from the queue.
The normal action taken when processing an event is to attempt to run the macro for that event. The handler macro must be in the system files folder (i.e. “/sys” or as set by M505) and have the same name as the event type, with a ‘g’ extension added. Parameters are passed as follows:
If the macro file is not found then default processing occurs as shown in the table. Where "Pause print" is shown, if the print is already paused or pausing then no additional pause is added.
| Event type & macro file name | D macro parameter | P macro parameter | B macro parameter | Default action if macro file not found | Log level |
|---|---|---|---|---|---|
| heater-fault | Heater # | Heater fault type code | CAN address of board controlling the heater | Faulty heater turned off (before the event is raised). Pause print using pause.g and inform user via message box | Error |
| driver-error | Local driver # | Lower 16 bits of driver status word | CAN address of board with driver | Pause print without running pause.g and inform user via message box | Error |
| filament-error | Extruder # | Filament error type code | CAN address of board hosting the filament monitor | Pause print using pause.g and inform user via message box | Error |
| driver-stall | Local driver # | 0 | CAN address of board with driver | Inform user via console and continue | Warning |
| driver-warning | Local driver # | Lower 16 bits of driver status word | CAN address of board with driver | Inform user via console and continue | Warning |
Once processing is completed the event is removed from the queue. If an event of a particular type in in the queue and that condition happens again on the same device, a second event of the same type/device is not added to the queue.
As described above events call specific macros (e.g. filament-error.g) and pass macro parameters to those macros.
For more information about macro parameters see:
https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#macro-parameters
as an example:
filament-error.g could contain:
echo "filament error from filament monitor: "^{param.B}^"."^{param.D}^" : "^{param.P}^" ,"^{param.S}
to print the particular issue.
The following behaviour changes may require configuration and macro file changes to be made when upgrading from RRF 3.3 to 3.4.