Multi color printing with Prusa's MMU V2 & Duet?

fma

For sure, MMU2 seems more reliable, and easier/cheaper to fix if it brakes. And interfacing it with the Duet/Duex is easy if you remove the electronic, and wire motors to the Duet. Then it is just a matter of a few G-Codes as macros to use it. Maybe ask Prusa if they can sell it without the electronic?

BTW, I'm working on my own filament multiplexer, but a mix between v1 and v2: a passive mux above the extruder, like in the v1, but a simple loader, not Bowden, like in v2. I'm waiting for mini-clutch to test my design.

bartolomeus

Someone is already designing an alternative. The design is on thingiverse. He also has a thread on this forum somewhere,

fma

In fact, there are 2 designs on Thingiverse (both guys are on this forum). I started mine because it is different in many ways...

OBELIKS

@fma Do you really think it would be easier without MMU v2 electronics? I think it should be possible to send the code to change the filament. But it is true you would need to change Duet FW to support this.
I really hope it will go this way.

fma

Well, wiring the motors on the Duet is a solution you can use right now, without any modification, so anyone can do it, and it does not need too much efforts nor skills...

I'm not sure it will be possible to communicate with the electronic, as it uses a SPI bus (MOSI/MISO/CLK are available - maybe not on a header, though - but it needs an additional CS - chip select - signal).

dc42

If the Prusa MMU needs 3 stepper motors, I wonder whether there is any cost saving compared to a 5-input Diamond, or a QuadFusion if 4 colours is enough for you; plus the 1 or 2 additional stepper motors and drivers. Also the Diamond and the Quad can do colour mixing, although the mixing isn't perfect.

If the MMU communicates with the main electronics via SPI, then you could connect it to the daughter board connector on the Duet. Of course, RRF would need to be modified to support the MMU.

tjb1

@fma said in Multi color printing with Prusa's MMU V2 & Duet?:

In fact, there are 2 designs on Thingiverse (both guys are on this forum). I started mine because it is different in many ways...

Do you have any links to these?

fma

Have a look at this thread: https://forum.duet3d.com/topic/6346/multi-material-filament-feeder-repurpose-e1-stepper-driver

There are links to both.

bartolomeus

@dc42 for me the benefit of the mmu2 is that it remains direct drive, and doesn't add mass to the X carriage.

deckingman

Just to add something to the mix, there is a company called RD4 which makes a multi filament feeder. It's called the RDB. They did approach me and asked if I would be willing to test one of their units, which I agreed to do. I signed a Non-Disclosure Agreement with them but alas they never did send me a unit or provide me with any information (if they had, I could not of course divulge anything). I note however that they have a stand at the TCT show so I'll stop by and see what's what.

Yet another alternative is the Pallete2 system by Mosaic.

Finally, the cheapest option is to pause the print, retract the filament, load new filament, purge and resume. Essentially, that is all that any of these systems do albeit in a semi automatic way. Unlike the Diamond and the Quad (and to some extent the pallette2) which have all the filaments loaded so switching between them is simple a matter of changing tools (which can be done "on the fly" without pausing the print).

martinj

I've made an MMU2 unit from some scrap parts I had laying around just as a Proof of Concept to see how if i could get it to work with Duet.

I haven't implemented any tramming which i do believe is important to avoid jams especially stringing is a problem.
I also think for it to be sort of reliable it needs to use some sort of filament sensor to check if the switch is successful or not so the print may be saved through manual intervention, though I haven't really found a way to solve this with Duet. I really would like to have some sort of conditional checking.

brunofporto

If the objective is just add collors one can create a multi pen filament colorizer (like this https://www.thingiverse.com/thing:11742 but with all colors you want)

Also I discussed with a friend to have a special tool that holds a pen (grabbed from a 100 color carousel) and just draw each layer perimeter with the color you want

JLink33

Hi, I built my own MMU2 and configured the Selector and bearing rotation mechanism with endstopless homing, but I cannot figure out how to configure the extruder drive motor with the five drive gears. How do I do that on the duet. What commands do I have to add to my config.g. Thanks

dc42

I am not familiar with the MMU2. Can you explain in more detail what the requirement is?

martinj

@dc42 the most critical actions for mmu is during unload/load of a filament where it could slip or jam. The way MMU2 handles it is to use a filament sensor to detect potential problems during load/unload.

Example when loading, move filament forward and check status of filament sensor. If doing this for X step and the filament sensor doesn't detect the filament you would do a retry phase, e.g back filament some and retry and if still doesn't succeed pause print for manual intervention.
Same principal would be used for unloading to verify it succeeds.

Unfortunately I don't see a way to solve this with Duet with its current functionality, and I don't have any suggestion on how it could be solved using GCode. Wish there were some sort of advanced scripting support.

fma

What about moving the intelligent script out of the Duet?

connect all motors to the Duet/Duex;
connect an arduino to the Due connector and to the I²C bus; also connect the filament contact on the MMU carriage to that arduino;
write a Duet macro to send a specific code over I²C when filament change is needed, and pause the print;
send required G-Code to the Duet to move the motors, check the sensor, do the retries if needed...
send a resume command to the Duet.

Note 1: you may use an esp8266 and control the Duet over wifi instead of serial;

Note 2: this arduino/esp could also communicate with the original MMU electronic, over SPI, so you don't need a Duex. As Prusa board firmware is open, you could re-use most of its code to handle the MMU electronic communication. The only thing to do is to sync Duet and MMU.

martinj

@fma It was actually my initial thought when i was thinking of making a MMU2. Connect and run everything externally. However it does increase the complexity, was hoping to be able accomplish it only using the duet.

fma

Well, most of the code is already written in Prusa main board firmware, so there is not that much work... More adding some glue ;o)

Bester42

@fma I think its even more simple, if you use an arduino.
Simply connect the arduino to DIR and STEP of the extruder driver. Let the Arduino count steps every time DIR is in backwards direction (reset counter if a step is done forward). If the number of steps exeed a certain number, obviously its not retraction but filament unload.
So the command to change filament is unload filament.
The arduino than sends the command to retract the filament into the MMU to the controller of the MMU.

To select the new filament, let the extruder step into forward direction for 1-5 mm. This does effectly nothing, as the extruder is empty. But the arduino can interpret this as "I want filament 1-5", so command in gcode would be extract 1mm filament to select filament one. The Arduino than sends the code for Filament selection to the MMU.

Than let wait for Filament change completed by the MMU. Than the arduino triggers a gpio on the duet; in gcode its an m226 to wait for this pin. Than start loading (if your printer has autoload, this is notneeded, simply use m600 insted).

This technique may work not only with a Duet, but with nearly any 3d fdm-printer, even the cheapest ones - if you dont have access to dir/step signals, use an optical encoder on the extruder-motor, if you do not have a free gpio or autoload-function, set a relais in parallel to the O.K.-Button and use m600.

Only think is calibration. You may do that by terminal via Arduino to the mmu.

fma

I agree, this is a good solution...

In fact, there is already an Arduino in the MMU2! Don't know if there are enough inputs, but it could be interesting to just have to modify MMU2 firmware to implement your proposition...