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 |
|---|---|---|---|---|---|
| expansion-reconnect | 0 | 0 | CAN address of the board that has stopped communicating | Inform user via console and continue (likely to be changed before RRF 3.5 release) | Error |
| expansion-timeout | 0 | 0 | CAN address of the board that has stopped communicating | Inform user via console and continue. | Error |
| 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. Note, if you use the M591 S2 parameter to enable filament monitoring even when not printing from SD card, and an error occurs when not printing from SD card, then pausing the print will fail and error messages will be generated. You should provide your own filament-error event handler when using M591 S2. | 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 the Gcode Meta Commands wiki page.
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.
M957 can be used to raise an event, that allows to testing the event handling macros without having to cause a hardware or other fault.
Supported in RepRapFirmware 3.4 and later for raising events
M997 is used to raise an event or trigger internally as if the event had actually occurred, and execute any related handler macro for that event or trigger.
Parameters
The following behaviour changes may require configuration and macro file changes to be made when upgrading from RRF 3.3 to 3.4.