Improvements to the MMU 2.0 controller firmware  

Re: Improvements to the MMU 2.0 controller firmware

Ok, I'll loosen it up and try again... How would you prefer we communicate feedback to you? here in the forums? I noticed we can not post issues on your fork.

Can you join chat on the discord we have several people there trying your firmware and we would love to help you move forward with this.

https://discord.gg/SydChB6

I hope it's OK to post this link here.

Re: Improvements to the MMU 2.0 controller firmware

Everyone, I'm trying to get a stable MMU-FW on my master branch at present which talks with my MK3 FW, MMU-MK3-FSensorBuild branch.
I will advise once stable so people are able to test.

Great. My mmu2 should arrive on Monday. I‘m ready to test then. 😀

Re: Improvements to the MMU 2.0 controller firmware

Just received my MMU2 and did a semi-successful first test print using stock firmware and setup. I'm ready to help you test if there's anything I can help with.

Re: Improvements to the MMU 2.0 controller firmware

Hey,

if you can post on the branch that would be good.

once I get a good master branch I will ensure only tested mods/changes get merged and git issues will help make improvements.

Discord is good, I will connect that feed up and join you.

I don't get too much time but will do what I can.

My prints are now going good until the idler rehomes to the wrong place 😥 if anyone has amazing trinamic 2130 foo please offer assistance getting an accurate home with stallguard2. It seams temperature is playing too much of a roll, when idle the warm motor homes fine even with over tightened tension bolts and then once a couple hours in when the idler motor is 15-20C hotter it gets confused, thinking the bearings are the end stop.

I feel it does need an rehome/reset every 20 tool changes as I did have issues with the factory FW where the idler or selector got out of sync.

Re: Improvements to the MMU 2.0 controller firmware

It doesn't look to me like you have issues open on the branch, that's the only place I would think we could post there. Maybe check your repo settings?

Re: Improvements to the MMU 2.0 controller firmware

Hey,

if you can post on the branch that would be good.

once I get a good master branch I will ensure only tested mods/changes get merged and git issues will help make improvements.

Discord is good, I will connect that feed up and join you.

I don't get too much time but will do what I can.

My prints are now going good until the idler rehomes to the wrong place 😥 if anyone has amazing trinamic 2130 foo please offer assistance getting an accurate home with stallguard2. It seams temperature is playing too much of a roll, when idle the warm motor homes fine even with over tightened tension bolts and then once a couple hours in when the idler motor is 15-20C hotter it gets confused, thinking the bearings are the end stop.

I feel it does need an rehome/reset every 20 tool changes as I did have issues with the factory FW where the idler or selector got out of sync.

Discord is USELESS for keeping track of issues, at least, I've never seen it done well. It is awesome if everyone is on it 24/7 with nothing but the one topic on their mind, but it's a chat, not a topic-sorted forum. I would not recommend using it - GitHUB is better, inherently on topic. Just my feeling on it.

I have NOT seen the drum actually get out of sync except when my screws are loose, and when they are, they need tightening. Homing every X number of moves isn't really a solution though it does help.

Two issues:
One:
The old version I was running, when there was a misfeed, kept trying to cut and fed and cut and feed and I had dinner to come back and find some 10+ meters of filament squirted out on the floor. It had missed the selector and just kept feeding.

IT IS IMPERATIVE that the machine fail "safe". After some FINITE number of attempts, there is no reason to keep trying, you can only cause trouble or do no further improvement.

Two:
I installed the latest version (2.0.2-158), and had issues. The print will not load the filament when the print begins. During the prime line, the MMU feeds (much, much slower than before, the same for retracts, much slower), and gets into the extruder gears, but won't start printing until several CM of filament is "used up" in the "print". It seems the printer isn't waiting for its response from the MMU to load and just carrying on immediately after getting the command.

I'm very much interested in the most "stable" version I can use - I want to help test but also have to have prints that work. What's your advice?

Re: Improvements to the MMU 2.0 controller firmware

OOOoooo, I just learn't something, I didn't even know you could enable/disable issues on a git 🤦‍♂️ it now is 👍 thanks Joshua.j9

