Improvements to the MMU 2.0 controller firmware  

Re: Improvements to the MMU 2.0 controller firmware

That's pretty cool so far as it goes!

I'm curious - what do you mean by 'cool motors'? Running at lower voltage?

Re: Improvements to the MMU 2.0 controller firmware

Awesome work

Re: Improvements to the MMU 2.0 controller firmware

@karl.z2
Most impressive, what you have been able to accomplish in less then a week or two. Stock firmware doesn't even use stallguard at this point.....

Re: Improvements to the MMU 2.0 controller firmware

Oh yeah, that's what it should be.

Do you do stall guard on the drum, too? That is needed probably more, the drum gets lost quite often.

Re: Improvements to the MMU 2.0 controller firmware

Oh yeah, that's what it should be.

Do you do stall guard on the drum, too? That is needed probably more, the drum gets lost quite often.

I just implemented the stall guard also for the idler drum. No "tuck, tuck, tuck, tuck, ..." any more, when the system boots. 🙂

For getting idler and selector back in sync during printing, there would be still some more code rewriting needed. They only do differential moves without absolute positions!

Re: Improvements to the MMU 2.0 controller firmware

That's pretty cool so far as it goes!

I'm curious - what do you mean by 'cool motors'? Running at lower voltage?

reduced current, when they are in idle.

Re: Improvements to the MMU 2.0 controller firmware

That's pretty cool so far as it goes!

I'm curious - what do you mean by 'cool motors'? Running at lower voltage?

reduced current, when they are in idle.

There is a GitHub feature request related to this issue for the stock firmware:
https://github.com/prusa3d/MM-control-01/issues/27

In your firmware Karl, I understand u reduce current to keep the motors cooler during idle periods...... But then how do you ensure once motors need full current again, selector is in correct position? Do you rehome selector?

Re: Improvements to the MMU 2.0 controller firmware

This is of course just a demo, of how it could be, if the firmware would be polished. It's up to Prusa, now.
Prusa, if you are in lack of man power, please let us know.

Have you submitted a pull request for your updates? It would be a shame to see your effort go to waste.

Re: Improvements to the MMU 2.0 controller firmware

..... But then how do you ensure once motors need full current again, selector is in correct position? Do you rehome selector?

That's not needed. The current isn't lowered until the would loose steps. The values are just not tweaked enough by Prusa.

Re: Improvements to the MMU 2.0 controller firmware

Have you submitted a pull request for your updates? It would be a shame to see your effort go to waste.

With the current speed of developments of Prusa's team, a merge in two weeks would still be without any conflicts, I guess 🙂
Their last commit was on Wednesday.

Re: Improvements to the MMU 2.0 controller firmware

This is of course just a demo, of how it could be, if the firmware would be polished. It's up to Prusa, now.
Prusa, if you are in lack of man power, please let us know.

Have you submitted a pull request for your updates? It would be a shame to see your effort go to waste.

Karl is letting us know what better programming of mmu2 firmware is capable of. He's not giving away his talent for free, wants Prusa to hire his team of programmers.

However it's such a tease for us......sadness

Re: Improvements to the MMU 2.0 controller firmware

Karl is letting us know what better programming of mmu2 firmware is capable of. He's not giving away his talent for free, wants Prusa to hire his team of programmers.

If Prusa does the work on their own, I'm also happy. But looking at the provided results of "the best they could do"... I don't believe it.

I also don't want to branch off from the main project, because that means constant efforts into the firmware.

I really don't want to appear arrogant or greedy, because I'm not giving my code away for free. Prusa runs a business, and me too. I only want Prusa to act - in any way. But doing nothing is not a solution at all. Today in the morning I sent them a quotation via eMail.

Now we have to wait. I'm very sorry for that.

Re: Improvements to the MMU 2.0 controller firmware

Before going into this improvements they should prioritise the release of MK2.5-MMU2.0 firmware . Until now we can't use our MMU2.0 on MK2.5. It's very frustrating after waiting months for MMU2.0 we can't even use it on MK2.5 as advertised and only work on MK3.

Re: Improvements to the MMU 2.0 controller firmware

