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

    Beta testers for multiple motion system support

    Scheduled Pinned Locked Moved
    Beta Firmware
    21
    70
    6.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.
    • GeneRisiundefined
      GeneRisi @dc42
      last edited by

      @dc42 is the memory space too limited with the duet2s ?

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

        @dc42 I don't know if my machine would fit your criteria but if you recal, the (6 input) hot end is on the XY gantry, and the 6 extruders run on the UV gantry. I currently use a python script to generate the UV moves such that the extruder gantry (UV) tracks the hot end (XY) but within a tollerance of +/-20mm so the UV moves are always shorter than the XY moves. It wouldn't be too difficult to slice the same part twice - once to generate the XY moves and then a scaled down version to generate the UV moves (although I'd likely have to run a python script to convert the G1 XY moves to G1 UV).
        But if the goal is for the firmware to process two concurrent gcode streams, then I reckon I could test it.

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

        1 Reply Last reply Reply Quote 1
        • kazolarundefined
          kazolar @dc42
          last edited by kazolar

          @dc42 my machine has 2 gantries with 2 independent heads on each. So as I called before a quad. 2 of the tools can be fully independent of each other, z is shared. If there is a way to synch z moves, this would be a cool project.

          1 Reply Last reply Reply Quote 1
          • o_lampeundefined
            o_lampe @dc42
            last edited by o_lampe

            @dc42 I'd really like to be part of the test-team with my hashprinter. But it runs on @gloomyandy 's branch of RRF.
            If he's part of the dev team or has access to your latest code (and is willing to colaborate) I'd love to test his branch.

            A Duet3 setup with 11-12 stepper drivers is currently not affordable for me. (independent Z-axis would require 4 more steppers)
            As a last straw I would sell the hashprinter (as-is) to someone in EU, who has the knowledge and funds to make it work.
            PM me if you're interested...

            gloomyandyundefined oliofundefined 2 Replies Last reply Reply Quote 1
            • JoergS5undefined
              JoergS5 @dc42
              last edited by

              @dc42 I will participate with two robot arms. Main focus will be collision detection and avoidance and I will help writing needed code.

              1 Reply Last reply Reply Quote 1
              • gloomyandyundefined
                gloomyandy @o_lampe
                last edited by

                @o_lampe It looks like the code for this will be on the 3.5-dev repo. I will at some point be picking that code up and providing an STM32 version, so hopefully we will be able to contribute to the testing of this new feature. I usually try to track new developments reasonably closely so hopefully it will be possible to do that again.

                1 Reply Last reply Reply Quote 4
                • oliofundefined
                  oliof @o_lampe
                  last edited by

                  @o_lampe I have an unused MB6HC and 3HC expansion board I can loan out to you. DM me for details.

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

                  o_lampeundefined 1 Reply Last reply Reply Quote 1
                  • o_lampeundefined
                    o_lampe @oliof
                    last edited by

                    @oliof That's very kind of you, but I'd need at least three 3HC boards or many other toolboards with 2 drivers per board. 15 drivers in total...

                    oliofundefined 1 Reply Last reply Reply Quote 0
                    • oliofundefined
                      oliof @o_lampe
                      last edited by

                      @o_lampe if one other kind soul finds they have a 6HC lying around you'd be set (-:

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

                      o_lampeundefined 1 Reply Last reply Reply Quote 0
                      • o_lampeundefined
                        o_lampe @oliof
                        last edited by

                        @oliof
                        Jepp, passing the hat is not my style. Unfortunately the shopping list would be alot longer (eg. hotends, direct drive extruders). That's why I proposed to sell my frame.
                        But it's over the top for a dual-motion system anyway. It would need 4 independent Z-axes and then it could work with two tools simultaneously. (then changing tools for perimeter and infill)
                        It's quite a challenge

                        oliofundefined 1 Reply Last reply Reply Quote 0
                        • oliofundefined
                          oliof @o_lampe
                          last edited by

                          @o_lampe you are not passing the hat if people propose giving, but I catch your drift. Unfortunately I have neither the funds nor the space for yet another machine, or I´d consider your offer.

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

                          1 Reply Last reply Reply Quote 1
                          • breedundefined
                            breed
                            last edited by breed

                            Untitled.jpg

                            ive been working on this layout in the background while I finish other printers. should be what you are thinking correct?

                            o_lampeundefined 1 Reply Last reply Reply Quote 0
                            • o_lampeundefined
                              o_lampe @breed
                              last edited by

                              @breed The critical thing about dual print heads and dual toolheads working simultaneously has always been the z-height. (mesh -leveling etc)
                              Idk if that's already in the scope of @dc42 project, but independent z-motion is the key for succesful multi tool systems.
                              Since you are still in the planning phase, you might consider adding an Z-adjustable toolholder. (I prefer dovetail sliders)

                              David, would you be so kind and tell us the options to drive the independent mini-z axes?
                              Geared DC-encoder motors would be small and strong, but they'd need a supporting toolboard.
                              Steppers would be huge and heavy. Remotely driven, it might be an option, if mesh leveling with backlash-compensation is available.

                              dc42undefined breedundefined 2 Replies Last reply Reply Quote 0
                              • dc42undefined
                                dc42 administrators @o_lampe
                                last edited by dc42

                                @o_lampe wouldn't a Nema 11 or Nema 8 stepper motor with leadscrews be suitable? Although the Nema 8 ones tend to be expensive. https://www.omc-stepperonline.com/linear-motor

                                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

                                o_lampeundefined 1 Reply Last reply Reply Quote 0
                                • breedundefined
                                  breed @o_lampe
                                  last edited by breed

                                  @o_lampe I haven't gotten near the point of adjustable z on one of the tool heads. I have 2 printers with makertech tilting hotend. They have grub screws for adjusting the heatbreaks, seems to work fine. I was hoping to get this one figured out and together by mrrf, but there are 4 other printers in the que in front of it. Maybe next year. Having automatic z adjustment would be awesome but the weight....I didn't want the common rail double x carriage because of carrying the second x carriage for all the y axis moves. I have an i3 style idex and basically never print mirror or duplicate mode. I def could see a path for simultaneous g code. Printing two different objects would be a useful time saver.

                                  1 Reply Last reply Reply Quote 0
                                  • o_lampeundefined
                                    o_lampe @dc42
                                    last edited by o_lampe

                                    @dc42
                                    It would work, but the weight penalty isn't worth the +/-1mm movement we need for Z-hop and mesh leveling.
                                    Even a small hobby servo with excenter could do this, but their speed isn't controlable. That makes it difficult to move them in sync with XY motion.
                                    So IMHO a dc motor with encoder would be the best option.
                                    A mockup picture of a modified PTFE dovetail slider with dc motor/leadscrew

                                    In a perfect world we'd have access to the heightmap(s)-data and route the z-correction to a device of our choice.

                                    1 Reply Last reply Reply Quote 0
                                    • botundefined
                                      bot
                                      last edited by

                                      What about shims to adjust hot end Z height? On my printer, I'm able to add shims to the top of the hot end to lower its nozzle's Z height.

                                      *not actually a robot

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

                                        Thanks for all who have responded. I may be able to provide a first build of RRF with dual motion system by this Friday. This version will have some limitations:

                                        • The two motion systems must share a common Z axis
                                        • Standalone mode only (not SBC mode)
                                        • Resume-after-power fail will not be supported
                                        • Simulation mode may not be supported
                                        • Pause/resume may not be fully implemented
                                        • There will be no attempt to predict collisions between the two print heads, so the GCode commands must avoid potential collisions
                                        • There will be no checking that commands for different motion systems don't attempt to drive the same axis simultaneously
                                        • No mesh bed compensation

                                        It's time to think about preparing GCode files that case use both motion systems. There is some documentation at https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems on how the different motion systems are addressed in GCode.

                                        The simplest way to use the two motion systems is probably to load two objects on the build plate in your slicer and space them far enough apart so that they can be printed independently by your two motion systems without collisions. Then change the GCode file produced by the slicer so that the commands for one object are assigned to motion system 0 (by using the M596 P0 command before a block of commands for that motion system) and commands for motion system 1 are assigned to motion system 1 (using M596 P1 before a block of commands for that motion system).

                                        You will need to add a M400 command to sync the motion systems before and after each G1 Z command that does a layer change. Obviously you cannot use Z hop on travel moves. Don't let the blocks of contiguous commands for one motion system get too long, or the other motion system might pause for a short while as it skips the block.

                                        You will need to select one tool for each motion system at the start. One of those tools should map the X and Y axes to the corresponding axes of your second motion system, for example U and V.

                                        In the future I hope we will be able to do the splitting of objects into multiple motion systems either in the slicer, or in a standard post-processing script.

                                        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

                                        o_lampeundefined 2 Replies Last reply Reply Quote 2
                                        • o_lampeundefined
                                          o_lampe @dc42
                                          last edited by

                                          @dc42
                                          That'll be exciting to try!
                                          You should also mention that mesh leveling must not be enabled.

                                          I wonder, how a waiting tool behaves when layer times are way different? Will it go in parking position or just sit and wait for the other tool to finish the layer? Will it automatically retract/unretract?

                                          1 Reply Last reply Reply Quote 0
                                          • o_lampeundefined
                                            o_lampe @dc42
                                            last edited by o_lampe

                                            @dc42 said in Beta testers for multiple motion system support:

                                            There will be no checking that commands for different motion systems don't attempt to drive the same axis simultaneously

                                            How do we address layer changes then? Isn't Z-axis a common axis of both systems? Do we need to define a third tool just for the z-axis and switch to that tool before layer change?
                                            Putting M400 before a layer change will only wait for the other tool to empty the print queue, but it's not guaranteed to be finished with the layer...

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