Discord is USELESS for keeping track of issues, at least, I've never seen it done well. It is awesome if everyone is on it 24/7 with nothing but the one topic on their mind, but it's a chat, not a topic-sorted forum. I would not recommend using it - GitHUB is better, inherently on topic. Just my feeling on it.
Yeah, I agree Discord isn't good for tracking and issues on the git would be the place for it.

I have NOT seen the drum actually get out of sync except when my screws are loose, and when they are, they need tightening. Homing every X number of moves isn't really a solution though it does help.
Good to know, it may be a logic issue in code and in fact I found a couple of incorrect calculations just before and now it is 🤞 30 changes into a print without any issue.

The old version I was running, when there was a misfeed, kept trying to cut and fed and cut and feed and I had dinner to come back and find some 10+ meters of filament squirted out on the floor. It had missed the selector and just kept feeding.

IT IS IMPERATIVE that the machine fail "safe". After some FINITE number of attempts, there is no reason to keep trying, you can only cause trouble or do no further improvement.
Sorry to hear that, I'm just an average user like the rest trying to getting a reliable product when it should have already been when delivered.
I have implemented timers now on loads/unloads and they stop and flash the colour channel in question when an error or timeout is encountered.

I installed the latest version (2.0.2-158), and had issues. The print will not load the filament when the print begins. During the prime line, the MMU feeds (much, much slower than before, the same for retracts, much slower), and gets into the extruder gears, but won't start printing until several CM of filament is "used up" in the "print". It seems the printer isn't waiting for its response from the MMU to load and just carrying on immediately after getting the command.
I was just speaking with AbeFM on an old pull request and this is because the MK3 FSensor is for some reason off despite my attempts to have it enabled always when a MMU2 unit is attached. My MK3 must remember that it's on so if someone could please let me know if they can even enable via MK3 settings menu please. This should allow the filament to be fed into the extruder properly.

Re: Improvements to the MMU 2.0 controller firmware

Hey Robert,

I've been lurking on your thread for a while. I was wondering why you couldn't bring issues on github, glad u fixed that. I havent tried to install your firmware yet. I love reading the CHANGELOG.md on your github.......gives me hope.

Do you think its ready for the masses or only beta testers? or should the masses wait for you to implement error handling?

Is this branch for stock mk3/mmu2 hardware, no mods? (is cutting enabled? I took knife out)

So one must also install your version of MK3 firmware to work correctly with your mmu2 firmware?

Re: Improvements to the MMU 2.0 controller firmware

sorry guys for my absence, I didn't notice all the traffic here.

@milindur
great you are referencing by commit hashes.

Sorry, that essentially my code lead to that bad misbehaviour on your machine. As I stated, my code was just a preview, and not meant to be used for production. On major reason for that is, that I have not an army of MMU2 to be tested - it is only one unit, and I don't know the variances between different machines.

It's very likely, that your spindle has a slightly higher friction. I also used some oil on my spindle, as it had difficulties with the stock firmware on homing.

@joshua.j9
I also once saw that idler homing loop on my machine.

@khalil.n
Just wanna clarify that the CHANGELOG.md is all from my fork, which has been merged into robert.m28's fork.

@robert.m28, perhaps you can keep the CHANGELOG.md updated, so we can easily track your changes and the state of the firmware.
what do you plan with both of your forks? do you think, Prusa will merge them, when you start a pull request?
A hard fork would perhaps be a dead end, if it is not supported by Prusa.
Further more, I recommend you to use GitKraken as a Git GUI client. There you can easily change the most recent commit message or squash multiple commits into one commit. Branching and merging is also very easy there.
Also you can add there other remotes very easily, which would help to keep track of merges.
Attached is a screenshot of this project. You can keep track of everyone's commits very easily. I've reformatted your code and published it on https://github.com/KarlZeilhofer/MM-control-01/tree/master-zero

