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

    Beta testers for multiple motion system support

    Scheduled Pinned Locked Moved
    Beta Firmware
    21
    70
    6.6k
    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.
    • o_lampeundefined
      o_lampe @dc42
      last edited by o_lampe

      @dc42
      As it turned out in my thread, there are only two candidates left for independent z-adjustment: dual delta or dual SCARA option.
      I don't believe, the patents you mentioned forbid me to build such a printer?
      Or is it about a certain software method?

      Finding workarounds or improve the patented methods is still an option...
      Do you have a link to the patents, please?
      THX

      oliofundefined dc42undefined 2 Replies Last reply Reply Quote 0
      • oliofundefined
        oliof @o_lampe
        last edited by

        @o_lampe I don't think those patents necessarily bar you from building a printer with those features yourself, but you may not be allowed to commercially exploit them. I'm not a patent lawyer so this is a random claim on the internet and don't rely on it as legal advice (-:

        <>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 0
        • dc42undefined
          dc42 administrators @o_lampe
          last edited by

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

          Do you have a link to the patents, please?

          Here are links to some relevant patents. There may be others.

          https://patents.google.com/patent/US20150231827A1/en
          https://patents.google.com/patent/US11086295B2/en
          https://patentimages.storage.googleapis.com/dd/95/ae/df14d6ce71d74b/US20200233399A1.pdf
          https://patentimages.storage.googleapis.com/dc/d9/a1/69e28a28a70d1e/EP3347190B1.pdf

          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

          oozeBotundefined 1 Reply Last reply Reply Quote 0
          • oozeBotundefined
            oozeBot @dc42
            last edited by oozeBot

            @dc42 we have a unique use case that this might solve - or there may be an existing way that you can point us towards. We are interested in using a second extruder as an automatic filament unwinder as we use 10KG spools that put a lot strain on primary extruder.

            The idea would be to create another axis (F). It would be simple to have our post-processor duplicate the E commands into F commands like:

            G1 X124.761 Y43.556 E2.46118 F2.46118
            

            That would work, but its not how we want to tackle it. I threw together an algorithm which calculates the amount of filament used per layer and then generates a new command before the layer begins.

            ;LAYER_CHANGE
            G1 F304.84405
            ;Z:0.5
            ;HEIGHT:0.5
            G1 Z.5 F9600
            G10 ; retract
            G1 X95.404 Y57.128
            G11 ; unretract
            ;TYPE:Skirt/Brim
            ;WIDTH:0.75
            G1 F1440
            G1 X102.111 Y45.927 E1.74422
            G1 X103.445 Y44.47 E.26393
            G1 X105.244 Y43.654 E.26393
            G1 X106.339 Y43.531 E.14722
            G1 X124.761 Y43.556 E2.46118
            G1 X127 Y43.935 E.30343
            G1 X128.648 Y44.49 E.23234
            G1 X130.206 Y45.262 E.23226
            

            This would allow the second extruder to advance the next layer's filament at once. This would work as well, but currently, the print would pause while the F-axis "extruded" the next layer's filament.

            So our question is, with the new multiple motion system or anything existing, is there a way for commands to be executed out of process from the primary job's gCode stream?

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

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

              So our question is, with the new multiple motion system or anything existing, is there a way for commands to be executed out of process from the primary job's gCode stream?

              It looks like timing isn't critical for that application, so you could use the daemon.g file to run the filament unwinder.

              A problem I can see is that any error in the relative steps/mm of the two motors will cause the reel to unwind either too fast or too slowly. Have you considered using a switch to detect tension in the filament, and using it to run a DC motor to unwind the spool for a few seconds?

              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

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

                PS - I am currently testing and debugging the multiple motion support, and I hope to release 3.5beta1 soon.

                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

                oozeBotundefined zrunchoundefined 2 Replies Last reply Reply Quote 0
                • oozeBotundefined
                  oozeBot @dc42
                  last edited by

                  @dc42 The idea would be to advance F some amount (~100mm) at the beginning of the print so it is considerably ahead of E. We also have it worked out where there won't be any tension between the extruders.

                  So gCode executed by the daemon is out of process? We'll consider how we can cleanly get this information piped over to it. Thinking 'out loud,' from the job's gCode, we could call a custom mCode with the F value as a parameter. That mCode's job could be to convert the F-value into something consumable for the daemon. This would be a great use case for Arrays.. looking forward to that being introduced.

                  Thanks!

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

                    @oozebot alternatively you could have daemon.g monitor the rawPosition or position value for the extruder concerned. Those values are available in the object model.

                    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

                    oozeBotundefined 1 Reply Last reply Reply Quote 0
                    • oozeBotundefined
                      oozeBot @dc42
                      last edited by

                      @dc42 good call. Sorry to semi-hijack this thread, but can you please take a look at the following snippet? It works from daemon.g, but it is pausing the print when the C axis is moved. I thought this would be out of process from the job?

                      Hopefully I'm doing something wrong.. If not, would this scenario be supported by the update for multiple motion systems?

                      var rawExtrusion = 0
                      if job.rawExtrusion == null
                      	set global.spoolPosition = 0
                      else
                      	set var.rawExtrusion = job.rawExtrusion
                      	
                      if var.rawExtrusion > global.spoolPosition + 100
                      	G1 C{var.rawExtrusion - global.spoolPosition} F1000
                      	set global.spoolPosition = var.rawExtrusion
                      	G92 C0
                      
                      dc42undefined 1 Reply Last reply Reply Quote 0
                      • zrunchoundefined
                        zruncho @dc42
                        last edited by

                        @dc42

                        I don't have the modern Duet boards to make use of this code, but it's still exciting to hear that this is coming along.

                        Today I released a complete open-source Dual-Gantry CoreXY printer called Dueling Zero, w/configs, STLs, videos, CAD, docs, diagrams, the whole nine yards. The GitHub repo includes a sample RRF config for XY motion, which "just worked"... it was nice.

                        https://github.com/zruncho3d/DuelingZero/

                        6937f23b-d691-40a5-8e69-2c6021fd5ae3-image.png

                        Curious what you (and others on this thread) think. In particular, the section on collision detection and avoidance in a shared workspace is general for any firmware.

                        https://github.com/zruncho3d/DuelingZero/blob/main/SOFTWARE.md

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

                          @zruncho the RRF 3.5-dev branch now includes basic collision avoidance. See https://reprap.org/wiki/G-code#M597:_Collision_avoidance. Currently this is limited to checking for a minimum separation between one pair of axes, which is sufficient for IDEXY machines; but I have implemented it in a manner that allows it to be easily extended in future.

                          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

                          zrunchoundefined 1 Reply Last reply Reply Quote 1
                          • zrunchoundefined
                            zruncho @dc42
                            last edited by

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

                            https://reprap.org/wiki/G-code#M597:_Collision_avoidance

                            If I understand the G-code description, though, this seems like more of a "collision detect & then abort" than proactive avoidance?

                            "If this is not the case, the job will be aborted prior to starting the first move that would cause the conflict."

                            Still useful though! If I had this it would have avoided a few head crashes.

                            BTW, have you seen any other Dual Gantry machines printing? The Links section at the bottom of the README links to every bit of prior art I could find - mostly gantry renders for post (here), or one commercial model, the Essentium HD 280i.

                            https://github.com/zruncho3d/DuelingZero#links

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

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

                              @dc42 good call. Sorry to semi-hijack this thread, but can you please take a look at the following snippet? It works from daemon.g, but it is pausing the print when the C axis is moved. I thought this would be out of process from the job?

                              There is only a single motion system in the current RRF, so the C axis movement has to be inserted into that queue.

                              Furthermore, the G92 C0 command will wait until all pending movement has been completed and there is no movement before it executes. You may get better results if you can rewrite that code without using G92 C0, but there will still be slight pauses.

                              Hopefully I'm doing something wrong.. If not, would this scenario be supported by the update for multiple motion systems?

                              Yes.

                              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
                              • dc42undefined
                                dc42 administrators @zruncho
                                last edited by

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

                                If I understand the G-code description, though, this seems like more of a "collision detect & then abort" than proactive avoidance?

                                Correct. It's up to the slicer to do proactive avoidance. The collision detection is there as a backup.

                                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
                                • o_lampeundefined
                                  o_lampe
                                  last edited by

                                  @dc42 With a dual gcode stream, would it be possible to run a "colour-splicer" machine?
                                  The idea is to use a single Bowden tube hotend and feed it with filament cutoffs of different colours.
                                  The cutoff length would be calculated by checking the gcode for tool changes. (the toolchange macros are basically for cutting off the current filament and feed forward the next colour)
                                  The "length of the Bowden tube X extrusion speed " would determine the time it takes before colour "X" reaches the nozzle and the second gcode stream would do the motion planning with a fixed delay between splicing and extruding.

                                  1 Reply Last reply Reply Quote 0
                                  • misanundefined
                                    misan
                                    last edited by

                                    I considered this a while ago for CNC machining: https://fightpc.blogspot.com/2017/10/getting-work-done-faster-on-cnc-machine.html

                                    More than going for a self-scheduling system handling collisions, I went for a simpler system where both heads will swipe space from "left to right" keeping a safe distance. But I never went beyond the concept. In my case, each head could have a different Z height.

                                    dc42undefined 1 Reply Last reply Reply Quote 0
                                    • o_lampeundefined o_lampe referenced this topic
                                    • dc42undefined
                                      dc42 administrators @misan
                                      last edited by

                                      I finally got time today to work on this again. Here's an example of multiple motion systems in operation. https://www.dropbox.com/s/v18lgomkg44ald9/20221101_223148.mp4?dl=0

                                      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

                                      Hoops40undefined Aurimasundefined 2 Replies Last reply Reply Quote 6
                                      • Hoops40undefined
                                        Hoops40 @dc42
                                        last edited by

                                        @dc42 any updates? Also was wondering if there is capability in independent z axis as well?

                                        jay_s_ukundefined 1 Reply Last reply Reply Quote 0
                                        • jay_s_ukundefined
                                          jay_s_uk @Hoops40
                                          last edited by

                                          @Hoops40 RRF3.5b1 has been released with support for multi motion systems. I don't believe there is currently independent Z axis support

                                          Owns various duet boards and is the main wiki maintainer for the Teamgloomy LPC/STM32 port of RRF. Assume I'm running whatever the latest beta/stable build is

                                          Hoops40undefined 1 Reply Last reply Reply Quote 1
                                          • Hoops40undefined
                                            Hoops40 @jay_s_uk
                                            last edited by

                                            @jay_s_uk OK 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