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

    Simultaneous printing with collision zones and semaphores

    Scheduled Pinned Locked Moved
    Gcode meta commands
    3
    7
    443
    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
      last edited by o_lampe

      Hi guys,
      back in Aug. 2015 I introduced my idea of "Four SCARA printers on one bed" to the RepRap community.

      square-scara.jpg
      It was not possible then, although handling the collision zone wouldn't have been too difficult.

      Now with conditionals and variables (soon) it would be much easier to implement. I'm not sure if the concept of semaphores is possible with meta commands, but the communication options between various mainboards to implement a semaphore-handler are there.

      What would be required to have four tools work simultaneously on one part?

      • each tool has it's private area to print undisturbed
      • We'd need collision zone definitions in the M208 print area ( left and right neighbour)
      • each tool has it's own small Z-axis to make mesh bed leveling and Z-hop possible.( a servo or linear actuator will do)
      • only one mainboard has full control over the real Z-axis and it requires green light from all other printers, before it moves the bed to the next layer. (semaphores)

      How to handle the collision zones?
      Each time the lookahead planer identifies a track that leads into a collision zone, it triggers the semaphore handler. If the zone is free, it reserves the semaphore.
      If not, it goes into pause mode and resurrects when the semaphore is free.
      An advanced semaphore handler would tell how long the zone is blocked and if possible, the printer who wants to enter the zone would run slower to avoid going into pause/resurrect.

      What about the Slicer?

      • the part has to consist of four sections. They'd be sliced with different tools and in consecutive order. That makes it easier to split the gcode up for each printer.
      • there might be tracks, which start or end in the collision zone. This problem requires more coffein, I haven't found a solution yet. Maybe the whole part has to be split in eight sections? Four private sections and four collision zones.
        A postprocessor would then sort those zone-tracks to the best matching tool. (depending on start-, endpoint of the track) A track that starts and ends in a zone would need a preset priority (each printer takes care of it's left zone)

      Is it all worth it?
      I think so. In 2015 no one would've tried to print parts bigger than 30x30x30cm. Newbies who asked, how to build a 1m x 1m x 1m printer were treated as dreamers.
      But that's no longer the case. The demand for bigger prints is growing and printing these in less time gets you in the winnerzone.

      That's it for the moment. I re-introduced you to the idea and probably have to wait another 5 years to see it realized. I won't be able to try it out myself for financial reasons, so it's up to you 🙂

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

        It doesn't have to be four SCARAs, four monorail Tripterons would also be fine. See
        Or a dual gantry IDEX printer with four independent tools?
        It's up to you.

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

          We're looking at options to run multiple independent motion streams (initially just two) concurrently. The idea would be to assign every axis to one of the motion streams, then each move would be assigned to a motion stream depending on which axes it refers to. We would also introduce a new GCode meaning that the streams should be synced at that point, i.e. whichever one reached that command first would wait for the other to catch up, probably with the option of running a parking macro. When the other had caught up, both would continue.

          I think that should be enough for the slicer to split parts of the model between motion streams, and to implement collision avoidance by ensuring that with each segment between sync commands, the areas occupied by the two motion systems are disjoint, allowing for the size of the print heads.

          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

          janusofdoorsundefined 1 Reply Last reply Reply Quote 0
          • janusofdoorsundefined
            janusofdoors @dc42
            last edited by

            @dc42 said in Simultaneous printing with collision zones and semaphores:

            We're looking at options to run multiple independent motion streams (initially just two) concurrently. The idea would be to assign every axis to one of the motion streams, then each move would be assigned to a motion stream depending on which axes it refers to. We would also introduce a new GCode meaning that the streams should be synced at that point, i.e. whichever one reached that command first would wait for the other to catch up, probably with the option of running a parking macro. When the other had caught up, both would continue.

            Could this be taken one step further and allow for two printers to print simultaneously off a single board + expansions?

            dc42undefined o_lampeundefined 2 Replies Last reply Reply Quote 0
            • dc42undefined
              dc42 administrators @janusofdoors
              last edited by

              @vishiano said in Simultaneous printing with collision zones and semaphores:

              Could this be taken one step further and allow for two printers to print simultaneously off a single board + expansions?

              That would be more complicated, for example you would probably want a mechanism to pause them independently. With the Duet 3 Mini costing little more than the EXP3HC, would there be any point?

              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

              janusofdoorsundefined 1 Reply Last reply Reply Quote 0
              • janusofdoorsundefined
                janusofdoors @dc42
                last edited by

                @dc42 Would be more for fun I suppose 😊

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

                  @vishiano said in Simultaneous printing with collision zones and semaphores:

                  Could this be taken one step further and allow for two printers to print simultaneously off a single board + expansions?

                  @dc42
                  I would also opt for independent controllers, because they would each have their own Z-probe and mesh leveling.
                  Right now, there's only one Z-probe allowed AFAIK and independent mesh leveling is important when two tools work at different places.
                  My proposal was to use a mini-Z axis on each tool for height adjustment and Z-hop.
                  Your new approach has means to implement that, too?

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