You should do this before any commit, so the diffs will stay consistent. Artistic Style ( https://sourceforge.net/projects/astyle/ ) is FOSS which also runs on Windows - if that's your development environment. Perhaps you can provide a windows batch file, base on the format.sh, which is for Linux's bash.

For your info:
I'm in contact with Prusa, but sadly still without any results for the community.

Re: Improvements to the MMU 2.0 controller firmware

Hey Robert,

I've been lurking on your thread for a while. I was wondering why you couldn't bring issues on github, glad u fixed that. I havent tried to install your firmware yet. I love reading the CHANGELOG.md on your github.......gives me hope.

Do you think its ready for the masses or only beta testers? or should the masses wait for you to implement error handling?

Is this branch for stock mk3/mmu2 hardware, no mods? (is cutting enabled? I took knife out)

So one must also install your version of MK3 firmware to work correctly with your mmu2 firmware?

Hi Khalil.n,

As of this morning I think it is ready for some wider supervised testing by who ever feels up to it. I just resolved a nested loop issue from last nights build which has just given me my first untouched successful print with the MK3 & MMU2 FWs.

Note: MK3 filament sensor needs to be enabled or MMU2 will never load filament into extruder properly.
Also, if the fprint library isn't enabled for your compiler as per PRUSA instructions on their README.md then you will see a "?" for Z height. Cosmetic as far as I'm aware.

sorry guys for my absence, I didn't notice all the traffic here.

@milindur
great you are referencing by commit hashes.

Sorry, that essentially my code lead to that bad misbehaviour on your machine. As I stated, my code was just a preview, and not meant to be used for production. On major reason for that is, that I have not an army of MMU2 to be tested - it is only one unit, and I don't know the variances between different machines.

It's very likely, that your spindle has a slightly higher friction. I also used some oil on my spindle, as it had difficulties with the stock firmware on homing.

@joshua.j9
I also once saw that idler homing loop on my machine.

@khalil.n
Just wanna clarify that the CHANGELOG.md is all from my fork, which has been merged into robert.m28's fork.

@robert.m28, perhaps you can keep the CHANGELOG.md updated, so we can easily track your changes and the state of the firmware.
what do you plan with both of your forks? do you think, Prusa will merge them, when you start a pull request?
A hard fork would perhaps be a dead end, if it is not supported by Prusa.
Further more, I recommend you to use GitKraken as a Git GUI client. There you can easily change the most recent commit message or squash multiple commits into one commit. Branching and merging is also very easy there.
Also you can add there other remotes very easily, which would help to keep track of merges.
Attached is a screenshot of this project. You can keep track of everyone's commits very easily. I've reformatted your code and published it on https://github.com/KarlZeilhofer/MM-control-01/tree/master-zero

You should do this before any commit, so the diffs will stay consistent. Artistic Style ( https://sourceforge.net/projects/astyle/ ) is FOSS which also runs on Windows - if that's your development environment. Perhaps you can provide a windows batch file, base on the format.sh, which is for Linux's bash.

For your info:
I'm in contact with Prusa, but sadly still without any results for the community.

Hey Karl,

Thank you for the post update and guidance, much appreciated, I'm very new to git and first timer at AVR (good to learn though, I have many AVR projects planned for the future).

I have AStyle built and working now, OS X so wasn't too tricky thank you.

I also started updating the CHANGELOG.md and will strive to update with each version 👍

Karl, I haven't had good luck getting would I would consider essential pulls into their codebase. E.g my MK3-YAxis mount update, I still use my prototype and always homes within 1step on Y. https://github.com/prusa3d/Original-Prusa-i3/pull/74

If we get it working good I can only hope that PRUSA is willing to get the best experience possible to the masses, if not, then at least the people on the forum can have a solid, reliable FW.

Good to hear you're in contact with them and hope they pull their finger out, I believe a lot of people including myself feel they have dropped the ball with the MMU. Yes I'm sure with high tolerance/quality filament it will work stock but it was promised as being much more accommodating than MMU1. Chuck's DIY MMU2 is running so, so good so I have hope for the rest of us.

Re: Improvements to the MMU 2.0 controller firmware

Chuck's DIY MMU2 is running so, so good so I have hope for the rest of us.

Hi Robert,

I'm trying your firmware now, MMU version 176 and MK3 version 2107. No problems compiling and flashing.

It seems to boot and home the MMU correctly, and if I do a Load All from the MK3, each filament appears to load to the FINDA and unload back correctly. I can post videos of these steps if you want to check if anything unexpected is happening.

When I start a print, it switches to the first filament for the print which is filament 1 and loads it to the extruder correctly. Filament 1 starts to come out of the nozzle while printing the initial purge line. Great!

HOWEVER, as the MK3 moves from the initial purge line to the purge block on the first layer, the MMU2 idler suddenly shifts to the 2nd filament position (the selector stays on 1), the pulley advances filament 2 by about 2-3 cm, then the idler moves again. The first time it happened, I didn't catch it, so on the next filament change the selector jammed on the protruding filament. 😮

Here's a video:

The problem happens at 0:42 but it's pretty quick and easy to miss if you aren't watching closely.

.gcode file is also attached. This is a simple 5 color swatch test, only 1 layer.

UPDATE:
The problem seems to be caused by the second T0 command that slic3r inserted between the purge line and the purge block (the first T0 command is just before the purge line). I'm looking at your code now and it seems this case is handled (previous_extruder == active_extruder), but regardless, if I remove the redundant T0 and change nothing else then it works correctly! Attached updated .gcode file.

Re: Improvements to the MMU 2.0 controller firmware

Well, good and bad news for Robert's firmware. Good news is that after removing the extra T0 from the gcode, I was able to get pretty far into a print.

Bad news is, after 19 successful layers (roughly 40 tool changes), the MMU2 froze up during a filament change. At least I think the MMU2 froze.

It looks like the current tool was supposed to be red (filament 2), but on this layer it started printing black (filament 1) where it should have been red. (See the one layer of black infill on top of the red part.) The printer shows it is currently trying to switch from filament 2 > 1, but the MMU was already erroneously on filament 1 (should have been on 2). The MK3 successfully unloaded filament up to the bondtech gears, but then the MMU2 didn't start the unload. The MMU2 was showing a solid red light on filament 1 and was not responsive to any buttons. The MK3 LCD menus were still working but nothing I tried would get the print to resume.

Looks like maybe the MMU2 missed a tool change or got confused which tool it was on?

Re: Improvements to the MMU 2.0 controller firmware

Hey guys,

Thanks for giving it a crack, glad it works somewhat but puzzling why we all get different results can you please do the following?

- Check MK3 FSensor state in MK3 Menu?
- Get a dump of the serial output when you get any of these issues as it has diagnostic messages regarding what is actually happening

@jettoblack - your issue with it just stopping with no flashing sounds like missed or corrupted serial communication, I will see what I can implement to protect again this. I think my test print at home may have suffered from this from this, goes good and then just stops and appears in the serial output as if it is waiting for a tool change from MMU2 but it is chilling, totally missed the message. One of the drawbacks of not having interrupt driven comms (TODO list)

I will see what else I can do about the duplicate toolChange commands as this should not be happening and doesn't appear in my setup.

Thank you for your efforts, I'll add this to the GitHub issues and we'll work on it.
https://github.com/TheZeroBeast/MM-control-01/issues/6
If anyone is a code guru please don't be shy, I want this working asap. Sick of failed prints.

Re: Improvements to the MMU 2.0 controller firmware

- Check MK3 FSensor state in MK3 Menu?

It was on before flashing and appears to still be on. Most of the loads were working fine on your new FW (way better than the stock MMU2 FW at least) until I ran into the issues mentioned.

- Get a dump of the serial output when you get any of these issues as it has diagnostic messages regarding what is actually happening

How do you do that? I tried the serial comm monitor in Arduino IDE (connected to MMU2) and didn't get anything. Should it be the MK3's serial log?

Re: Improvements to the MMU 2.0 controller firmware

I don't think the MMU has a serial out - I think the USB port is only alive for the first 5 seconds. Do you have to leave you PC logging during the whole print?

I would love to get a log of optical sensor put out on the serial port, to see how far from working it is. If the Prusa folks weren't so closed lipped, they could tell us what they saw - they have put out several versions of sensor handling, I'd like to start with that knowledge.

Note: MK3 filament sensor needs to be enabled or MMU2 will never load filament into extruder properly.
Also, if the fprint library isn't enabled for your compiler as per PRUSA instructions on their README.md then you will see a "?" for Z height. Cosmetic as far as I'm aware.
OH! Ok, I'll admit, I skipped that step. Guess I'd better do it! It didn't seem to effect the print.

I wonder if just rehoming on EVERY missed load makes more sense? Before or maybe after the cutting motion, mainly to get the drum in place.

The latest FW for printer and MMU are ready for testing?

Also: No one owes any apologies for prints not working with their alpha firmware! I hope I haven't portrayed my failures as anyone's "fault".

Re: Improvements to the MMU 2.0 controller firmware

I have two suggestions about trimming:

1) Rehome after a trim/feed failure. Often as it trims, I'll see filament come out of the next hole (this may well be fixed in the current version of your firmware, I could try it all again.), but if something went wrong the least destructive/most likely to help may be rehoming (especially the drum)

2) Retry at least once before trying the trim
I really had a lot of prints go well with the blade removed entirely. With the new code I HAVE to have it in so I put it back. I think it would often survive without issue if you just try to feed again? I'm not sure what the original behavior is, but I think it worked.

