Command Buffer for Console Messages

[mwolter]

Hello,
Is it possible to query the object model to retrieve why the printer was automatically paused, stopped, or halted? What I'm looking for is something similar to the user alerts that are sent to the paneldue or DWC. For instance, if the printer was halted due to a heater error, movement error, filament sensor runout or under or over extrusion. Basically I would like to retrieve the last alert that was sent to the user.

If this isn't possible, I would like to request an object to be added that contains this text string.

This would be helpful as the object could be queried via the rr_model HTTP command and the alert string could be sent to the user via email, notification, or be processed by external logic to perform additional tasks. Currently, I am using NodeRed to query the Duet and send an alert if the printer state changes from printing to paused, but it would be helpful to also receive info on why it was paused.

Thank you!

Edit: Please see Danal's message below. I think a buffer for console messages would be better as long as all warnings (thermal, filament runout, etc.) are displayed there. Currently, I don't believe filament runout warnings print to the console.

[dc42]

I can look ad adding this, but we'd need first to define what constitutes an "alert".

[mwolter]

@dc42 I have a couple ideas. One would be to store the text string of anything that would cause a modal pop up in DWC or PanelDue that has to be dismissed. In other words anything that generates a dialog box that has an ok button. Another idea, and this might be easier to implement, is if the in print is automatically paused or stopped, store the reason why it was interrupted.

[Danal]

The current handling of "console" across multiple IP sessions is a bit odd. I'm not sure I even fully understand it.

Would it be possible (memory wise) to have a fixed depth buffer of "past" console messages that can be pulled by any IP connected process that wants to keep track on its own? Perhaps a sequence number to help, perhaps not. About a 10 message deep buffer? Sort of fixed, in that it really should be a number of lines, not a number of bytes, within the limits of a reality check on the size in bytes.

Or any other thought on how to allow connections to "see" console messages that would otherwise be handed to a different connection, and therefore invisible?

That would avoid the firmware making all kinds of decisions. Push the burden onto the external interface.

[mwolter]

@Danal Great idea, and I agree how RRF reports console messages to multiple devices is very confusing. Storing the last 10 or so console messages with my situation as well as provide a better mechanism for receiving console messages multiple connected devices.

[mwolter]

@dc42 Since you're in the process of developing 3.2.0, wanted to see if this "command buffer" for the console was in the works.