Independent Dual Gantry - any examples out there?

zruncho

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.

zruncho

Probably relevant, it's a dual CoreXY setup.

chrishamm

@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.

droftarts

@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

zruncho

@droftarts

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...

zruncho

@zruncho

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.

droftarts

@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

zruncho

@droftarts

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?

breed

@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.

breed

@zruncho would love to see the printer and what belt routings you went with.

zruncho

@breed

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...

zruncho

@breed

I'll share it all on GitHub once I've addressed a few minor items, just like all my other printer mods:

https://github.com/zruncho3d/

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.

zruncho

@droftarts

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.

oliof

@zruncho super interesting! for someonwhat simplified belt runs, you could look at Dual Wire Gantry / Slid3r kinematics.