I feel the unneeded trims contribute to plastic chips which can get in the works and cause issues. I may be worried about nothing, so I'm curious what people think.

===========================
Watching the printer run today, it's two main issues, these new chips, and not unfeeding - some of which is the chips (from ramming/etc I guess?), some is the extruder isn't letting, but none of it would be an issue if the drum wasn't losing home. Tightened screws again, maybe that's it.

Re: Improvements to the MMU 2.0 controller firmware

Feature Request: Can you turn the light on in the little ball sensor when it is activated, off again when it is not?

I'm not dead sure it has one, but it's a nice feature of the main z-level sensor, and it would make me more confident in general if it could be done.

Re: Improvements to the MMU 2.0 controller firmware

- Check MK3 FSensor state in MK3 Menu?

It was on before flashing and appears to still be on. Most of the loads were working fine on your new FW (way better than the stock MMU2 FW at least) until I ran into the issues mentioned.

- Get a dump of the serial output when you get any of these issues as it has diagnostic messages regarding what is actually happening

How do you do that? I tried the serial comm monitor in Arduino IDE (connected to MMU2) and didn't get anything. Should it be the MK3's serial log?

Nice, good to hear.

To get serial log you would view through usb to MK3 or your octoprint terminal.

Re: Improvements to the MMU 2.0 controller firmware

