Improvements to the MMU 2.0 controller firmware  

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/cskozlowsk/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.

Here are some of my results:

impressive results....
link to your github not working for me

Re: Improvements to the MMU 2.0 controller firmware

Missing an 'i' in my link (corrected in my original post) . Try this: https://github.com/cskozlowski/mmu2

Re: Improvements to the MMU 2.0 controller firmware

My sensor is a simple microswitch with a 7mm ball bearing.

I've seen someone use a ball bearing as an interstitial with the existing sensor. It likely wouldn't be AS accurate, but I think at least trying to use the optical sensor since it's there makes sense.

For that matter, if we're NOT using it, could we re-purpose the wires to run a useful sensor like yours?

Re: Improvements to the MMU 2.0 controller firmware

My sensor is a simple microswitch with a 7mm ball bearing.

I've seen someone use a ball bearing as an interstitial with the existing sensor. It likely wouldn't be AS accurate, but I think at least trying to use the optical sensor since it's there makes sense.

For that matter, if we're NOT using it, could we re-purpose the wires to run a useful sensor like yours?

I was tempted to use the laser sensor for my project but decided to go with a microswitch and ball bearing because it is so reliable and doesn't care about filament color or translucence . I run those microswitch sensor wires (3 of them) back up the bowden tube (outside of the tube) to my MMU2 controller. The control loop needs to be tightly coupled with the MMU2 so that was once again - the easiest approach for me to use at this point in time. I am familiar with the ball bearing/laser sensor design - it appears to be a solid approach since it takes filament color and characteristics out of the equation. Regarding accuracy, I am able to track filament load distances between the MMU2 down to the MK3 and the min/max distances travelled by each filament can vary up to 10mm. I print out stats during a run on my local computer (using the serial interface with my MMU2 arduino). These variances are attributable to hobbed gear variations as well as filament diameter variations between filament types. I am amazed at the max delta (10mm) and this will result in filament load issues (seen as 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);


I haven't had a chance to try the MMU since the 1.01 release but I have noticed that my mmu has been failing its bootup sequence frequently since the firmware update. But I have just been bypassing the unit and printing directly with single colors right now.

Re: Improvements to the MMU 2.0 controller firmware

My sensor is a simple microswitch with a 7mm ball bearing.

I've seen someone use a ball bearing as an interstitial with the existing sensor. It likely wouldn't be AS accurate, but I think at least trying to use the optical sensor since it's there makes sense.

For that matter, if we're NOT using it, could we re-purpose the wires to run a useful sensor like yours?

I was tempted to use the laser sensor for my project but decided to go with a microswitch and ball bearing because it is so reliable and doesn't care about filament color or translucence . I run those microswitch sensor wires (3 of them) back up the bowden tube (outside of the tube) to my MMU2 controller. The control loop needs to be tightly coupled with the MMU2 so that was once again - the easiest approach for me to use at this point in time. I am familiar with the ball bearing/laser sensor design - it appears to be a solid approach since it takes filament color and characteristics out of the equation. Regarding accuracy, I am able to track filament load distances between the MMU2 down to the MK3 and the min/max distances travelled by each filament can vary up to 10mm. I print out stats during a run on my local computer (using the serial interface with my MMU2 arduino). These variances are attributable to hobbed gear variations as well as filament diameter variations between filament types. I am amazed at the max delta (10mm) and this will result in filament load issues (seen as skipped layers).

I have been following your work on the Facebook Prusa Community group, so impressive! It inspired me to try and do the ball bearing mod for my optical sensor but I can't seem to get it to work consistently. It would also require firmware modding to get it to work with the MMU which I am not capable of doing.

Re: Improvements to the MMU 2.0 controller firmware

The difference in feed lengths also leads to grinding of the filament in the MMU unit, and subsequent failures due to the notch and powered filament.

More people should post about the 1.0.1 failures on boot up. I've posted 3 videos and several threads and the response seems to be "how come we don't see it"...

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.

Very, very impressive work!

Here I just want to sum up all your coding, I would prefer over the code provided by Prusa:
* Common definitions for Stepper Resolution
* Definition of steps/revolution
* use of absolute coordinates
* definitions for the used pins (instead of flooding the code with repeated constants)
* using a function for testing finda
* interactive command interface on the USB connection
* use of a stesps per milli meter definition for the pulleys
* rehoming selector after 20 tool changes
* proper comments all the way!
* delay compensation for code execution in a stepper loop to get accurate speed
* overall simple code and rather good structure, even though it is all squeezed into a single .ino file

I don't want to say, that every piece of code is better than that from Prusa, but we have to take into account, that this code is written by a volunteer hobby programmer!

Do you have anywhere a consolidated documentation of your project? Or a thread, where you describe your project?
Do you think it is worth to implement your changes on a bought MMU 2.0?

How reliable is your unit working now? What are the problems you are still facing?

EDIT: and did you do any custom modifications on the printer firmware?

Hat off and kind regards,
Karl

Re: Improvements to the MMU 2.0 controller firmware

And he shared is work on Facebook and more importantly GitHub.......

Chuck do u mind making your own thread about your mod here on the forums, so we can discuss your changes separately.

Re: Improvements to the MMU 2.0 controller firmware

Great work Chuck, glad you're making the system work like many of us are battling with, I'm slowly going through to see if any improvements can be pulled into my build

Karl.z2, I envy your embedded AVR programming fu, I come from an IT background with more app dev that embedded so this is strange but I am learning.

