Closed revilor closed 5 years ago
the latest versions of marlin have all the options for it
Where can I download?
It's all within the latest release of marlin, but again I'm not sure if what I've by will work or if there are more options that need to be tweaked as I haven't got my mmu2 yet. Was hoping someone here could help me eventually
I the Marlin 1.1.9 is no included. Could you send me the download link?
Check the config file it's next to the signal nozzle and Cyclops options. It'll then make you enable nozzle park, advanced pause feature and 5 extruders. Plus which ever pins you want to set as the outputs but I used the default ones so far
That's as much as I've done so far, knowing my luck it's more complicated than that and I'll have to modify the mmu 2 fw and potentially add more to marlin. I heard people talking about hal files and such which I don't know what they are
@0lympu5 It for sure is more complicated than just enabling 5 extruders. The serial communication between MMU2 and the printer has to be implemented in Marlin. I'm working on that and if you are interested check my repository which also has a description of how to wire the MMU2 to a RAMPS board.
Unfortunately I'm very busy at work these days so at the moment the project is stalled on my side. The code as is should work but is not tested yet. Therefore I would not recommend using it but if you want to be the first alpha tester please let me know.
@revilor the repository link don't work. I have a MMU2 board, I would like test the MMU2 with your Marlin.
Looks like I lost a 2 in copying the URL, the repository link is fixed now.
The configuration options for MMU2 are located at the and of Configuration_adv.h
obviously im just spit balling here as i ordered my mmu2 late so wont be shipped for a while. What is it like editing firmware for prusa printers, just an idea if i bought the Einsy board that is used on the mk3 and just change relevant settings like bed size, etc
Olympu5, sorry but I have the feeling that you are mixing things up here. MMU2 support is not built into marlin at this time. What is built in is "MK2 Single Nozzle Multi-Material Multiplexer" which is the old MMU for the MK2 printer version. Based on your recommendation I bought the MMU2.0 and am now standing here without marlin support. Next time when you make claims, please make sure they are true. But I should also have checked myself.
Ok, so what is left is revilor´s (UNTESTED!) code which is based on an old (3months) marlin 2.0 which I also can´t use since at this time there were problems with my LPC1768 board. So, now I will try to move the changes to a current marlin.
Sorry for an inconvenience but i was asking a question and not stating any working prototype. I already have the hardware to potentially run a mmu, with a ramps board and cnc expansion board just the adapter is plagued with issues of switching filaments.
@revilor Obviously the most complicated part is getting the two boards to talk to one another, I have a cnc expansion board giving me 6 extruder outputs so far. Is it possible to use this instead of the multiplexer, im presuming id need to add endstops for homing and connect the finda probe straight to the main board if a tool selector code was available.
If not im struggling with the wiring of the ramps as i have a full graphics display taking up pins 16 an 17, i only have 3 endstops so there is space there if it useful also aux 2 is empty
@yellobello I just merged the latest 2.0 branch into my MMU2 branch. So it's no longer based on a 3 months old Marlin 2.0 - but still untested.
@yellobello I just merged the latest 2.0 branch into my MMU2 branch. So it's no longer based on a 3 months old Marlin 2.0 - but still untested.
Ohnnnooooo! I just did the exact same thing last night... we should have told each other so one of us would have had less work ;-(
But, while doing this it came to my attention that the LPC1768 code uses different designations for the serial ports.. for the AVR version its "internalSerial", for LPC1768 it is "SERIAL_PORT_X" where X is one of 4 serial ports to choose from. OK, this can be easily fixed. Going further, the LPC1768 serial port code is much much simpler than the AVR code, where loads of functions like SERIAL_ERRORPGM() are not implemented... I currently I loads of compile errors with this. Let´s see where it will take me .. probably not too far since my C++ is a bit rusty
@revilor when will you be able to test it. I would love to help you out and test it but my unit wont be shipped till march
@revilor would you mind to make a pull request to have it merged into the marlin bugfix-2.0.x branch? So, maybe Roxy3d or someone else with experience with the HAL could take it on and actually make it work, because I tried and got stuck.
As far as i tested yet, the implementation of @revilor should work. Initializing and position change of the selector worked like charm. Because of a mechanical issue with my MMU clone i couldnt print yet.
@Lyr3x what setup did you use?
@yellobello I changed all my uses of SERIAL_ERRORPGM() to SERIAL_ECHOPGM() or SERIAL_ECHOLNPGM(). And I just made another change so now my branch at least compiles for LPC1768.
Regarding a pull request: I have no plans to create a PR until at least one successful multi-material print was made using a MMU2 and a printer running Marlin. And there is still some stuff missing in the implementation like a menu to manually load one of the five materials on the MMU2 for a single-color print.
For LPC1768 you will have to change
in Configuration_adv.h to
// #define ENABLE_INTERNAL_SERIAL 2
And the hardware reset pin of course.
@0lympu5 I am using a MMU 2.0 board clone with an MKS Gen 1.4 but switching this weekend to an Einsy board and hopefully i can finally make a test print
@Lyr3x I'd love to bear about it, I'm running ramps atm did look at einsy but no customisation really, do like tmc 2130 tho
@0lympu5 I am just switching to the einsy because i build another printer and needed another board. So i dont need to build an adapter for the display 👍
@Lyr3x yeah I will need help down the line finding a replacement for pins 16 and 17 on my ramps board as I have a full graphics display
Saw a post on Facebook about a firmware update for the mmu 2
Can the einsy board be connected to a full graphic lcd?
@revilor Thank you for the changes to your firmware! I really really appreciate it ! I let you know when I have it printing... need to build my MMU2 first, though ;-)
@revilor is my hero right now, cant wait for mine to turn up
A little bit offtopic, but I thought maybe you guys know.
It´s about the extruder needed for the MMU2, I figured that no extruder besides the prusa extruder will work with the multi material upgrade. First I thought extruder type would not really matter and I could use it with my bowden extruder, then It came to my attention that the MMU2 would not account for the huge amount of filament that sits in the bowden tube between extruder and hotend and therefore can´t be used. And even if it would, the prime tower would get enormous pretty fast. And then finally I also figured that any extruder that needs manual handling to insert the filament would also not work. I think that about every direct drive extruder that there is, uses some kind of lever mechanism to manually expand the spring that pushes the idler bracket to the drive gear. OK, even the prusa MK3 type extruder has this spring loaded idler bracket, but it does not rely on someone pushing a lever that will open up the space to insert a filament into the drive mechanism. The simple fact that filament is pressed into the extruder drive wheel by the MMU seems to suffice to load the filament, and finally opening up the idler when the extruder is pulling the filament in towards itself. I can´t imagine any extruder which is currently being used that does not require someone pushing the idler when loading some filament. Do you?
And a question that is kind of related: Why does the MMU2 itself not serve as the extruder? It can be some kind of bowden extruder and actually has everything needed to perform this task. Or am I wrong?
regards!
You may be able to tune the bowden tube length to account for the total length
I'm making a custom mk3 extruder but you could use a bondtech one, same principle as the mk3
I don't think that is correct. My printers are using a Titan and a bondtech extruder setup. Both are capable to load the Filament without pushing the lever to release the spring. The bondtech is working even better because of the two side grip. I tested the Filament load with my mmu and when it pushed the Filament correctly the extruder was not the problem.
The only mechanical issue I have at the moment is the idler body which sometimes is not in the correct position
The MMU2 only cares about the distance between the extruder and itself (which is configured in the MMU). The distance from the extruder to the hotend is handled in your gcode. So the sequence for a tool change goes like this:
Steps 2 to 4 are handled by the MMU when a T* gcode is sent. Let's say in your bowden setup you have a distance of 500mm from the extruder gears to the tip of the nozzle. Then the simplified gcode for a tool change to material 4 would look like
G92 E0.0 ; unload 505mm to make sure filament is beyond extruder gears G1 E-505 F1000 T3 G1 E500 F1000 G92 E0.0 ; purge
The real unload gcode is more complex than that because the filament has to be moved up and down some small distances several times with the right speeds to create a filament tip which does not cause a jam when the material is loaded the next time.
That's the reason why I think Prusa went back to direct drive extruder with MMU2 because this way you have better and more direct control over the filament movement. MMU2 with a bowden setup would be kind of another MMU1, which is also why the MMU2 is not working as the printer's extruder.
So back to the question of using an MMU2 in combination with a bowden extruder. I think it is possible and if tuned correctly should be at least as reliable as the MMU1, probably better because at least the problems caused by the Y-splitter are gone this way.
But finding the perfect unload gcode sequence will be some work. This also applies to any other non-Prusa printer even with direct drive extruder, by the way. You will have to find the perfect unload gcode sequence for your extruder/hotend combination. The sequence Prusa uses for the MK3 can be a starting point but you will have to tune it for your very setup. I'm sorry guys, but there is no plug and play in this.
Is there any special code required for the extruder in marlin or is It all done with gcode
Communication with the MMU is handled by the T* commands, so in the end it's all just regular gcode. You can check the examples from the MMU2 drivers package or slice a multi-material object in Slic3r Prusa Edition to see how the gcode for MMU2 prints looks like.
Even though I had some misconceptions in my thoughts above, It will be clear to anyone that using a bowden extruder with the mmu2 would be quite wasteful since one would need to get rid of a lot of filament in the prime tower. Or can you change the filament already to another color but still continue to print with the color in the bowden tube at the actual object until it is let´s say 90% empty and then go for the prime object/tower/infill ? This would need some further optimization of the gcode though.
Either way, I was afraid that only the MK3 B7 extruder would grab the filament without manual intervention so I am going to build the MK3 extruder together with my MMU2 and have the problems of matching the right combination of factors out of the way. I wanted a direct extruder back anyways, so this is my chance now. I already designed a holder plate for the CR10, if anyone is interested.
I'm doing the same, full mk3 extruder, want to try out the laser filament sensor too. The only difference with mine is I'm running volcano but already got a modified fan blower from thingiverse.
I think the best option for purging is into another object, as about half of my printed parts are either functional or painted I get lists of 'free' models. Closely followed by wiping into infill.
Even though I had some misconceptions in my thoughts above, It will be clear to anyone that using a bowden extruder with the mmu2 would be quite wasteful since one would need to get rid of a lot of filament in the prime tower.
Sorry to interfere here, but you still have some misconceptions: the prime tower is only necessary for the molten filament inside the hotend; the wipe amount is not influenced whether it's a bowden or direct extruder.
Only difference is that you move more filament back and forth during the swaps, but you waste not more.
From my understanding your only waste filament would be what ever is left between the extruder and the hot end, however I'm not sure how the mmu would handle this and depending on if or where you used a filament run out sensor, the unit could theoretically push more filament down but you would loose retraction capabilities for a little bit
What you need to run the MMU2 with any extruder:
Even though I had some misconceptions in my thoughts above, It will be clear to anyone that using a bowden extruder with the mmu2 would be quite wasteful since one would need to get rid of a lot of filament in the prime tower.
Sorry to interfere here, but you still have some misconceptions: the prime tower is only necessary for the molten filament inside the hotend; the wipe amount is not influenced whether it's a bowden or direct extruder.
Only difference is that you move more filament back and forth during the swaps, but you waste not more.
Now I got it.. off course, the whole filament is being pulled back. I had the knife blade in mind and thought the whole filament would be cut off and left in the tube or something like that. It´s just the tip that is being cut off when the whole filament is pulled back. Thank you!
Is the tip always being cut off by the MMU? If so, why then the above mentioned procedure to shape the tip when pulling it out of the hotend. I have a feeling that I am still somewhat wrong :-) I don´t have the device yet and I have never seen one in action ...
No, the tip is not always cut.
I think it's currently never cut. At least for me, the MMU2 unit mostly panics (i.e. print pauses and asks for user help to remove the jam/clog) whenever something is wrong. Yesterday one of the colors did not feed properly and caused a print failure. But that was on the 1.0.2 MMU firmware, today I updated to 1.0.3....
Currently it's very stupid and lacks some of the advertised features (like: detecting that the extruder is not feeding properly, retracting and cutting to remove the clogged tip...)
Any news? I am still waiting for my parts to arrive... they are now starting to come in.. almost part by part! I just read a thread in the german reprap forum by someone who already built his own MMU2. He made some very important points, mainly that the 8mm steel ball is actually 7,98mm and so a 8mm ball will get stuck, that only 6,2mm pulleys do work, that one should use FESTO pushfits right from the beginning, that one should print some revised STL files that he posted and when printing the MMU2 one should use 30-50% infill (Honeycomb 3D), use at least 4-5 perimeters and use no supports.
Just to let you guys know.
Revised parts: -> https://www.thingiverse.com/thing:3237579 -> https://www.thingiverse.com/thing:3232438 -> https://www.thingiverse.com/thing:3237770
Merry Chistmas!
From my experience so far I would say the two most crucial parts in the build are the stepper motors for idlers and pulleys and the springs. I started with 17HS16-2004S (45Ncm) motors from stepperonline but could not get consistent results. Sometimes feeding filament would work, and the next time it would not. So today I replaced them with 17HS19-2004S1 (59Ncm) ones and now everything works perfect with 12V supply voltage and using the 12V/MK2 mode of the latest MMU2 firmware (1.0.3).
Regarding the springs I can't give you more than the dimensions of the ones I'm using: 5.5x17mm. It was a lot of try and error with different kinds of springs until I ended up with the ones at use now. It's like for a regular extruder but a little bit more difficult because of the idler drum mechanics: if the force of the springs is too high the stepper won't be able to bring the idler bearing into position, if it's too small the pulley will loose steps and you don't get consistent results.
So the current status on my side is as follows: I have a working MMU2 clone and have Marlin consistently feed filament to/retract filament from the extruder on tool changes. Next I will have to calibrate the MMU for the length of the PFTE tube, and then finally run a test print.
Sounds like you are almost finished, i had a couple of vouchers so bought a genuine mmu2, cant wait to get it working, have you tested with 24v?
At the moment im running ramps 1.4 with tmc2208 so was looking at a possible upgrade, my main concern is as my set up stands the two systems would be running off of different supply voltages, im already using two psu as i have a large print bed but dont want any voltage jumping between boards as it were.
I did not test it in detail with 24V, but considering the MMU2 runs with 24V on the MK3 I guess you will have no problem doing the same. Just take care you power the MMU steppers and the printer board from the same PSU. It won't work otherwise as there is no separate GND for the 5V circuit (which is powered from the printer board).
Ah okay so I'd need to run everything off one power supply or connect the grounds in some way
@0lympu5 not sure but with "switching" power units you can't connect gnd in common
Ah okay, currently I have a separate 24v psu for my heated bed and 12v for everything else, I believe they are switching power supply
Ok guys, looks like we are getting somewhere :-)
I used the sample lizzard gcode from Prusa's MMU2 examples with the change of just one gcode to enable ABL. I had a jam and that's where the print ended because after fixing that reheating the nozzle triggered a thermal runaway. So there is still some work to do.
I will try to add support for the Prusa MMU 2.0 to Marlin as soon as I have a unit at hand. So just to avoid reinventing the wheel: is anybody already working on MMU 2.0 integration?