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

    Configurable step pulse offset (delay) per drive

    Scheduled Pinned Locked Moved
    Firmware wishlist
    2
    3
    231
    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.
    • nhofundefined
      nhof
      last edited by

      I want to be able to delay a drive's pulse train by a configurable amount of time.

      The reason is that many external servos (Odrive, etc.) running from step/dir perform poorly when connected to the moderately slow pulse train from the duet.

      The servos I use have a feature to improve performance in this type of setup. They have a configurable step buffer where the servo will sample steps for a period of time, any only start executing afterwards. This greatly increases servo performance by enabling the servo to look ahead a certain period of time and adjust to upcoming events.

      The problem with enabling these input buffer is that the external servos will get out of sync with the on-board stepper motors due to the time delay introduced. This leads to print quality issues if running external drivers alongside internal.

      One method to solve this would be to enable a configurable delay to the step pulse train to drivers. I imagine another argument to the M569 command might work.

      Something like M569 P3 K100000 ; offset drive 3 pulse train by 100,000 us (0.1s)

      That way if the input buffer on an external servo is set to 0.1 seconds, the internal drive 3 will still be synchronized with it.

      Is this something that could be added reasonably without breaking everything?

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

        Unfortunately, that would be difficult to implement. The problem occurs when one move ends and another starts, because if some of the drives are being delayed, two or even more moves would have to be processed at the same time. The firmware is based on the premise that under normal circumstances, only one move is executed at a time.

        RRF is designed to send step pulses at uniform intervals even when it switches to double or higher stepping, because that is what most step-servo drivers prefer

        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
        • nhofundefined
          nhof
          last edited by

          Gotcha. I thought it might be too complex to implement, but doesn't hurt to ask. Thanks for the explanation 🙂

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