Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

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

    Scheduled Pinned Locked Moved
    PanelDue
    3
    5
    238
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Armonundefined
      Armon
      last edited by 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?

      dc42undefined 1 Reply Last reply Reply Quote 0
      • dc42undefined
        dc42 administrators @Armon
        last edited by

        @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.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        GeneRisiundefined 1 Reply Last reply Reply Quote 0
        • GeneRisiundefined
          GeneRisi @dc42
          last edited by

          @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?

          dc42undefined 1 Reply Last reply Reply Quote 0
          • dc42undefined
            dc42 administrators @GeneRisi
            last edited by

            @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.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            GeneRisiundefined 1 Reply Last reply Reply Quote 0
            • GeneRisiundefined
              GeneRisi @dc42
              last edited by

              @dc42 Thank you!

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Unless otherwise noted, all forum content is licensed under CC-BY-SA