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

    M577 and queued movements

    Scheduled Pinned Locked Moved Solved
    General Discussion
    2
    8
    477
    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.
    • aconz2undefined
      aconz2
      last edited by

      I've tried reading through the source code to figure this out but haven't found anything conclusive. I'm wondering if moves are queued while waiting for an M577 or if they only get queued after the M577 trigger is complete. I see that HandleGcode keeps getting called until the M577 is triggered but I don't yet have an understanding on how that interacts with the DDARing.

      If moves are not queued until the M577 is complete, I'm wondering if there are any ballpark latency numbers on time from M577 complete to when the next G1 (for example) move would begin. 1 us, 10 us, 100 us, 1 ms, 10 ms?

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

        When the M577 command is reached, RRF will stop processing further commands. However, moves that have already been processed and queued (for example, moves) will continue to be executed until the queue is empty.

        If you want to watt for all previous commands to be completed and then to wait for a pin to be triggered, use M400 and then M577.

        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
        • aconz2undefined
          aconz2
          last edited by

          Thank you, that is what I suspected. And do you have an idea on latency to begin moving from an empty queue?

          My use case looks roughly like

          G1 X1
          M400
          M577 P1 S1
          G1 X1
          

          I'm hoping to get a handle on the elapsed time between the M577 and the start of the next move. My guess might be something like 1000 clocks so we're looking at 1ms, does that seem reasonable?

          If anyone is curious, I'm looking to synchronize the movement of a piece of wood so that moves only occur on the downstroke of a saw blade. First couple seconds of this video should give an idea.

          1 Reply Last reply Reply Quote 0
          • aconz2undefined
            aconz2
            last edited by aconz2

            I completed some initial testing and so far things look promising. See this video for some quick footage. This may be useful to other machines that need to synchronize with an external trigger.

            ; setup 
            M950 J1 C"!ext.e2stop" ; photo interruptor which goes low when saw is at top of stroke
            G91
            
            M577 J1 ; wait for saw to reach top of stroke
            G1 Y1 F480 ; forward 1 mm in Y
            M400 ; wait for moves to finish
            ; repeated 4 times in each test
            

            This does require generating gcode with each move chopped to the length desired to move with each downstroke as well as executing that move at a feedrate so that the move finishes in the time for a single down stroke. In this test we are moving 1mm at 480mm/min so the move should last 0.125s (roughly) and the saw is moving at 4 Hz so a half period is also 0.125s.

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

              When receiving moves and the move queue is empty, RRF waits for one of the following before starting to execute moves from the queue:

              1. The main loop is called 10 times without another move becoming available. In RRF 3.3beta there is an additional configurable timeout that must have elapsed too.
              2. The movement queue becomes full.
              3. A command that waits for movement to finish (e.g. M400) is executed.

              So one option may be to send G1 Xxxx M400 as a single line. That will ensure that the move is executed immediately.

              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
              • aconz2undefined
                aconz2
                last edited by

                So I believe you are implying that the move queue will not get filled while waiting on M577? This is my current understanding.

                Does sending the G1 Xxxx M400 as a single line matter if printing from an SD card?

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

                  You don't need to send G1 and M400 on a single line, but it's slightly more efficient if you do.

                  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
                  • aconz2undefined
                    aconz2
                    last edited by

                    To tack on in case anyone finds this later, I measured the "time to first step" ie. the time elapsed between M577 P1 and the first step of G1 Xxxx and am seeing 13 ms on average. My test setup was an Arduino with interrupts and wired to the input (photointerruptor in my case) and the X step pin on the duet.

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