Beta testers for multiple motion system support

dc42

We are adding support for multiple concurrent motion systems to RRF. The aim is to support printing two dissimilar pieces concurrently, or printing or machining two different areas of a single piece concurrently.

If you have a machine that is mechanically capable of running two tool heads with independent X and Y movement concurrently (for example, an IDEXY machine) and you would like to take part in beta testing this support, please reply to this thread with details of your machine, or alternatively email us (info@duet3d.com) or PM me. You will need to be using a Duet 3 MB6HC, Duet 3 MB6XD or Duet 3 Mini main board, and initially only standalone mode will be supported.

There is a documentation page about this support in development at https://docs.duet3d.com/en/User_manual/RepRapFirmware/Multiple_motion_systems.

wdenker

@dc42 I sure would love to! I have a corexyuvab utilizing 4 leadscrews, two independent gantries and heads. Would love this capability.

martin7404

@wdenker i am in for this testing.
I have a machne with 1 x axis and 2 independant Z axis with drilling velocity spindles VFD for simultaneously driling 2 diferent operations

GeneRisi

@dc42 is the memory space too limited with the duet2s ?

deckingman

@dc42 I don't know if my machine would fit your criteria but if you recal, the (6 input) hot end is on the XY gantry, and the 6 extruders run on the UV gantry. I currently use a python script to generate the UV moves such that the extruder gantry (UV) tracks the hot end (XY) but within a tollerance of +/-20mm so the UV moves are always shorter than the XY moves. It wouldn't be too difficult to slice the same part twice - once to generate the XY moves and then a scaled down version to generate the UV moves (although I'd likely have to run a python script to convert the G1 XY moves to G1 UV).
But if the goal is for the firmware to process two concurrent gcode streams, then I reckon I could test it.

kazolar

@dc42 my machine has 2 gantries with 2 independent heads on each. So as I called before a quad. 2 of the tools can be fully independent of each other, z is shared. If there is a way to synch z moves, this would be a cool project.

o_lampe

@dc42 I'd really like to be part of the test-team with my hashprinter. But it runs on @gloomyandy 's branch of RRF.
If he's part of the dev team or has access to your latest code (and is willing to colaborate) I'd love to test his branch.

A Duet3 setup with 11-12 stepper drivers is currently not affordable for me. (independent Z-axis would require 4 more steppers)
As a last straw I would sell the hashprinter (as-is) to someone in EU, who has the knowledge and funds to make it work.
PM me if you're interested...

JoergS5

@dc42 I will participate with two robot arms. Main focus will be collision detection and avoidance and I will help writing needed code.

gloomyandy

@o_lampe It looks like the code for this will be on the 3.5-dev repo. I will at some point be picking that code up and providing an STM32 version, so hopefully we will be able to contribute to the testing of this new feature. I usually try to track new developments reasonably closely so hopefully it will be possible to do that again.

oliof

@o_lampe I have an unused MB6HC and 3HC expansion board I can loan out to you. DM me for details.

o_lampe

@oliof That's very kind of you, but I'd need at least three 3HC boards or many other toolboards with 2 drivers per board. 15 drivers in total...

oliof

@o_lampe if one other kind soul finds they have a 6HC lying around you'd be set (-:

o_lampe

@oliof
Jepp, passing the hat is not my style. Unfortunately the shopping list would be alot longer (eg. hotends, direct drive extruders). That's why I proposed to sell my frame.
But it's over the top for a dual-motion system anyway. It would need 4 independent Z-axes and then it could work with two tools simultaneously. (then changing tools for perimeter and infill)
It's quite a challenge

oliof

@o_lampe you are not passing the hat if people propose giving, but I catch your drift. Unfortunately I have neither the funds nor the space for yet another machine, or I´d consider your offer.

breed

ive been working on this layout in the background while I finish other printers. should be what you are thinking correct?

o_lampe

@breed The critical thing about dual print heads and dual toolheads working simultaneously has always been the z-height. (mesh -leveling etc)
Idk if that's already in the scope of @dc42 project, but independent z-motion is the key for succesful multi tool systems.
Since you are still in the planning phase, you might consider adding an Z-adjustable toolholder. (I prefer dovetail sliders)

David, would you be so kind and tell us the options to drive the independent mini-z axes?
Geared DC-encoder motors would be small and strong, but they'd need a supporting toolboard.
Steppers would be huge and heavy. Remotely driven, it might be an option, if mesh leveling with backlash-compensation is available.

dc42

@o_lampe wouldn't a Nema 11 or Nema 8 stepper motor with leadscrews be suitable? Although the Nema 8 ones tend to be expensive. https://www.omc-stepperonline.com/linear-motor

breed

@o_lampe I haven't gotten near the point of adjustable z on one of the tool heads. I have 2 printers with makertech tilting hotend. They have grub screws for adjusting the heatbreaks, seems to work fine. I was hoping to get this one figured out and together by mrrf, but there are 4 other printers in the que in front of it. Maybe next year. Having automatic z adjustment would be awesome but the weight....I didn't want the common rail double x carriage because of carrying the second x carriage for all the y axis moves. I have an i3 style idex and basically never print mirror or duplicate mode. I def could see a path for simultaneous g code. Printing two different objects would be a useful time saver.

o_lampe

@dc42
It would work, but the weight penalty isn't worth the +/-1mm movement we need for Z-hop and mesh leveling.
Even a small hobby servo with excenter could do this, but their speed isn't controlable. That makes it difficult to move them in sync with XY motion.
So IMHO a dc motor with encoder would be the best option.
A mockup picture of a modified PTFE dovetail slider with dc motor/leadscrew

In a perfect world we'd have access to the heightmap(s)-data and route the z-correction to a device of our choice.

bot

What about shims to adjust hot end Z height? On my printer, I'm able to add shims to the top of the hot end to lower its nozzle's Z height.