Before going into this improvements they should prioritise the release of MK2.5-MMU2.0 firmware . Until now we can't use our MMU2.0 on MK2.5. It's very frustrating after waiting months for MMU2.0 we can't even use it on MK2.5 as advertised and only work on MK3.

Oh, I didn't know, it's that bad. I thought this is just a cabeling issue!?

Re: Improvements to the MMU 2.0 controller firmware

Hi,

I just want to give you a preview, of what the MMU 2.0 controller is capable of - in principal:

I've hacked some testing code regarding the stepper motors and their motion, based on firmware V1.0.1.

New features:

This is of course just a demo, of how it could be, if the firmware would be polished. It's up to Prusa, now.
Prusa, if you are in lack of man power, please let us know.

Karl from Team14

That`s all interesting. But how exactly is that helping people with the reliability of the mmu2 unit?

The two main issues right know seem to be
A: getting the ramming sequence right and
B: getting the build of the mmu2 unit right so that the filament runs perfectly smooth.

So not really firmware related.

Re: Improvements to the MMU 2.0 controller firmware

That`s all interesting. But how exactly is that helping people with the reliability of the mmu2 unit?

Of course there are still other issues to solve. But our domain is embedded software and electronics. Stall detection can help to restore from a step loss. Or at least report a problem to the printer.

Me and others had a case, where the homing didn't work reliably - I thing because of a very bad motion control algorithm.
The idler drum is crashing constantly against the end stop when homing!
More speed is always good in printing.

Please have a look at the issue list on GitHub: https://github.com/prusa3d/MM-control-01/issues

Re: Improvements to the MMU 2.0 controller firmware

There are definitely more firmware issues/gaps than hardware at the moment with the MMU2. Look around thingiverse and theres very few useful mods for the MMU2. The selector definitely needs a few small amendments but overall the design works as intended. The firmware is just wildly inconsistent. Looking at Karl's github issues, most seem very valid and should not take months to fix especially considering the MMU2 was in beta for several months. It won't fix the filament strings or jams that need filament-specific ramming settings (ugh) but it will ease a lot of pain. In particular I would like to see the extruder filament sensor reactivated with MMU2. This would help so much with skipped layers.

Re: Improvements to the MMU 2.0 controller firmware

This would help so much with skipped layers.

Do you have still issues with the V1.0.1 with skipped layers? For feeding the filament into the gears (the last few millimeters which are driven by the MMU) there is a special procedure, something like this:


// PLA
tmc2130_init_axis_current(AX_PUL, 1, 15); // medium current
move_pulley(150, 384); // 150 steps, with speed 384 steps/s

tmc2130_init_axis_current(AX_PUL, 1, 3); // very little current
move_pulley(450, 454);


Re: Improvements to the MMU 2.0 controller firmware

I started with an arduino mega 2560 and ramps 1.6 board using 8255 stepper motors ( https://github.com/cskozlowski/mmu2 ). I added a 2nd filament sensor at the top of the mk3 extruder so I have ZERO filament load/unload issues and I don't have to calibrate the filament travel distance between the MMU2 and the MK3 because of this 2nd sensor. This 2nd filament sensor guarantees that my filament lands in the middle of the bondtech gear EVERY TIME. My sensor is a simple microswitch with a 7mm ball bearing.

Since I wrote the code I have 100% control over the behavior of the MMU2. During the critical 'filament load', the bondtech gear and the MMU2 extruder gears are active at the same time. I have my code properly tuned so that I match the MK3 extruder (bondtech gear) speed exactly. There is a setting in Slic3r for filament load speed I currently have this set to 30 mm/sec. There is a 2 second run across the purge block to load the new filament and both gears are engaged at the same time. I actually push filament from the MMU2 into the MK3 at that speed for 1.6 seconds - I have no filament load misfeeds. For those following along, I am moving over 45 mm of filament past the bondtech gear and I have ZERO grinding since I have matched the speed of both gears. There is 69.5 mm from the middle of the bondtech gear to the heat break in the extruder.

I am using very crude 8255 stepper motor controllers (open loop) with 45 N-cm stepper motors (pretty close to the same stall torque as Prusa stepper motors).

Here are some of my results: