Skip to content
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

Closed
BryanSmithDev opened this issue Apr 6, 2019 · 9 comments
Closed

Comments

@BryanSmithDev
Copy link
Contributor

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

@bmmerril
Copy link

bmmerril commented Apr 6, 2019

I'm experiencing this too.
My bandaid to the problem was to tighten the extruder idler a bit and loosen the mmu idler quite a bit. I have it just tight enough to feed the filament to the extruder. The extruder then just muscles the filament through the mmu pulley.

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
3.7.0 and 1.05

@BryanSmithDev
Copy link
Contributor Author

BryanSmithDev commented Apr 7, 2019

@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,

if ('A' == getc(uart_com))
{
        s_has_door_sensor = true;
        tmc2130_disable_axis(AX_PUL, tmc2130_mode);
        motion_disengage_idler();
        return;
}

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.

@BryanSmithDev BryanSmithDev changed the title MMUv2 Idler doesn't park/disengage after filament load. MMUv2 Idler doesn't always park/disengage after filament load. Apr 7, 2019
@BryanSmithDev
Copy link
Contributor Author

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.

BryanSmithDev added a commit to BryanSmithDev/MM-control-01 that referenced this issue Apr 8, 2019
This shouldn't be needed but seems to solve the issue shown in prusa3d#135
@Prusauser
Copy link

Prusauser commented Apr 13, 2019

I have the same problem with my new MMU 2.0 (MK3),
this clearly is a big issue at the moment.
It happens at every filament change on my setup!
The Idler does not disengage before the extruder gears
are pulling the filament -> which results in grinding the filament
in the MMU gears. Is this issue only happening at the current MMU
software respectively MK3 software?

@BryanSmithDev
Copy link
Contributor Author

@Prusauser Are you using MMU2 or MMU2S?

@Prusauser
Copy link

@BryanSmithDev MMU2S

@BryanSmithDev
Copy link
Contributor Author

@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.

https://github.com/BryanSmithDev/MM-control-01/releases

@Prusauser
Copy link

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

mkbel added a commit that referenced this issue Apr 24, 2019
Make sure idler disengages - Issue #135
@mkbel
Copy link
Collaborator

mkbel commented Apr 24, 2019

Fixed in #136

@mkbel mkbel closed this as completed Apr 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants