SMuFF - Smart Multi Filament Feeder with #Bondtech gears

by christian-gegg Feb 16, 2019
Download All Files

Thing Apps Enabled

Please Login to Comment

Hallo Christian,

echt tolle Arbeit!

Eine Stepdatei mit dem kompletten Zusammenbau würde es Einfacher machen wenn man kleine anpassungen vornehmen muss.

Danke Gruß Timo

Danke für das Kompliment.

Was z.B. würdest du denn anpassen wollen?

Es geht mir eigentlich darum, wenn man z.B. halter Bohrungen um den SMuFF irgendwo zu befestigen anbringen möchte oder wenn man statt der verwendeten Bauteile vielleicht "schon vorhandene" Bauteile verwenden möchte die z.B. andere abmaße haben. Eventuell andere Stepper Motoren, statt Nema 17 einen Nema 14 für den Selector. Ohne STP geht das auch ist aber sehr umständlich.
Falls du das nicht möchtest ist das kein Problem, war nur eine Frage.
Grüße Timo

Christian, can you provide the fusion 360 or a STEP File of SMUFF?
I´d like look more into the design and maybe change something to use my material I already have at home.

This is amazing, im sure Joseph Prusa is pissed XD.

Thanks for the compliment.

I don't think he's pissed. I don't know Josef Prusa in person, but judging from what he has done for the maker community, I think this project is in his spirit. As in "learn, make, share".

That being said... loooooooool

Have you got a list of lengths for the 9 material version?

Sorry, no I haven't.
Simply add 4 times 21 mm to the length of the rods for the 5 material version - which is the size of one filament guide block and increase the number of bearings, fittings and stuff for each additional filament guide block.
This might help: https://youtu.be/z5ulHYynAa0 (leave out the brass insert and screw at the bottom since they're not needed anymore).

That is brilliant thank you,

Also the mainboard does these only work with the duet board? or can i use an skr 1.3 (marlin 2.0) as the main board?

I'll try to rework the BOM and create a dynamic version.

As of now, only Duet3D has been fully tested (which is what I have). As I've mentioned in one of the updates, I've implemented the Prusa MMU2 protocol, which is supported by the SKR 1.3 running on Marlin 2.0 (as far as I can tell from reading the source code) but this has not been tested yet (afaik).
If you wanna give it a try, I will assist you as good as I can.

Ok thank you for the reply,

i Am planning in converting my any cubic predator and use this on it since it has the largest build volume i have at the moment.

Also, thank you for the updated BOM with the auto adjustments for the number of feeders

You're welcome.
Please let me know if I missed something in the BOM.

Talking about the conversion: I know I sound biased (mostly because I am ;o) but I'd recommend the Duet3D if you haven't made a decision yet.

I am slowly working my way through the BOM and sourcing parts. The integrated leadscrew proves problematic.

As for the duet, I would love to upgrade to one of them but the price really puts me off considering I live in the UK its way more expensive then else where

  • Posted with 3D Geeks Thingiverse Browser App

Have a look at "Update 6" of the description. Solves that "integrated leadscrew" problem.

I've been thinking about an SKR 1.3 recently to upgrade the old Flashforge Dreamer to something really useful. I compared it to the Duet Maestro, which is more than sufficient for this project and figured that the Maestro comes cheaper since it has the drivers already on board.
Using the Maestro, you also may recycle the old display - so no money to spend on this.

Overall, I just love the way the Duets handle the configuration. Fiddling around in the config.g is - in my opinion - much less time consuming and much more efficient than compiling and uploading. You simply can try different parameters just to see how they perform even while the printer is printing.
This way I've optimized my printers, so that my default printing speed setting in the slicer is set to 100 mm/s and I rarely go below, except I have some really small parts to print (yeah - sometimes I even print Benchies with a 180 mm/s ;o).

That's great thank you, I must of skimmed right over that update.

And yes I think I will go with the duet for my predator since someone has done a full conversion with mag all arms and such

  • Posted with 3D Geeks Thingiverse Browser App

I'm pretty sure you won't regret.

I went in trouble as I tried to use the SMuFF.cfg
Message: CONFIG FAILURE Your config file is too big, please reduce content