Last night I bit the bullet and started trying to tune my MMU2 2130 config to drive more like what I'd expect (similar if possible to Karl's vid) and have already had great success with getting the selector tuned to use SG properly for homing reliably.

Working on getting idler homing with SG properly tonight.

code updated on my fork when implemented.

https://github.com/TheZeroBeast/MM-control-01

Rob

Re: Improvements to the MMU 2.0 controller firmware

Here is the results from the last two nights, giving multicolour Phil the astronaut a go now 😀

Re: Improvements to the MMU 2.0 controller firmware

🙂 the frist part of the video looks very familiar

See bugreport https://github.com/prusa3d/MM-control-01/issues/47

Re: Improvements to the MMU 2.0 controller firmware

Hello,

finally I published the code from the video:
https://github.com/KarlZeilhofer/MM-control-01/tree/rework

Please do not relay on it for production. It's just a first glance, in what direction it should go.
If it is compiled without the TESTING define in config.h, it should behave like the original Prusa firmware, currently version 1.0.2.

I forked the source at v1.0.1, and merged today the changes from v1.0.2 into my rework branch. Before that merge, I reformatted Prusa's code with Artistic Style, since my branch was already formatted. Here's the diff of these branches:
https://github.com/KarlZeilhofer/MM-control-01/compare/formated-v1.0.2...KarlZeilhofer:rework?diff=split&expand=1

It's very likely, that the attached issues get fixed very soon 🙂

Greets,
Karl

Re: Improvements to the MMU 2.0 controller firmware

Hello,

finally I published the code from the video:
https://github.com/KarlZeilhofer/MM-control-01/tree/rework

Please do not relay on it for production. It's just a first glance, in what direction it should go.
If it is compiled without the TESTING define in config.h, it should behave like the original Prusa firmware, currently version 1.0.2.

I forked the source at v1.0.1, and merged today the changes from v1.0.2 into my rework branch. Before that merge, I reformatted Prusa's code with Artistic Style, since my branch was already formatted. Here's the diff of these branches:
https://github.com/KarlZeilhofer/MM-control-01/compare/formated-v1.0.2...KarlZeilhofer:rework?diff=split&expand=1

It's very likely, that the attached issues get fixed very soon 🙂

Greets,
Karl

Nice Karl.....thanks for sharing, hope they take a look at what u did.

Re: Improvements to the MMU 2.0 controller firmware

I'm unsure why there is so much resistance to improving the product - I'm VERY glad you're taking the time to get it there.

I've made some nice prints, but on average it takes 25-35 minutes to start a print, resetting and resetting the machine until it happens to come up in a good state. Frankly if your code works half the time it's a factor of 2 or 3 better than the latest "Release" version. 😛

Re: Improvements to the MMU 2.0 controller firmware

So.... Now do I want to mess with Karl's version, or Robert's?

Trying Karl's now.
----------------------------------
So far I only notice one difference - there's no real changes to homing that I can tell, but it's finished the homing procedure 20 for 20 tries. On 1.0.1-126 I was lucky to get 3 reliable homes in 20 tries. That would be notably faster.
Also the version number comes up as 1.0.2-132 on the printer's screen - I don't know if that overlaps with one of the Prusa official builds, if you could add a K to the end I'd like it.
Filament changes, etc, seem to be the same speed, and stalling the selector loses home. Pulling all the way to 5+ doesn't fix it, you need a reset... But at least that reset works!

Suggestions: Put something in the first line of code that shows up that says you made it so we can tell it apart? I added "// Karl" to mine.

Re: Improvements to the MMU 2.0 controller firmware

I think you tried the wrong Git branch, could that be?

It's the rework branch, and there the version is set to 9.9.9-132

So it was not my code which improved your machine 🙂

Re: Improvements to the MMU 2.0 controller firmware

Not sure where to post on GitHUB

Using it so far, it worked for many resets. Now I'm having the occasional issue, resetting not working like before.

Is there some useful testing for me to do?

Re: Improvements to the MMU 2.0 controller firmware

As said before, you are not on the correct branch.

please run following commands in a shell:


git clone https://github.com/KarlZeilhofer/MM-control-01.git
cd MM-control-01
git fetch --all
git pull --all
git checkout rework


Now you will have my code checked out. Proceed either with platformio or arduino IDE.

Greets, Karl

Re: Improvements to the MMU 2.0 controller firmware

My sensor is a simple microswitch with a 7mm ball bearing.

I've seen someone use a ball bearing as an interstitial with the existing sensor. It likely wouldn't be AS accurate, but I think at least trying to use the optical sensor since it's there makes sense.

For that matter, if we're NOT using it, could we re-purpose the wires to run a useful sensor like yours?

I'm currently investigating the issues with the optical filament sensor. I've modified the MMU controller and built a cable to connect the sensor directly to the MMU controller.

Abe, you mentioned, that you saw one, using a bearing? I think, this would be a very good improvement, since the sensor now also detects the smallest strings. With a bearing one could design that mechanics to detect only things with a minimum diameter of e.g. 1.5mm. Do you have a link to that bearing mod?

Another try could be to investigate all the registers and values of the sensor, perhaps one can distinguish a string from a proper filament. But that's signal processing, and not as straight forward than a mechanical bearing.

Greets, Karl

EDIT: Perfect would be measuring the presence of any filament, and of course it's motion. Former is more important, since a motion sensor alone cannot reliably detect stuck filament.