New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MMUv2 Idler doesn't always park/disengage after filament load. #135
Comments
I'm experiencing this too. I don't know if this problem is related. Have you experienced your extruder pausing after the filament reaches the gears and trips the IR sensor? My mmu will then try to unload the filament held by the extruder and grind down the filament. Mk3S MMU2S |
@bmmerril It has happened to me a few times but at least for me does not seem to be as prevalent as the issue I describe here. The issue you are describing has multiple issues posted on the /prusa3d/Prusa-Firmware GitHub. For the idler not disengaging I thought that is might be in this code,
The MMU is listening for an 'A' to be sent by the printer firmware, essentially as the signal that it has made it to the Bondtech gears as seen by the IR sensor, it then disengages the idler. My thinking was that maybe it isn't getting the 'A' and not running the disengage code inside the If statement. But by monitoring the Octoprint command output, I saw the 'A' and the MMU responded even on moves where the idler technically didn't disengage. I am still looking around but I am nowhere near as knowledgable of the codebase as the Prusa devs who made/ are working on it, which makes a huge difference, but I am learning more as I go. I was hoping it was simply a case of idler current which is why I tried @mkbel 1.6.0 firmware with increased idler currents but it made no difference in this issue. |
Just an update. I added a call to the motion_disengage_idler() function right after the motion_feed_to_bondtech() in load_filament_withSensor(). While technically there is a call to motion_disengage_idler() in motion_feed_to_bondtech() already, I did this just a test and as a fallback. As far as I can tell adding that extra motion_disengage_idler() would do nothing if it is already disengaged, and if it wasn't for whatever reason, then it would have another chance to disengage it. I tested this on a test print that uses all 5 filaments every layer for a total of 100 tool changes over about 3 hours, and not a single one failed to engage. So it seems to work and I had a perfect print with no user interaction. I am going to give it a real test tonight, with a print that will also use all filaments and will be a total of nearly 600 tool changes over 17 hours. While I am not sure that that is how they would want to solve the problem, it might help in identifying it better, so I may create a pull request tomorrow. That way it may at least get some attention so they can get the same result the way they want to if they don't want to use this method. |
This shouldn't be needed but seems to solve the issue shown in prusa3d#135
I have the same problem with my new MMU 2.0 (MK3), |
@Prusauser Are you using MMU2 or MMU2S? |
@BryanSmithDev MMU2S |
@Prusauser If you want you can try this. I submitted a potential fix but they have not merged/or commented on it, but you can download a compiled version of v1.0.5 with my one line fix. I was able to print a 17 hour 600+ tool change print on it so it seems to be working. At least temporarily until Prusa makes a move. |
I've just got in contact with prusa, the issue on my side was the IR sensor (located before the extruder gears) which didnt't trigger all the time. There is a tutorial on how you can calibrate the sensor: https://help.prusa3d.com/article/wprwemqsmj-ir-filament-sensor-calibration @BryanSmithDev thanks for your help if there is any problem in the future i will try your version |
Make sure idler disengages - Issue #135
Fixed in #136 |
I upgraded my MK3 to MK3S. Afterward, I have been getting great tips on my filament between filament changes however I still randomly get failed unloads and loads. After very close inspection, I have found that the issue is that (seemingly randomly) the idler will not park or disengage after a filament has made it to the bondtech gears and gets pulled in by the extruder. Since the idler is still applying pressure to the filament, the extruder is working against the MMUv2 gears as they are no longer moving. This creates extra friction and grinds away some of the filament. While the print will sometimes make it for a little while, eventually it ends in a failed load or unload due to this.
As I have watched the prints, this seems to occur on any of the filament paths (1-5) and sometimes it will disengage and sometimes it won't. There doesn't seem to be any pattern if it does or doesn't. Although it seems to happen on path 1 more but I am not sure if that is just the one I happen to notice the most or if it is actually happening most on it. While it seems random it is also quite frequent. In a test file that prints all 5 filaments each layer, it will happen at least once usually per layer. It doesn't seem to matter what I am printing as multiple files have the same issue. It has been hard to track down. I have been looking in the code for anything but any attempts I have made produced no change in the behavior. I have also tried multiple firmware versions to see if they made an impact or not. None of them made a difference. Also, putting the MMU into stealth mode or normal mode doesn't seem to make a difference either in the undesired behavior.
Everything else seems to work great, and if it wasn't for the idler randomly deciding to not get out of the way, it appears my MMU prints would have quite a good chance at success.
Current:
MK3S on 3.7.0
MMUv2 on 1.5.0
Tried:
MK3S 3.7.0-RC1
MK3S 3.6.0
MMUv2 1.6 from mkbel's repo with increased idler current
If relevant, I am using Slic3r 1.42.0-beta1
The text was updated successfully, but these errors were encountered: