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

    CAN Latency and practical application

    Scheduled Pinned Locked Moved
    Using Duet Controllers
    4
    8
    415
    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.
    • wayneosdiasundefined
      wayneosdias
      last edited by

      I ordered a 6HC rather impulsively as my current controller was beginning to fail. Having used a Duet 2 wifi with great success in the past I just assumed the 6HC supported step/drive signals to drive external drivers. Once I discovered this was not the case I impulsively ordered x2 1XD Expansion Boards. Then I read of the CAN latency issue and impulsively ordered a Mini 5+ as that board natively supports x2 off-board drivers. I now have a 6HC + x2 1XD expansions and a Mini 5+.

      Taking a step back and looking at the best possible solution. My machine is a PnP that rapids large XY distances with a fairly heavy head. It requires >36V XY drivers with encoding hence the need for the offboard drivers.

      The more I think about CAN latency it in practical terms; If the XY is driven by the 6HC + XDs and the CAN latency only manifests as a slightly off Homing of XY this should not be an issue. So long as the XY are not Homed at a rate so fast to overrun the limit switch, once Homed, latency is no longer an issue given that;
      -Work Offset is almost never at home, or at least never on my machine and doesnt require any correction of overstep.
      -Work Offset or Job reference is ultimately determined by visual calibration.
      -Since component pick up and orientation is automated with vision, vision settling time can be adjusted to compensate for any XY deviation due to CAN latency.
      Is that accurate?

      Lastly the only thing Im not terribly sure of is that OpenPnp has 'Smoothing' options requiring a lot of velocity/trajectory updating in the XY plane. Is it conceivable that the increased gcode planner updating for smoothing could overrun the CAN? Does the 6HC buffering handle this?

      I really like the speed of the 6HC Ethernet and like it to be the solution. If anyone could shed some light on any of this it would be greatly appreciated.

      Thanks Wayne

      dc42undefined 1 Reply Last reply Reply Quote 0
      • rjenkinsgbundefined
        rjenkinsgb
        last edited by

        As far as I am aware, the CAN latency only affected such as "instantaneous" signals between two boards, like an axis limit or probe on one board relating to an axis motor on a different board.

        In normal operation, all commands are queued ahead of time and then executed synchronously by all boards.

        That's what caused a problem with a switch/probe detection, as the motor board would still be executing the move for a few milliseconds before the probe signal reached it.

        I believe even that is now a non-issue, and the axis will take the correct position from the switch trigger point.

        Even without that, a simple solution is a two stage home, backing off a fraction then a very slow move on to the switch again, so the distance moved during any delay is irrelevant.

        Robert J.

        Printers: Overlord pro, Kossel XL+ with Duet 6HC and "Frankentron", TronXY X5SA Pro converted to E3D toolchange with Duet 6HC and 1LC toolboards.

        1 Reply Last reply Reply Quote 3
        • dc42undefined
          dc42 administrators @wayneosdias
          last edited by

          @wayneosdias it's as @rjenkinsgb said in his reply.

          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 1
          • wayneosdiasundefined
            wayneosdias
            last edited by

            Thanks for the explanation. So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

            rjenkinsgbundefined deckingmanundefined dc42undefined 3 Replies Last reply Reply Quote 0
            • rjenkinsgbundefined
              rjenkinsgb @wayneosdias
              last edited by

              @wayneosdias said in CAN Latency and practical application:

              So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

              Correct, as I understand it.

              And, as of the recent betas, the endstop position is also correct even with remote switches; any overshoot will be cancelled automatically.

              Robert J.

              Printers: Overlord pro, Kossel XL+ with Duet 6HC and "Frankentron", TronXY X5SA Pro converted to E3D toolchange with Duet 6HC and 1LC toolboards.

              1 Reply Last reply Reply Quote 0
              • deckingmanundefined
                deckingman @wayneosdias
                last edited by

                @wayneosdias If it's of any help, I have a CoreXYUVAB (3 XY gantries) with 6 extruders running a 6HC main board and three 3HC expansion boards. The XY and Z motors are connected to a 3HC expansion board and the UVA&B motors are connected to the 6HC main board. The 6 extruders are connected to the other two 3HC expansion boards. The end stops for all those axes are scattered around between the various boards and not necessarily connected to the same board as the motors. Latency for homing Z was initially a bit of an issue but that was resolved over a year ago and everything is "fine and dandy" now.

                Ian
                https://somei3deas.wordpress.com/
                https://www.youtube.com/@deckingman

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

                  @wayneosdias said in CAN Latency and practical application:

                  Thanks for the explanation. So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

                  No, because the limit switch triggering is still processed by the main board.

                  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

                  wayneosdiasundefined 1 Reply Last reply Reply Quote 1
                  • wayneosdiasundefined
                    wayneosdias @dc42
                    last edited by

                    @dc42 said in CAN Latency and practical application:

                    @wayneosdias said in CAN Latency and practical application:

                    Thanks for the explanation. So if I understand correctly, if a CAN driven axis has its limit switch local to the CAN board and not the Main board, there is no latency issue at all?

                    No, because the limit switch triggering is still processed by the main board.

                    Understood, 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