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

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

Bester42

You are perfectly right.

The reason to use an extra Arduino (clone) is Prusa Research contantly improving and updating not only the printers firmware, but also firmware of mmu.
So by adding an extra Arduino (Clone) you add only a cost of 3-4€, but making maintence much more easy.

Also an Arduino is not an multitasking system. So checking gpio's, constantly control extruder movement, you have to make shure not to interfeare with the mmu's functions. So it would require much more programming skills.
Using an extra Arduino the code would be much more easy. It's strictly single task.

Watch rotation of extruder
If unload detected, send comand to mmu
Watch rotation of extruder
If movement (1-5mm) detected, send comand to load and Insert filament 1...5
If a filament sensor detects Filament Inserates (or mmu tells thad loading ist completed) give signal to the printer.
Goto 1.

I do not think Prusa will change comands a lot in future (maybe add "success" comand from printer if the printhead filament sensor detects loaded filament - but due to bad relability of prusas sensor I do not think this coming soon). So an "Interface-Arduino" is much simplier than modding mmu-firmware, much more easy to modify.

gavatron3000

Might be another idea to use this fellas version of the firmware for Arduino but modify it to change via multiplexer or a digital IO somehow. That way the duet initiates the changes but it fully controlled by the Arduino. He's also added another sensor to the system
https://github.com/cskozlowski/mmu2

patakopecek

I think it would be possible to do everything (even the checking with the finda) via the duex board, David suggested to set up the finda for a dummy axis that would try to home while moving the E and the dummy axis at the same time, that would be for the FINDA part, the macros would handle the filament switching part but the only problem I could find is the filament cutting part, it is not possible to assign macros to the stall detection, so the cutting could not be triggered

dc42

@patakopecek, supporting macro execution on stall detection is under consideration for a future firmware revision.

gavatron3000

the problem ive found when trying to home to endstop/pinda is if it doesnt reach the sensor it just carrys on with the rest of the macro, if there was a feature to home to endstop but if not reached by Xmm or Xseconds then pause or retry. but this may be leaning towards conditional gcode

ive got a home built MMU2 unit hooked upto the duex2 now, just testing at this stage

dc42

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

the problem ive found when trying to home to endstop/pinda is if it doesnt reach the sensor it just carrys on with the rest of the macro, if there was a feature to home to endstop but if not reached by Xmm or Xseconds then pause or retry. but this may be leaning towards conditional gcode

If it doesn't reach the endstop, then I presume either the amount of movement specified in your G1 S1 command is too low, or you are using G1 S1 without selecting relative coordinates first, or your axis is getting stuck. The first two are easily fixed, the last is mechanical

gavatron3000

Yes exactly, the drama is with relation to the mmu2 is if there is a jam during loading the firmware isn't able to detect this until perhaps the filament sensor is reenabled just before printing with a new tool
This also applies when unloading too
I guess though it still picks up the error eventually, I'll try jigging the macro's differently by enabling the filament sensor at different points see what outcomes occur during tool changes

Just thinking out aloud here, don't mind me

gavatron3000

Hi all, id thought id report back to say running the mmu2 with the duet and duex is possible and working even with loading and unloading detection using the "finda" style setup. its all working as expected now i just need to dial my ramming settings to get good tips. if anyone has any questions let me know. but its a win

my next thing is to setup filament-change.g to unload filament through the front of the mmu

Ungreon

I'm assuming you got the full thing working without the prusa MMU v2 board? If so did you modify the MMU assembly at all or just assemble it without the board? Would you consider sharing the g code or slapping together a short tutorial on how to accomplish your solution?

gavatron3000

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

I'm assuming you got the full thing working without the prusa MMU v2 board? If so did you modify the MMU assembly at all or just assemble it without the board? Would you consider sharing the g code or slapping together a short tutorial on how to accomplish your solution?

So my mmu2 is just the original without the Prusa electronics. It's hooked up to the duet and a duex2. Longest part in getting it running was getting the endstop configuration on the fly and loading and unloading detection triggers running correctly with additional axes. I'm happy to share my macros, I'll write some things down and share when I get some free time.
Hardest part is shaping the tips so it's reliable,

gavatron3000

Here's the first document I wrote for the mmu2. Treat it as a beta at the moment as I'm sure as more people get more hours with it I think there would be improvements.

https://docs.google.com/document/d/13r_6BTYTO-xlD6cQeNwOx4qeCEYYGrxOcHc0mC-tT8Q/edit?usp=drivesdk

NicoLab28

I used the few scripts you had given me, and it's almost starting to work for my MMU.
But my questions are, do you use a cutter, and where?
Do you use ABS filament or just PLA or other.

For my part, I have big problems with the ABS, because it happens to make obstructions, or he puts me back pieces.
The only solution I found is to cut as close to the head as possible.

I saw that some used a cutter at the level of the selector, but it might congest too?

gavatron3000

I don't use the cutter, for me I didn't think it's necessary as the ramming before retraction forms the tip anyways. Abs just works but pla is more difficult. Make sure you use the correct I.D PTFE tube in the Hotend as well. 1.8mm to 1.85mm. capricorn tubing isnt narrow enough either, ive tried.

I almost forgot! I'm adding some modded STL and scad files soon so the filament change will function perfectly as the filament ejection will snag on T4 without a small mod to the selector and main body of the mmu2

NicoLab28

You are in live drive, I looked at your Tipsmoothing.g
10s break anyway, it's just for testing, or is it really necessary?

On my side, it is not too much a problem of diameter of ptfe, I ordered, but of hair, which does not see itself and accumulates until stuffing. I should test your method.

I put transparent tube, and it is obvious.
The worst thing is that it's not regular, it happens from time to time. 15-20 tool change without worries, and boom!
That's why, I put a cutter.

I have the impression, that reliability will be a very hard thing to obtain.

I think I'll test the standard version, what change do you think you'll make? Your files are coming soon?