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

    CoreXYAC / 5-axis Voron / M669 kinematics configuration

    Scheduled Pinned Locked Moved Unsolved
    Using Duet Controllers
    5
    15
    1.5k
    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.
    • PXP11undefined
      PXP11
      last edited by

      Hi guys.

      Short Intro:
      I built a 5-axis Voron 2.4. Mechanically it works but I'm having trouble with the M669 kinematics configuration. (Duet2 Wifi + DueX5)

      Long Intro:
      So, I'm currently in the final phases of my study to become a mechanical engineer. As part of my bachelor thesis, I got the task to develop a 3d printing system which can be used to functionalize already existing plastic parts e.g. printing geometries on injection moulded parts. This was the perfect task for me because on the one side I know my way around 3d printers and as a CNC-Machinist by trade I have already worked with 5-axis CNC machines.
      So after a short research phase I settled on converting a 350mm Voron 2.4 to 5-axis using duet boards and RPF, mostly because I'm already familiar with the firmware and it's the only one capable of handling the 5-aixs stuff.
      I mainly developed three key components: AC-axis trunnion, custom printhead because of the necessary clearances and a 3D-touchprobe-tool to locate the parts in space.
      PXL_20230526_132709081.jpg
      Voron_5x_1.png
      Current status:
      Mechanically and electrically, everything works. For the setup process I put it in the standard coreXY mode M669 K1. Homing for all the axis works perfectly (A- and C-axis do also have homing switches). A is constrained +/- 90°, C is free to rotate indefinitely.

      Problem:
      In my research concerning the feasibility of the project I stumble upon all the duet documentation regarding the "robot" stuff: Robot Docs. I found my way to the 5-axis CNC page (5-axis Docs) and discovered a already existing configuration for CoreXYAC. So the command M669 K13 B"robotType=CoreXYAC" should solve all my problems.
      Turns out I was a bit too optimistic there. When implementing M669 within the config.g file I get the following message:Untitled_2.png
      Am I correct in the assumption that those types are not implemented in RPF 3.4.5 or are other previous configurations needed before the M669 command?
      So even if I must configure the kinematics matrix myself, it's hard for me to find the correct information, as it's obviously quite a niche application and the information is fragmented across different pages. For example: The M669 command is featured much more in depth on the robot config page than on the gcode repository for M669.
      If someone already has any help, insight or information regarding this topic, your support would be much appreciated.

      Thanks in advance
      Dan

      PS: I looked a lot at the OpenX5 repository from Freddie Hong but all the kinematics stuff is handled in the grasshopper/ rhino setup and not on the Duet. Due to the fact that we are planning to use commercial 5-axis slicing software this is not really a option. This printer needs to receive XYZAC lines and to move according to the kinematics model.

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

        @PXP11 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

        Am I correct in the assumption that those types are not implemented in RPF 3.4.5 or are other previous configurations needed before the M669 command?
        So even if I must configure the kinematics matrix myself, it's hard for me to find the correct information, as it's obviously quite a niche application and the information is fragmented across different pages.

        We're waiting for @JoergS5 to announce a stable version of the robot code before we integrate it into our standard Duet 3 builds of RRF. Meanwhile you might like to seek advice in this thread https://forum.duet3d.com/topic/17421/robotic-kinematics.

        We won't be including robot kinematics in Duet 2 builds because of lack of flash memory space. So even when we do include it as standard in our Duet 3 builds, you will need to build the firmware for Duet 2 yourself, adjusting the Pins_DuetNG.h file to enable robot kinematics and to disable enough other features to free up sufficient 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

        PXP11undefined 1 Reply Last reply Reply Quote 0
        • PXP11undefined
          PXP11 @dc42
          last edited by

          @dc42
          Thank you for the clarification.
          So this basically this means no onboard kinematics until a robot code version is released and I created a custom fork for the Duet2 with every unused pin und unnecessary feature disabled? Or just upgrading to a Duet3 6HC+3HC?

          But the Duet2 should be able to handle 5-axis simultaneous movement when the kinematics model is calculated externally and just fed in as XYZAC coordinates? Or do I already need to disable features now/ is there a way to monitor the flash memory used?

          JoergS5undefined T3P3Tonyundefined 2 Replies Last reply Reply Quote 0
          • JoergS5undefined
            JoergS5 @PXP11
            last edited by JoergS5

            @PXP11 @dc42 I'll make a build for Duet 2 to test whether memory is sufficient, then David can decide whether it can be integrated for Duet 2 also.

            I make a version with cached values or without. Without caching, it will be slower, but needs less memory, so there are chances for Duet 2. This is handled by a #if switch, needing recompilation (or setting it to cache for Duet 3 and without for Duet 2 as default). I have Duet 2 and 3 and can compare and report the results. Another possibility is a limited cache for Duet 2, so not all subkinematics like 6 axis robot can be used, but those who need less memory.
            Edit: I will currently not use the if option to avoid too much code change. The data+cache needs about 2000 bytes currently to support all subkinematics, this can be diminished for Duet2 if needed.

            I concentrate on CoreXY 5 axis, this will be the first released part. Release of the test version between tomorrow or a short time later, depending whether I find bugs. I build a binary for Duet 3 Mini, Duet 3 6HC and Duet 2, but publish the sources addtionally to github for own compilation of course.

            1 Reply Last reply Reply Quote 0
            • JoergS5undefined
              JoergS5
              last edited by

              Testing yesterday, I found several bugs and a few ambiguities in the specification of the configuration options. I don't want to bother (or annoy) anybody with them, just correct them before delivery. A reminder for me that unit and integration testing are essential (at least for me).

              Additionally, I build a CoreXY 5 axis prototype today to verify code. The forward/inverse code as such works ok. I'll post the prototype in the My Duet controlled machine section, as it may be interesting as low cost version to try 5 axis.

              I'm changing configuration as well, to lower memory usage and for some special cases. The usual M208 homing procedure will be supported vor CoreXY, because XYZ are linear.

              1 Reply Last reply Reply Quote 2
              • JoergS5undefined
                JoergS5
                last edited by

                I have some results from today about CoreXY:

                • for every inverse kinematics there are two solutions for AC: A 180 degrees different and C negated. Example A=30, C = 50 => another solution with same position and orientation with A=-150, C=-50. My proposal would be to set a preference variable abSign to 0 positive or 1 negative and try to remain in this area. Or are there other proposals?

                It may make sense to change the AC at some time, because XYZ position changes considerably, so space requirements can require the change. Changing while a move happens is a disaster (infinite velocity). The change could be made with a specific G-Code command.

                • performance looks good, on the laptop 1.4 microseconds for inverse kinematics and low memory usage. Duet 2 should be possible with a flag to limit the cache.
                oliofundefined PXP11undefined 2 Replies Last reply Reply Quote 0
                • oliofundefined
                  oliof @JoergS5
                  last edited by

                  @JoergS5 you are allowed to be opinionated in your implementation and just pick one of the two kinematics solutions. It moght be interesting to do a "shortest path" kind of heuristic later (-;

                  <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                  JoergS5undefined 1 Reply Last reply Reply Quote 0
                  • JoergS5undefined
                    JoergS5 @oliof
                    last edited by

                    @oliof you may be right, it is a problem to be solved in a later release.

                    In robot industrial, there are 8 inverse solutions, in all AC/BC related 2 inverse, in 5 bar parallel scara with 5 axes 4 forward (the workmodes), resulting in 4 * 2 inverse solutions, so I'll store the current preference and use it for forward/inverse, until something better is developed. The algorithms always give back all solutions.

                    1 Reply Last reply Reply Quote 1
                    • PXP11undefined
                      PXP11 @JoergS5
                      last edited by PXP11

                      @JoergS5
                      So I actually thought about the preference angles when constructing the 5 axis Voron. The printhead was designed accordingly to accommodate an A-angle of up to 90°+ (A90) while having the nozzle as close to the build plate as possible. As of now I have set the max angle at 90° but it can accommodate at least up to 110°. Also for visibility purposes it's much more preferrable than the negative A-angles. And in general on commercial 5 axis machines and CAM Software or rather post processors, the next positive C-angle is always preferred for the possible solutions. If the C-axis is freely rotating that is, some cheap trunnions for example have to turn back to 0 after 720°.
                      Voron_5x_3.png

                      JoergS5undefined 1 Reply Last reply Reply Quote 2
                      • JoergS5undefined
                        JoergS5 @PXP11
                        last edited by JoergS5

                        @PXP11 I've tested the results of the A angles between -180 and +180 ok, but precision of the linear axes calculation is diminished when the angle is near +-90 or +-180 degrees *) (precision is about 0.3 mm then in worst case. The normal precision is in the region 1e-4 mm). I'll add double precision when being there probably or try a different algorithm. When near +-90, little rotation changes have a big influence on the xyz positions (RTCP correction) which are corrected by xyz movements.

                        *) near means it is approaching about +-0.3 degrees, so between 89.7 and 90.3 degress the xyz results begin to be less precise (the difference between forward and inverse kinematics result).

                        I add a requirement to store the absolute degree of the C axis, so a limit to +-720 can be set. I'm not sure whether the slicer or firmware shall rotate back the C axis when this limit is reached.

                        PXP11undefined 1 Reply Last reply Reply Quote 0
                        • PXP11undefined
                          PXP11 @JoergS5
                          last edited by

                          @JoergS5
                          I think in "normal" simultaneous and dynamic operation it's actually not that likely to be near that +-90° window. Especially if you think about the printing of convex or concave shapes. The 90° angle is more likely with a stationary A-axis (radial rotary printing) or AC-axis stationary when printing "normally" on the side of a cube for example. This obviously depends on the use case. I don't know how this affects the accuracy when one or both of the rotaries are stationary.

                          @JoergS5 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

                          I add a requirement to store the absolute degree of the C axis, so a limit to +-720 can be set. I'm not sure whether the slicer or firmware shall rotate back the C axis when this limit is reached.

                          Well this could either be handled in the slicer but more likely in the post processor. When the angle goes over +-720 you subtract the int-multiple and set back the position with a G92 accordingly next to 0. This would be my first and dirty solution. No idea if there would be a more refined method.

                          JoergS5undefined 1 Reply Last reply Reply Quote 0
                          • T3P3Tonyundefined
                            T3P3Tony administrators @PXP11
                            last edited by

                            @PXP11 said in CoreXYAC / 5-axis Voron / M669 kinematics configuration:

                            But the Duet2 should be able to handle 5-axis simultaneous movement when the kinematics model is calculated externally and just fed in as XYZAC coordinates

                            yes this definitely works ok because that is how @Freddiester is controlling the original #Open5X printer:
                            https://forum.duet3d.com/topic/27648/5-axis-3d-printer-on-prusa-i3?_=1686302247551

                            www.duet3d.com

                            1 Reply Last reply Reply Quote 0
                            • JoergS5undefined
                              JoergS5 @PXP11
                              last edited by

                              @PXP11 I'll make a build for CoreXY 5 axis tomorrow, check in and make a Duet 2 binary, which is memory reduced, so it should work for you.

                              I'll make some updates to the robot 5 axis dedicated page about homing and how to specify the config.

                              PXP11undefined 1 Reply Last reply Reply Quote 0
                              • PXP11undefined
                                PXP11 @JoergS5
                                last edited by

                                @JoergS5
                                Perfect, I'm looking forward to tiring out the build. If everything goes to plan, I should have time to test on the printer towards the end of next week.
                                Thank you very much for the extra effort.

                                JoergS5undefined 1 Reply Last reply Reply Quote 0
                                • JoergS5undefined
                                  JoergS5 @PXP11
                                  last edited by JoergS5

                                  @PXP11 I've made the build now, but my prototype is not ready, so I cannot test it. I posted you the binary, but I would prefer if I can test it next week before you damage something. I'll be out of office until Tuesday, then I can proceed.
                                  The files are checked in in https://github.com/JoergS5/RepRapFirmware_robot

                                  Duet 2 had compilation problems, I hope the memory is sufficient. => I can try to reduce the cache memory a bit more next week.

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