SDCard is 4GB big with FAT16 (also tried FAT32)

How can I fix it? File looks quite fine
Using Macbook

Yeah, I've got the same message quite some times and it almost drove me nuts.

First of all, make sure you don't have an old config where the "I2CAddress" setting is set to 0x88. The "0x" is not being recognized by the parser. The newer configs have that setting written in decimal notation.

Also, make sure that the file size doesn't exceed 1200 bytes (remove the materials if this is the case).
A good way to test it is to copy and paste the config file in here: https://arduinojson.org/v6/assistant/
That's a tool from the maker of ArduinoJson, which parses the JSON string and check its size and syntax.

If that doesn't solve it, try using a different SD-Card, which is what I had to do once in another project using the i3 mini controller.

Another thing I've discovered once is that the free memory dropped to about 200 bytes (which usually is supposed to be about 2000 bytes). This happens if the RX line of the 2nd serial port is open or disconnected (the one that goes to the SMuFF-Ifc). Either connect it or use a pull-up resistor on that input pin.

Thanks Christian,

The file size was the issue.
I downloaded the file from your github before. I did some changes and I could downsize from over 1250 bytes to 1183 bytes

With the file below it works :)

Glad you got it working!
The problem is that the file size can't be extended anymore since the memory on the device is very limited and the JSON gets expanded into the main memory while parsing. So reducing is the only way to go.

Not sure about this - just a wild guess: Maybe the indentation tabs (\t) get expanded to spaces at some point, which can cause the file to exceed the set limit. I'm sure I replaced all spaces with tabs.

It's a brilliant design, about the controller, does it have to be the duplicator i3 mini? or any 3d printer controller board will do? Thanks.
At this point, I guess the only thing stops people from making it is probably the price, even if all parts are sourced from aliexpress, it still adds up to 200+

Thank you, glad you like it.
No, it doesn't have to be the i3 mini controller. I've picked this one because of its small form factor and because it has all components needed on one PCB.
You can use any other controller board based on the ATmega2560 chip but you'd have to adopt the pin configuration and the housing yourself.

Yes, it's pricey - no doubt - but I guess that is to be expected when geeky freaks build something for their own day to day use and simply expect them to function in every single print ;o)
That's also the main reason why my printers are all equipped with (genuine) Duet3D boards.

Don't forget, that if you build such a machine, you'll get a five fold Bondtech extruder equivalent, which doesn't come cheap even if you get them from aliexpress (which I'd not recommend - intellectual property - yadda yadda).

ok done a complete and even reverse turn

on the other hand, depending on the state of the butee on the presence of the filament
open or closed it turns or not


That's true. If the feeder endstop signals "loaded", the SMuFF will ask you to unload before homing. Also, if the line Feed on the main screen shows a checkmark, the feeder endstop has triggered.

what you quote as solutions I already tested
I think the concern comes from the endstop
they cut not frankly except that of the selector

If you disconnect the endstop, the Revolver is supposed to make a full turn. If that's not the case, theres something wrong with the stepper wiring. Have you tried this?

put video online


many times home


Ok, looks like the stepper is going the wrong direction.
Let's assume, the stepper is wired correctly, do the following:

  • set the InvertDir option in the Revolver-section of the config file to false if it's currently set to true or vice versa
  • select "Motors off" in the Main menu and rotate the Revolver manually until the endstop flag hits the endstop (LED on the endstop is supposed to go off - same as on Selector).

