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

    M408 does not respond when sensing endstops

    Scheduled Pinned Locked Moved
    Firmware developers
    2
    5
    249
    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.
    • ctundefined
      ct
      last edited by

      M408 does not respond when sensing endstops. What is preventing the response?

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

        @ct said in M408 does not respond when sensing endstops:

        M408 does not respond when sensing endstops. What is preventing the response?

        Please explain what you mean in more detail.

        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

        ctundefined 2 Replies Last reply Reply Quote 0
        • ctundefined
          ct @dc42
          last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • ctundefined
            ct @dc42
            last edited by ct

            @dc42 If I send a M408 from the web interface ‘Send’ button during a move without sensing endpoint it responds with the status. If I send it with sensing endpoint it buffers the responses and sends them all at the end of the move. M408 sent using RS232 responds immediately regardless of whether sensing endpoint is on or off. The discrepancies threw me during testing but it doesn’t cause me a problem as I am using the comm port. I'm sorry if I have wasted your time.

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

              The reason is that each GCode input channel can only process one command at a time. Ordinary movement commands are placed in a queue for later execution, so unless the queue is full, processing them happens immediately. But when a homing move is executed, the system has to wait until it completes so that the axis positions can be reset. So processing it doesn't finish until the move does.

              The same applies to all input channels. So if you initiate a homing move from DWC, you can execute M408 and other non-motion commands concurrently from serial; and vice versa.

              HTH David

              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

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