We need to talk about the engineering (MMU2)  

Re: We need to talk about the engineering (MMU2)

People who are not engineers are talking about engineering. That is starting to be a political discussion now. 😕

Reminds me a bit of the 602 issue.

Re: We need to talk about the engineering (MMU2)

I see your point, and do understand the humor of it.

But you can't honestly sit there and say that this product is ready for release. Not by any stretch of anyone's imagination.

Re: We need to talk about the engineering (MMU2)

People who are not engineers are talking about engineering. That is starting to be a political discussion now. 😕

Reminds me a bit of the 602 issue.

.

Seems the OP is highlighting issues not engineering per say. Not sure what your point is @flaviu. Read the entire post perhaps?

@jonathan.l2
There are many of us whom have issues getting the MMU2 to work reliably or work at all at this point in its development. I tend to agree with the points you bring up on testing. Still a bit confused as to what is being done about the issues. It shouldn't just be left to the customer granted in 3d printing there is a learning curve with any new machine. There is good info here on the forum but its diluted by the prusa fans whom don't offer much help but are swift to criticize without any assistance. Ill go ahead and call my self hypocritical cause i'm doing just that in this very post. I got nothing helpful to offer so my apologies.

Re: We need to talk about the engineering (MMU2)

Sometimes, there is a melted string of filament that causes heartache to the filament sensor/ball system. Other times, it's that the tip of the filament has created a little too much of a glob (just as the same problem with the MMU 1) and the filament is too hard to push through the PTFE tubes without much friction. There have even been times that the filament has unloaded completely from whichever it needed, but the idler motor keeps spinning endlessly for no reason.

Let's summarize: The filament is either too hot or just have wrong settings in the Slic3r.
Sorry but this is a hard requirement for the whole Prusa MMU system to work. The filament tip need to be in acceptable (not perfect) shape. on the MMU1 system you are screwed if you get jams in the splitter. Now you can always recover, clean up and proceed with a print. A huge step forward.

I hope PR will provide perfect MMU settings for their Prusament filament so more people can succeed. Until then you have to understand and find out how your filament can be used for MMU. You need to test. Ranting about PR will not help in this case.

Re: We need to talk about the engineering (MMU2)

People who are not engineers are talking about engineering. That is starting to be a political discussion now. 😕

I AM and engineer and I agree with the OP on this. MMU2 has not undergone the type of testing it should have before release. Just now, I had it come to life for some reason as I was trying to get some crap out of the feed tube and it crushed my finger between the selector and left wall (drawing blood). *THIS SHOULD NEVER HAPPEN!* They appear to be using the newer drivers that can detect jams, but they aren't using it. When it starts up, it runs the motors to the limits for several seconds to make sure they are homed instead of watching for the jam. They know how to do this since they are doing it on the X and Y axis. Why not on the MMU? I saw a 3rd party has modified to code to handle that. Why hasn't Prusa? I am really starting to regret purchasing this. While I had some initial setup problems with my Palette 2, I am not printing reliably with it, and I have had it less time than the MMU2! I have yet to achieve my first successful print with the MMU2.

EDIT: I have now taken off the MMU2 and not sure if it will ever go back on.

Re: We need to talk about the engineering (MMU2)

.. Just now, I had it come to life for some reason as I was trying to get some crap out of the feed tube and it crushed my finger between the selector and left wall (drawing blood). *THIS SHOULD NEVER HAPPEN!* They appear to be using the newer drivers that can detect jams, but they aren't using it. ...

Is the "Finger"-test now the new quality measurement?
Sorry but there are a lot of things where you could complain about MMU but "crash detection" for the selector is the least thing I would think of.

Re: We need to talk about the engineering (MMU2)

People who are not engineers are talking about engineering. That is starting to be a political discussion now. 😕