I have two suggestions about trimming:

1) Rehome after a trim/feed failure. Often as it trims, I'll see filament come out of the next hole (this may well be fixed in the current version of your firmware, I could try it all again.), but if something went wrong the least destructive/most likely to help may be rehoming (especially the drum)
With the changing to enable MK3 FSensor I have removed cutting method again as the 90degree edges would more times than not catch after the sensor on the way to bondtech gears. Angled cut and pausing for using intervention rarely is going to be getting I'm pegging.

2) Retry at least once before trying the trim
I really had a lot of prints go well with the blade removed entirely. With the new code I HAVE to have it in so I put it back. I think it would often survive without issue if you just try to feed again? I'm not sure what the original behavior is, but I think it worked.

I feel the unneeded trims contribute to plastic chips which can get in the works and cause issues. I may be worried about nothing, so I'm curious what people think.
Yes, oh my, yes, damn those cut pieces got everywhere and even at times caused idler mishoming.

IMG_20181105_192612 (1).jpg
===========================
Watching the printer run today, it's two main issues, these new chips, and not unfeeding - some of which is the chips (from ramming/etc I guess?), some is the extruder isn't letting, but none of it would be an issue if the drum wasn't losing home. Tightened screws again, maybe that's it.

Interesting, thank you for the update.
My Patch1 is in final tweaking stages with comms ack on each command to MMU2 so none will be missed

Re: Improvements to the MMU 2.0 controller firmware

I have some ironic news: I smashed my optical sensor, so I cant try the new firmware until I get some parts shipped from Prusa!!! 😛

These chips are getting worse.

I am wondering if I'd been running PET and TPU only earlier, so I didn't see these issues with more forgiving filaments?

Anyway, until I can get my first layers to stick and my flakes to go away and a new sensor, I'm kinda just waiting. 😛