RE: I challenge Prusa to use MMU2S
Agreed which is why we are tackling like we are.
The hardware changes are simple and innocuous so that A) it is easy to (un)install and B) it has no impact on the printer when printing without using it (e.g. single color, normal tower, etc..).
The software is modifying the gcode so if you'd rather print with the tower you simply* don't run the post processor. I say "simply" but right now for ease of tower identification it expects you to set your bed larger than the physical dimensions (e.g. make the Y length 310mm) and move the tower outside the physical bed range. As such you would simply generate your gcode normally rather than play that bed/tower trick. The final version will not require that trick unless you are printing something you don't have room for the tower (e.g. trying to use most of your plate).
As far as what it changes, once you identify the tower (most of it is in nice comments, but they stick some bits before and after the comments 🙄) it is easy to programatically pick out the unload (tip forming) process and drop everything up to that point and add the move to the bucket. After doing the tool change, we can scrap everything until it moves back to a real object and replace it with code to perform the purge which we can get the values for from the setting information that PS produces.
With the exception of the bed size trick and executing the post processor your workflow and settings in PS would remain the same.
At least that is the theory. Once we get it more along we'll need help from people willing to verify so we can determine the impact of things like extra cooling moves, different purge settings (volume, speeds, etc..), what happens in the "Real Multi Material" post script is run first, different materials, etc... The goal is that the code should be able to identify and handle all that, but I have 20+ years experience processing unformatted data to know that nothing goes to plan 😆
RE: I challenge Prusa to use MMU2S
Post processing has one huge disadvantage. You can't see and verify the results.
If you really want to implement nice bucket solution, then it should be part of PrusaSlicer (or whatever slicer you're going for). I was already worried about this during the real MMU2 script implementation. My worst case scenario was missing the right spots for changes and setting the temperature wrong.
As proof of concept, post processing gcode is legit option. But for production it's too slow and it should be possible to visualize the results. Don't make same mistake like me 🙂
Often linked posts:
Going small with MMU2
Real Multi Material
My prints on Instagram
RE: I challenge Prusa to use MMU2S
I agree that putting it PS would be the ideal, but beyond code issues (both being able to work in C++ and understanding/following some of that code), there are complaints of Prusa not accepting PRs. A post processor is better than something that remains a wish list item forever 😉
Logically it should be easier to do in the PS code since you don't have to deconstruct and guess, but the tower code gave me a headache when I tried following it to better understand what is happening.
RE: I challenge Prusa to use MMU2S
True. I really miss a plugin functionality in PS.
Often linked posts:
Going small with MMU2
Real Multi Material
My prints on Instagram
RE: I challenge Prusa to use MMU2S
Yeah, we'll cross the C++ bridge when we get there and it's working solidly; at that point I'll take a stab at integrating something in a community fork or so. If it turns out well enough it may be viable to do a pull request into a more widely known fork with other good features like SuperMerill's.
RE: I challenge Prusa to use MMU2S
Not sure that discussions about a post-processor should be in this thread; something like that is worth it's own thread.
And, for you more "junior" members/owners:
I wrote a working post-processor for the Mk2+MMU as a replacement for the PR post-processor that was supplied at the time. It worked very well (better than PR post-processor) and included such things as lowering the temps for ramming. It also optimised the waste (per filament purge volume) and the tower (shrinking and with alternate directions) and also auto-positioned the tower. Much of the KISS purge tower was based on my post-processor. I was also asked for input by PR when the tower was being included into Slic3r.
During the development of the KISS purge tower, we tried dumping the waste at the rear of the bed. This was a total fail.
So, my conclusion is simply that the purge tower really is the best way to go, simply because the waste is totally under control. PR purge tower is difficult to set up efficiently, but in the main, it's usable. IMVHO, the KISS purge tower is so much more advanced.
Peter
Please note: I do not have any affiliation with Prusa Research. Any advices given are offered in good faith. It is your responsibility to ensure that by following my advice you do not suffer or cause injury, damage…
RE: I challenge Prusa to use MMU2S
gnat & vintagepc: Is there a blog/git/forum post where you track/document your development (not just code changes)?
RE: I challenge Prusa to use MMU2S
gnat & vintagepc: Is there a blog/git/forum post where you track/document your development (not just code changes)?
Have a look at the various Readmes in the previously linked repo.
RE: I challenge Prusa to use MMU2S
OK, thanks. I haven't delved that deep tbh. Maybe you could implement a small ring spanner instead of a printed bucket?
Widely available standard part, stiff, metal...
RE: I challenge Prusa to use MMU2S
OK, thanks. I haven't delved that deep tbh. Maybe you could implement a small ring spanner instead of a printed bucket?
Widely available standard part, stiff, metal...
I'm not sure what problem the design has that would solve, I only see it creating them in terms of weight, nonuniformity from different brands depending where you are in the world, etc.
RE: I challenge Prusa to use MMU2S
No worries - it was just an idea I had reading your git, had one on the bench right in front of me. I was wondering if the printed arm would start to sag over time.
You're definitely on to something right there, we might all profit from it in the long run. So thanks for looking into this.
RE: I challenge Prusa to use MMU2S
My big concern is if the filament does not fall off the extruder, but stays connected instead. A long strang would be drug over the print bed, where the heat would make it stick.
Can this discussion get it's own thread? It is too big a thing to be lost in a rant thread.
RE: I challenge Prusa to use MMU2S
Oh to be fair it didn't start as a rant thread. It was a challenge to Prusa, which I'd still like to see answered 😉
I personally believe their claims, but don't believe they used units exactly as they were later sold.
RE: I challenge Prusa to use MMU2S
Oh to be fair it didn't start as a rant thread. It was a challenge to Prusa, which I'd still like to see answered 😉
I personally believe their claims, but don't believe they used units exactly as they were later sold.
I'm in agreement with you there. Prusa's greatness was arguably achieved, by using the product they produced in their actual production line. If they aren't actively using the MMU2S in some form in the production line on the regular, it is a departure from their own norm, in my opinion.
They might benefit from tracking defects per opportunity closer - better sample size in production, like Six Sigma, in a way, but..... maybe Two Sigma would be more appropriate for now... In their current state, the data they receive is from: people who are pissed, people who are giddy/happy, people who are fanboys who actually do not own the product. They never get the middle/in-between average user in cases of surveys return.
Part of the occurrence of defects is just from design constraint - 3D printed parts to stay open source and reduce cost. 3D printed parts gives technical disadvantages, but also advantage of fast iteration. I think they made the right choice on using 3D printed parts where they can, along with ALU extrusions. (But can a 3D printed part be considered a defect? I think no, although a big hassle - because it depends on how printed, so it has to be cast as 'all other things equal')
RE: I challenge Prusa to use MMU2S
My big concern is if the filament does not fall off the extruder, but stays connected instead. A long strang would be drug over the print bed, where the heat would make it stick.
Can this discussion get it's own thread? It is too big a thing to be lost in a rant thread.
Done.
RE: I challenge Prusa to use MMU2S
I think the main mistakes were in marketing and the way it was rolled out. Had they advertised this as experimental and not offered printed parts, then a lot of now disappointed users wouldn't have bought it in the first place. A simple test print to establish good tolerances first, then let the consumer print with defined filament and better quality settings. Could have used data from remaining users for an evolution to MMU3. I definitely fell for the "it's really seriously working now dude" claim, even though at this point I had almost zero remaining trust. To be fair I'm quite happy now, but only after a lot of wasted time. And I can't even claim with confidence I could help out a buddy if they had issues with theirs.
When I got the 2nd poll for MMU2 users I was seriously disappointed, you couldn't even check that your unit is not working/not working properly (iirc). Most important question, isn't it?
RE: I challenge Prusa to use MMU2S
Well that there's a good point. MMU2 working vs Extruder in the MK3S actually engaging/taking the filament properly. It's like it has to orchestrate.
Now, hindsight is 2020, but I really feel like the orchestration should be on a single board, but that's just me. 😉 They sure are doing a lot of things on that 8 bit micro...
RE: I challenge Prusa to use MMU2S
Hi guys,
...snip...
MMU2S was intensively tested and design was changed many times in order to improve the reliability. Final testing took about 2 months with a room full of MMU2S printing 24/7. Some printers required assistance from time to time, but the majority of the prints finished. You can see all the benchmark prints (around 480) in Joe's article: https://blog.prusaprinters.org/original-prusa-i3-mk3s-and-mmu2s-release-sl1-and-powder-coated-sheets-update/
Reposting this for those who missed it, since it was posted many pages ago.
I am out of this thread at this point, challenge was accepted and completed prior to the challenge even being made. 🙂
RE: I challenge Prusa to use MMU2S
FWIW I bought my MMU recently and got it about two weeks ago. Assembly went well and after some initial frustrations, followed by filament fine tuning I got a successful 2-colour print the other day of the 3h sheep (~150 tool changes). Needed attention 2 times but that is because I either need to dial in that particular brand of filament better, or there are still some friction issues with it - the fails had stringy tips. It's been noted before that AmazonBasics PLA has a rough texture and is somewhat finicky to get to travel smoothly in the buffer and this was the source of most of my issues, and my experience reflects this.
My impressions so far are that it's sound but the build requires attention to detail or you will have issues. I'm gearing up to try a larger three colour print this weekend. I'm running a skelestruder, no less, which brings its own complications to the mix. The common mantras of getting your sensor to work reliably and minimizing friction in the entire system are key. (And don't derp like I did and use Shenzen special PTFE for your hot end, and then realize why your filament tips are too fat - seriously, use the Prusa PTFE there.)
I also did browse the available user mods and there are a few Quality of Life ones I've picked up - rewind spool holders to save space and make loading less painful, and of course the ubiquitous PTFE quick connect coupler mods.
Note - this is a sample size of 1 and I'm not refuting folks may have bad had experiences. Just sharing my own for an additional data point.
TL;DR: I'm happy so far; but do see room for improvement over stock.
RE: I challenge Prusa to use MMU2S
My experience has been that the MMU2 was more successful for me. However, once I get the PINDA replaced, I bet MMU2S will be more reliable, since it was received from repair. I know I have to work on the Extruder again though, which will probably anger it.
As for the challenge, if they aren't using the MMU2S in their production line, let's say for the LCD panel, I consider the challenge not accepted/not attempted. Prusa's 'legendary' QC came from using the printer on the production line. Why they would depart from that, is likely due to the challenges the MMU presents. Proof is in the pudding.