I AM and engineer and I agree with the OP on this. MMU2 has not undergone the type of testing it should have before release. Just now, I had it come to life for some reason as I was trying to get some crap out of the feed tube and it crushed my finger between the selector and left wall (drawing blood). *THIS SHOULD NEVER HAPPEN!* They appear to be using the newer drivers that can detect jams, but they aren't using it. When it starts up, it runs the motors to the limits for several seconds to make sure they are homed instead of watching for the jam. They know how to do this since they are doing it on the X and Y axis. Why not on the MMU? I saw a 3rd party has modified to code to handle that. Why hasn't Prusa? I am really starting to regret purchasing this. While I had some initial setup problems with my Palette 2, I am not printing reliably with it, and I have had it less time than the MMU2! I have yet to achieve my first successful print with the MMU2.

EDIT: I have now taken off the MMU2 and not sure if it will ever go back on.

Hang on a sec. I'll just whip up some guards so that engineers can't put their fingers into the moving parts. 😀

I agree that the software should be much smarter though.

Re: We need to talk about the engineering (MMU2)

Sure, maybe venting on this forum absolutely won't warrant any real results - I get it. It's therapeutic to air out some grievances from time to time though.

I am still continuing to troubleshoot the issues I encounter for sure, and haven't given up.

Re: We need to talk about the engineering (MMU2)

Sure, maybe venting on this forum absolutely won't warrant any real results - I get it. It's therapeutic to air out some grievances from time to time though.

I am still continuing to troubleshoot the issues I encounter for sure, and haven't given up.

Feel free to ask specific questions. We have people here who are printing successfully not because of luck but because of proper configuration/adjustments and are willing to help everybody.

Re: We need to talk about the engineering (MMU2)

It's the same old story. Consumer 3d printing is not a turnkey scenario. This especially applies to those companies who are pushing the boundaries.

You can (perhaps) engineer a better solution until the cows come home, but at the end of the day none of us would be here if it wasn't for PR. And before anyone calls me an apologist, I have also criticized PR for certain things as well, where I think they have deserved it.

Re: We need to talk about the engineering (MMU2)

.. Just now, I had it come to life for some reason as I was trying to get some crap out of the feed tube and it crushed my finger between the selector and left wall (drawing blood). *THIS SHOULD NEVER HAPPEN!* They appear to be using the newer drivers that can detect jams, but they aren't using it. ...

Is the "Finger"-test now the new quality measurement?
Sorry but there are a lot of things where you could complain about MMU but "crash detection" for the selector is the least thing I would think of.