If those changes do not help, check the wiring of the stepper and also the reference voltage (Vref) on the Revolver stepper driver (as mentioned here https://github.com/technik-gegg/SMuFF-1.1/wiki/Wiring-the-i3-mini-board).

The Revolver is supposed to turn in the opposite direction (as it's doing in your video) to reach home position. If this is the case and it still doesn't move to home position, try changing the EndstopTrigger value (0/1) of the Revolver-section.

Comments deleted.

I'm having a problem with "Revolver"
when I do "home" "selector" stop on the endstop ok.
"revolver" hardly moves and stops anywhere.
endstop "feeder" closes ,no thread for testing
  thank you

Can you make a short video and put it online?

start bdes test

thank you!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

That looks beautiful! Great job!

Let me know how it works for you. I hope, you'll publish some printed models soon.

the compilation with platformIo of the SMuFF1.1 program
gives an error. made with two different pc's.

initial version with arduino ide without problem

thank you for the job

Yep. You somehow duplicated SMuFF.cpp into main.cpp... which is the source of the error.
Simply delete main.cpp from the source folder.


super !!!!!!!!!!!!!!!!!!!merci

pieces commandees

pour mettre sur corexy voron et duet wifi

Il n'y a pas de quoi.
Prévenez-moi quand vous aurez fini les parties et je mettrai à jour les scripts Duet3d car je suis en train de les peaufiner.
Si ce n'est pas trop compliqué pour vous, écrivez en anglais pour que les autres en profitent aussi.

I know its a newbie question, but can this thing do what mmu2 does, because i only look the video... and in the video just show color changing on z axis

The colors are applied through your model not the device itself.
So the answer would be: Yes, it does more or less exactly the same as the MMU2 or any other filament changing tool does.

okay, soo thats cool, maybe try to print something pretty hard like multicolor gekko or josef prusa's model..... maybe that will cool, but if you have enough filament though

I know its a newbie question, but can this thing do what mmu2 does, because i only look the video... and in the video just show color changing on z axis

I know its a newbie question, but can this thing do what mmu2 does, because i only look the video... and in the video just show color changing on z axis

No makes on this yet???

Very Very Very nice design mabie i'll implement on my corexy

Thank you! Glad you like it.
I'd say, if your CoreXY is driven by a Duet3D, go for it!

Got an SKR 1.1 Marlin 2.0 and i think marlin 2.0 already supports tool changing but will dig more in to it

I've added a Prusa MMU2 emulation mode to the latest version of the firmware (1.2).
Hence, you should be able to drive the SMuFF without modifying the marlin firmware by just pretending it's a Prusa MMU2.
Not sure if this works, since I don't have an SKR controller to test.
Let me know if you still plan to build one.

I guess you're right.
I browsed the Marlin 2.0 code just minutes ago and I'd say, it looks very promising. It's pretty modular and at first glance I think it doesn't need many changes.

I looked at the 'feature' folder and especially the Prusa_MMU2 feature (https://github.com/bigtreetech/BIGTREETECH-SKR-V1.1/blob/master/firmware/Marlin-bugfix-2.0.x-SKR%20V1.1/Marlin/src/feature/prusa_MMU2/mmu2.cpp).

The cleanest approach would be to create a new feature, let's say '/feature/SMUFF/' and add files SMUFF.cpp / SMUFF.h to it, whereas SMUFF.cpp needs to implement the public function SMUFF::toolChange(uint8_t index) (at least, don't know what else Marlin 2.0 needs for interfacing).
Then, the module toolChange.cpp (https://github.com/bigtreetech/BIGTREETECH-SKR-V1.1/blob/master/firmware/Marlin-bugfix-2.0.x-SKR%20V1.1/Marlin/src/module/tool_change.cpp) needs to be extended like this:

  #include "../feature/SMUFF/SMUFF.h"

and somewhere in the toolChange function itself:

    UNUSED(fr_mm_s); UNUSED(no_move);


And of course, somewhere in the code the 'smuff' instance has to be created and the serial interface has to be defined as well.

The not so clean approach would be to adopt the SMUFF GCode parser to interpret the commands sent by the Prusa MMU2 and act accordingly.

Either way... code must be changed / extended but at least it's doable and - as it seems to me - with less effort then in the Marlin 1.x.
One major culprit of Marlin 1.x is the non existing second serial port for communication, which has been added in 2.0 apparently.

but first i need to order some parts ^_^, i din't understand one part your smuff needs to accopolate to the extruder or is direct bowden ?

You can do either the one or the other (it's configurable through the SMUFF.cfg file on the SD-Card, as stated here https://github.com/technik-gegg/SMuFF/wiki/Configuration-file-(SMuFF.cfg)).

Since it's utilizing Bondtech gears, I recommend direct bowden. In this case, the SMUFF doesn't control the feeder, only the revolver and the selector. The feeder is supposed to be controlled through the E1/2 stepper of your mainboard.
Some sample configurations can be found here: https://github.com/technik-gegg/SMuFF-Ifc