Firmware / Configuration for Prusa MMU / Enraged Rabbit /SMuFF
-
Hey guys,
at the moment I am building a Voron Trident (I think my 4th or 5th Voron printer). When everything is set up I want to install the Enraged Rabbit Mod.
It's a Filament-Changer / Swapper similar to the Prusa MMU or SMuFF.
Is there anyone who already integrated a system like that into the firmware? The mechanics / base setup (2 steppers, 1 servo, filament sensor) are quite simple to get working in RRF3 (I plan to use a Duet 6 HC with a Duet 3HC expanison board for this).
The standard change precdure for filaments is quite easy too using macros and the t#post, t#pre etc. parts of the Firmware.In the last days I thought about possiblilitys I don't quite yet have solution for:
(1) The Enraged Rabbit Mod uses 2 Filament Sensors - 1 at the "filament changer" 1 at the tool head. I think these could be set up as external triggers with some macros and should work - I also could use the extrnal triggers for the filament change.
(2) Automatic continous printing: If one spool of the filament changer is empty (recognised by filament sensor) swap to the next spool. I think this could be implemented in some way with global variables...but I really do not know how to use them - is there any "good" example? I find the Documentation of GCODE-Meta-Commands is quite lacking in this regard (at least for people with limited programming skils).Maybe you could provide some input on this!
Thanks
Max -
-
@macnite said in Firmware / Configuration for Prusa MMU / Enraged Rabbit /SMuFF:
the Documentation of GCODE-Meta-Commands is quite lacking in this regard
A while ago, the forum proposed to have a gcode-repository for meta command macros. The CNC fraction has one, you could use to spy on.
The meta command forum has a few sticky-threads, you might find some useful hints there, too.Re MMU; the real magic happens during the tip-forming sequence. It makes sure, that the retracted filament doesn't leave a long stretched string of filament, which would tend to clog the hotend. If your MMU doesn't cut off the filament tip before loading, it is also useful to have a tip forming sequence. PrusaSlicers has some parameters, you can use to modify the sequence. But there is no support for it (AFAIK) in RRF.
-
-
@o_lampe tip forming doesn't need firmware specific support; it's an extrusion sequence that leaves the tip in a reasonable shape. That would be easily implemented as a macro.
-
@macnite I have no real progress other than thought experiments. Parts for my ercf build are probably a month out.
As for endless spool mode, it would be a macro that triggers in filament-error.g to change to the next spool.
I haven't decided if I want to represent the ercf as multiple tools or just macros that switches between tools
-
@pfn said in Firmware / Configuration for Prusa MMU / Enraged Rabbit /SMuFF:
@o_lampe tip forming doesn't need firmware specific support; it's an extrusion sequence that leaves the tip in a reasonable shape. That would be easily implemented as a macro.
So the tip forming is just a sequence in gcode? I thought it was done by the extra controller of the MMU
-
@o_lampe it's a retract, cool, fast extrude, fast retract sequence to give the tip shape. Whether it's controlled by an mmu specific mcu or in gcode, it would work about the same