I will admit that part of this was my mistake, but it was to point out the lack of "crash detection". While my finger was just one issue, I have had a dozen times when the selector has tried to move while there was filament inside causing a jam that required me to take the unit apart to clear. I know the unit will not move (or at least it wouldn't in the past) if the FINDA probe is triggered because of filament, but it should still be able to detect the resistance when moving because of a filament blockage. And it was from one of these blockages that resulted in the finger crush.

So it is because of this filament issue that "crash detection" should be fairly high on the list of issues to resolve.

Re: We need to talk about the engineering (MMU2)

So it is because of this filament issue that "crash detection" should be fairly high on the list of issues to resolve.

The selector is designed to cut the filament. Any crash detection is pointless there.

Re: We need to talk about the engineering (MMU2)

It's the same old story. Consumer 3d printing is not a turnkey scenario. This especially applies to those companies who are pushing the boundaries.

You can (perhaps) engineer a better solution until the cows come home, but at the end of the day none of us would be here if it wasn't for PR. And before anyone calls me an apologist, I have also criticized PR for certain things as well, where I think they have deserved it.

I agree with your point to an extent. To me, the MMU 2.0 feels like a product that was released to the consumer base to figure out how to get to work. Once again, to me, $300 is a little steep for some steppers, 3d printed parts, hardware, and a board when you're using your customers as beta testers until the kinks get worked out. I would have much rather waited for the product release to get delayed further into oblivion if the product would have been working somewhat after assembly IF the delays were properly communicated. I also have an issue with PR holding onto my money for 6 months and then using another 3 months of my time to debug it, only to never get it to work.

At some point you should be able to get it to work especially when they charge a premium for the product.

Re: We need to talk about the engineering (MMU2)

So it is because of this filament issue that "crash detection" should be fairly high on the list of issues to resolve.

The selector is designed to cut the filament. Any crash detection is pointless there.

It was never meant to cut the filament, but the strings that might be left behind, and only if moving in one direction. And even then, it would leave garbage in the tubes to interfere with proper operation. The whole cutting blade was a bad engineering design from the start.

Re: We need to talk about the engineering (MMU2)

It was never meant to cut the filament, but the strings that might be left behind, and only if moving in one direction. And even then, it would leave garbage in the tubes to interfere with proper operation. The whole cutting blade was a bad engineering design from the start.

ok.... So you agree that there is a system to cut something ... and in your opinion it still need to distinguish between your finger and the rest ...
I think the only thing PR missed is to put a sticker "DANGER: Don't put your fingers inside!"

BTW: To put a blade in one cut direction make sense. The only non-cut position is 1 and it's independent of the blade.
And no, I'm not saying the blade system is working or useful at the moment.

Re: We need to talk about the engineering (MMU2)

It was never meant to cut the filament, but the strings that might be left behind, and only if moving in one direction. And even then, it would leave garbage in the tubes to interfere with proper operation. The whole cutting blade was a bad engineering design from the start.

ok.... So you agree that there is a system to cut something ... and in your opinion it still need to distinguish between your finger and the rest ...
I think the only thing PR missed is to put a sticker "DANGER: Don't put your fingers inside!"

BTW: To put a blade in one cut direction make sense. The only non-cut position is 1 and it's independent of the blade.
And no, I'm not saying the blade system is working or useful at the moment.

First off, I never disagreed there was a system to cut something. I even say so in my reply. However, it takes less effort to cut a string than it does 1.75mm of filament. A difference that can be detected. And stop hyper focusing on the finger accident. You need to pay more attention to the part of my comment before saying that because there was no crash detection, the MMU tried to move the selector while there was still filament in the way. If it would have detected that, the finger accident would not have happened.

The blade system was a faulty engineering design from the start, as I said. Anything that gets cut gets left in the filament path and will cause blockages. The cutting system should never have been on the unit to begin with. From what I am seeing in your argument is that because there was a cutting system, they couldn't do a crash detection. My argument is that even with the cutting system, a crash detection is possible and practical.

Re: We need to talk about the engineering (MMU2)

I have to agree the MMU2 is a disappointment when you compare it to the more or less perfect reliability of the MK3 printer itself.

It brings back memories of when I first got my old Ultimaker in 2012 and most prints would fail with filament grinding and clogged extruders 🙂

I think it should largely be solvable with improvements to the software and minor tweaks to the hardware though.

Highest up on my wishlist would be lots of rotary encoders, one for each filament, one in the selector and one in the extruder. That would enable the MMU to be much smarter about figuring out both the status and the position of each filament, detecting runouts, clogs and so on depending on which set of encoders are still turning and automatically tuning parameters like tube lengths.

Second would be tighter integration between the MMU and printer firmware. Right now the only thing the printer tells the Octoprint host is "Recv: echo:busy: processing" whenever the MMU is busy doing something.
A verbose log of MMU operations would be extremely helpful in sending push notifications when something goes wrong and keeping track of error statistics over time.

Third I think would be endstop switches for the idler and selector so it could recalibrate reliably and tell the difference between homing and a crash. If the movement is blocked by filament while the MMU tries to recalibrate everything will end up in a messed up position and you have to reset it manually.

Fourth would probably be a "pro" setup with cascaded MMUs. In theory it should be possible to daisychain up to 5 additional MMUs off the first one for an insane 25 filament setup 😆

Re: We need to talk about the engineering (MMU2)

Highest up on my wishlist would be lots of rotary encoders, one for each filament, one in the selector and one in the extruder. That would enable the MMU to be much smarter about figuring out both the status and the position of each filament, detecting runouts, clogs and so on depending on which set of encoders are still turning and automatically tuning parameters like tube lengths.

If the firmware would use the filament sensor in the extruder, you wouldn't have to worry about tube lengths. It would know when the filament got to the sensor and it already knows the distance between the sensor and the bondtech gears. No tube length calibration would be needed.