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

      @slaughter2k I'm sorry, I accidentally gave the URL of that page that allows editing. Your link is correct.

      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
      • slaughter2kundefined
        slaughter2k
        last edited by

        no issue...
        "one" thing I don't fully understand yet from the documentation:
        "For command streams that originate from file, each motion system uses a separate GCode processor..."
        --> Is my understanding correct that ...from file... means that the gcode has to be stored on SD card?

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

          @slaughter2k yes, to make maximum use of the multiple motion support, you must print from SD card on the Duet, or if using attached SBC then from a file n the SBC. The beta1 release may not support using multiple motion systems when printing from SBC.

          It's possible to use multiple motion systems when not printing a file, however in this case a single GCode processor is used so it will only possible to move the two motion systems concurrently while both movement queues are not full. Whereas when printing from file, each motion system has its own GCode processor that reads from the file independently of the other one.

          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

            I started a discussion about various printer kinematics here.
            Meshleveling with two tools is still unsolved, but it's worth keeping this option in mind for a future build.

            dc42undefined 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:

              I started a discussion about various printer kinematics here.
              Meshleveling with two tools is still unsolved, but it's worth keeping this option in mind for a future build.

              Independent mesh levelling requires independent adjustment of Z heights. Unfortunately there is a patent on that in (at least) US and EU. There is another patent on independent motion systems, but I have been told it is US-only.

              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
              • 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
                                            • First post
                                              Last post
                                            Unless otherwise noted, all forum content is licensed under CC-BY-SA