Independent Dual Gantry - any examples out there?
-
Re: independant dual gantry corexy
I've recently built an independent dual gantry printer. This is not an IDEX; the toolheads are on independent gantries.
I'm looking for any examples of how to configure it so that, like an IDEX, the toolheads can both share in a single print, by taking turns.
Any ideas out there, especially @dc42 ?
There was this thread:
https://forum.duet3d.com/topic/24258/independant-dual-gantry-corexy/10... but it seemed to die long ago, and the forum encouraged me to create a new thread vs rekindling the old.
Thanks! I've got a Duet2 WiFi all upgraded to the latest code now, and I'd love to know if/how this is possible.
-
Probably relevant, it's a dual CoreXY setup.
-
@zruncho I don't think it is possible yet but it will come in v3.5 - RRF is being changed to support that. We will publish a first beta in a few weeks.
-
@zruncho if you mean that you want one tool/gantry to print, then park that tool, then have the second tool/gantry print, yes you can do that. Each axis will need to be set up as a separate axis, eg X, Y, U and V. Each axis pair (X, Y and U, V) and nozzle will need to be set up as a different tool. As most slicers generate Gcode just for X and Y positions, your tools will need to define which axes to use when a particular tool is enabled. This is done in the tool definition M563 using the X and Y parameter. There’s an example of how this is used on IDEX page here: https://docs.duet3d.com/en/User_manual/Machine_configuration/Configuration_IDEX#creating-a-tool-that-uses-more-than-one-carriage-to-print-multiple-copies-of-an-object
Homing and tool change macros will have to customised, to home the XY and UV axes in opposite corners so the tools don’t clash, and set the tool offsets on tool change.
I think that covers it in theory! Let us know if you need more specific help setting it up.
Ian
-
Thanks... that does seem to cover most of what I'd need for config.
Should the g-code that the slicer generates then include T0 and T1 commands to trigger the 'tfree*.g'? That's the bit I'm missing here, and maybe it's just that.
Looks like no g-code postprocessor will be needed here to make use of the second gantry, which is pretty cool. Seems like Duet's been designed for this or something...
-
I got a different message in this thread about the possibility of making a dual gantry work; what missing feature would be needed in RRF 3.5 to enable this?
Thanks.
Also, are you aware of any public references to a machine like this? I'll put mine on GitHub soon enough, but curious to see any others. Dual Gantry is a lotta work, but it's definitely an interesting setup if your goal is to learn.
-
@zruncho Yes, if you define multiple tools in the slicer, and load a model that needs more than one type of extrusion, the slicer takes care of sending the commands to change tool. When a tool change command is received, the Duet takes over the actual tool change, using whatever has been programmed into the tool change macros. See https://docs.duet3d.com/en/User_manual/Tuning/Tool_changing
The development in RRF 3.5 is for independent streams of Gcode, ie you can run two different gcode files at the same time, and cause the different tools to move independently. However, some coordination may be necessary if trying to print two different objects, each with a different tool; the firmware doesn't stop clashes between tools trying to move in the same area (probably best to limit print area of each tool so they can't clash), or synchronising layer changes (not sure how this is going to get dealt with). Fun times!
Ian
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
Interesting. I really don't see how that would be useful without a way to sync Z motion between the two streams. What's the driving use case for that functionality?
-
@zruncho for a simple single gcode stream idexy it's def possible. I've been working on two designs for a while now but other projects have pushed them back in priority. Remember you are still gonna need a way to adjust z on one head to the other with the probe.
-
@zruncho would love to see the printer and what belt routings you went with.
-
On my Hybrid-CoreXY IDEX ("Double Dragon"), I enlarged the toolhead mount holes slightly, then tapped one toolhead into position, using a shared nozzle endstop to precisely measure the Z height difference. Took < 5 m to get < 0.01mm alignment.
https://github.com/zruncho3d/double-dragon
https://www.youtube.com/watch?v=GY29F2O1unw
Gonna do the same thing on the IDG printer, since I know it works...
-
I'll share it all on GitHub once I've addressed a few minor items, just like all my other printer mods:
As a teaser, imagine two BoxZero gantries, with one rotated 180 degrees, plus all-custom XY joints so that both gantries can have shared rails.
-
On v3.4, I was able to get everything working without issue, from your suggestions. Thanks!
It was all pretty straightforward - define a CoreXYUV, map the axes and endstops, and verify it all as a CoreXYUV, first. Then set up to the tools, where the second one maps (U, V) to (X, Y), and ensure they work as expected with T0 and T1, where each of these parks the toolhead.
Seems all good... with no pain, surprisingly, so far. I know the XY offset calibration to come will be the bigger pain.
-
@zruncho super interesting! for someonwhat simplified belt runs, you could look at Dual Wire Gantry / Slid3r kinematics.
-
@zruncho said in Independent Dual Gantry - any examples out there?:
On my Hybrid-CoreXY IDEX ("Double Dragon"), I enlarged the toolhead mount holes slightly, then tapped one toolhead into position, using a shared nozzle endstop to precisely measure the Z height difference. Took < 5 m to get < 0.01mm alignment.
https://github.com/zruncho3d/double-dragon
https://www.youtube.com/watch?v=GY29F2O1unw
Gonna do the same thing on the IDG printer, since I know it works...
The main culprit about dual independent gcodes is: you can't use mesh leveling.
So, even when you have adjusted both toolheads to same height, your bed needs to be 100% flat and true to the XYUV axes.I've designed a 4-toolhead printer called the hashPrinter. It's not a CoreXY design, which makes beltpaths short enough to increase the framesize. I can park all tools outside of the printzone, which eliminates the need of most of the endzone dance you described on your Github.
See here for details -
Amazing work on that! I hadn't really understood it from skimming the thread, but I watched your video:
https://www.youtube.com/watch?v=Lo-ymCO0Ekw... and the great animations made it clear. How did you do them?!?!?
Anyway, I'm personally not too worried about mesh leveling, as all my printers either use a MIC6 bed or glass plate and none require mesh leveling, just bed tramming. A little variance in the first layer is probably OK anyway, especially if using textured beds, with parts that have first-layer chamfers.
re: parking outside - that's an option w/a Dual Gantry too. You can do that with the world's simplest T0/T1 gcodes to move to a parking position:
https://github.com/zruncho3d/DuelingZero/blob/main/Diagrams/workspace_dual_corners.png
-
modern magnetic flex Steel print surfaces are easy to shim too. you can even have differently shimmed sets for different target temperatures.
-
@zruncho said in Independent Dual Gantry - any examples out there?:
... and the great animations made it clear. How did you do them?!?!?
They're not my work, but a starting point for my design with the anti-racking Aramid wire stuff. I can drive each axis with only one belt, which makes the whole setup very compact and simple.
@oliof I agree, we don't necessarily need mesh leveling, since there is also the option to print a raft first.
But I mainly build prototypes with a little less accuracy, just as a proof of concept. So I'm glad there is some cheat mode available....and there is still no cure against gantry sag, other than mesh leveling. Except building an oversized, but heavy gantry.
