PanelDue UART. Issues getting printer state while it is busy.

Armon

Hi all!

I've been using a duet 2 wifi board for a while and while it's pretty awesome, I do not have a PanelDue or any other button panel connected to it.
All interactions must be done remotely and it can be a little inconvenient at times.

So I've started a fun little project of building a diy panel that would let me do some basic things like perform emergncy stop, home the printer, load/unload fillament, etc.

It turned out that uart of duet panelDue port is mostly straightforward to use, which is fantastic.
I can send gcode commands to printer and receive replies with no issues.

Well, almost no issues.

Ran into a problem where 'M408' status command would not work if printer is busy (homing axis, executing macro, etc). A busy printer does not respond to the uart commands. This means I cannot get accurate printer status and having difficulties distinguishing between printer offline and printer busy states ( no reply either way).

What is the correct way of handling this situation? How does PanelDue do this? is there a Gcode command that perhaps returns a non-blocking response?

dc42

@Armon said in PanelDue UART. Issues getting printer state while it is busy.:

Ran into a problem where 'M408' status command would not work if printer is busy (homing axis, executing macro, etc). A busy printer does not respond to the uart commands. This means I cannot get accurate printer status and having difficulties distinguishing between printer offline and printer busy states ( no reply either way).

That's only the case if the command being executed was sent from PanelDue. Some status data (mainly heater temperatures) is sent automatically by recent (3.4 and probably 3.3) versions of RRF when the printer is busy with those commands.

GeneRisi

@dc42 I am wondering if it would be a "reasonable" amount of work to implement a full two-channel over serial link protocol between the Paneldue and the Duet ?

I am guessing that the current Paneldue firmware implements a "request/response", blocking protocol so that it knows the data being returned is associated with the request just sent, with one exception to this being the "Emergency Stop" request.

What if two logical channels were implemented via the serial link? One channel could be the current "request/response, mostly blocking" channel and the other could send asynchronous "push" data to the Paneldue and accept non-blocking requests from the Paneldue?

dc42

@GeneRisi in fact the PanelDue protocol is designed so that PanelDue does not need to know which request a response refers to. All the responses are JSON formatted and the keys are unique, so that PanelDue knows what to do with each response.

I think the main difficulty with using two virtual channels would be that a certain amount of message decoding would need to be done as characters are being received, so that commands for one channel don't get held up behind commands for the other.

The Duet already sends object model data to PanelDue unsolicited under certain conditions. I suggest you modify your application to use M409 commands instead of M408 and decode the resulting object model data. I hope to remove M408 in a future RRF version to save flash memory space.

GeneRisi

@dc42 Thank you!