ProfessorFalkan
commented
4 months ago Small update: the Printer is the MK3S+
Closed ProfessorFalkan closed 1 month ago
ProfessorFalkan
commented
4 months ago Small update: the Printer is the MK3S+
ProfessorFalkan
commented
4 months ago From Prusa Chat. This is quite a useful explanation of the Idler homing.
I'm not a firmware developer, but to my knowledge, the StallGuard is a firmware feature that detects when a motor encounters a specific amount of resistance, detecting e.g. a crash or pushing against a homing position (like in the case of the idler). This is needed so the MMU knows where "zero" is for the idler, so that it can correctly line up the bearings with the 5 filament paths.
This value is highly dependent on the specific stepper motor used, and in your case, the bigger motor produces more torque, thus wrongly triggering the error. The correct idler motor would work in this case.
The good news is that we're very close to an easy firmware fix from our side, once the MMU3 for MK4 releases (which should be in the next few weeks). We can tweak the values to accept the bigger motor as well.
ProfessorFalkan
commented
4 months ago Prusa Support Chat is in the Notepad doc.
3.13.1 seems to be incomplete for MMU3 support. Result is MMU3 will not work until the new firmware is available. I've asked for a Warning to be placed on the MMU3 Upgrade Sales page so any prospective buyer are aware of this issue before they make a purchase otherwise I would consider not providing an update as to this not working with the current firmware as misleading sales practices and dishonest now this issue is somewhat identified but not dev confirmed. DominikMon030424.txt
ProfessorFalkan
commented
4 months ago Please escalate/flag and add this to the Internal Issues register once it has been confirmed.
ProfessorFalkan
commented
3 months ago Upgraded to 3.13.3 with 3.0.3
This firmware is junk. The problem still exists in the latest firmware. Using Putty to serial in is fine but none of the M707 or M708 command to change the registers will work unless the MMU is turned on the in the menu. The minute the MMU is turned on Idle Homing Fails. I set the Tuning menu sensistivity to 4 which is the lowest parameter and it did nothing. Once the Idler Homing Fails the MMU spits back so many error messages into the Putty window and it is not possible to break the feed without closing the session. What I had to do is copy M708 A0x19 X3 and right click on the Putty window with Enter immediately and then it homed correctly. This race condition is borne of such lazy coding, I just dont understand how any NORMAL user would figure out how to fix this.
This is still a bug that needs attention and fixed. At least I have found a workaround and have properly documented it.
jmhossler
commented
3 months ago Yeah, this is actually a very concerning bug. I purchased the mmu3 upgrade this past week, and I had some other prints I was working on. I was tired of the warning about the old firmware version, so I upgraded my base printer firmware version while I work on my current projects as well as print the materials for the mmu3 upgrade, but was met with this issue. I'm having to downgrade my printer and mmu2s firmware just so my printer will function again so I can continue printing.
To be clear, I am also seeing this issue on the MMU2S with the MK3S+. With the other comments in this thread, I have to ask; does this firmware release work AT ALL?
Has anyone gotten the mmu3 working at all? has anyone seen it working?
It seems like whoever is working on the code recently has never loaded this code onto a printer before shipping it, because if so it would never have been released. I'm going to be watching for a blog post of a post mortem of this issue, since this is something that breaks old hardware and doesn't even work on the new hardware.
IMO, once the exact bug is fixed and identified, git blame whoever made the change and whoever approved it. They should take more care with the code they push up and approve.
ProfessorFalkan
commented
3 months ago @jmhossler I've gotten the MMU3 with 3.0.2 and 3.13.3 on the MK3s+ I doubt your are going to see anything by way of blog post or even public acknowledgement. This bug has been opened for a week and its not yet acknowledged or assigned. The best thing I think you can do is try the firmware upgrade and then post all your findings here. The more people add their experiences to this post the more likely it will be acknowledged. To be clear I did get this working but I think it was more by accident than design.
ProfessorFalkan
commented
3 months ago I've now had to save this webpage as I fear this bug is going to get pulled down. See the Customer Support thread I have going below.
What a glib and condescending response. What evidence do you sight to explain why my motor is different?
The motor is an original Prusa Idler motor from an MMU2. My order number for the MMU3 UPGRADE kit is 1708232206.
The issue is not the motor it is the completely crap firmware that is being produced by Prusa Developers. You are not addressing the actual problem. What I expect from Prusa and yourself is that you actually read the bug I have posted on Github and properly address it. Your the 3rd Customer Support person I have been in contact with and your response below directly contradicts what I already have in WRITING from the 1st Customer Support person who told me the motor is correct. It clearly shows Prusa Research Idler Motor on the side of the motor for god sake.
Please send the replacement motor to: XXX
I will receive your new motor and test it and post all my results and feedback to the Github bug I have created.
PC
From: Zuzana Ungerová info@prusa3d.com Sent: Monday, 11 March 2024 10:33 PM To: Phil Subject: Re: MK3S with MMU3 Upgrade. Hello Phil.
The motor you have is a different size than the original one. If none of the other sensitivity adjustment values have helped you, please confirm the order number for MMU3 and your delivery address, I will send you the replacement for this part.
Kind regards,
— Zuzana Ungerová Customer support PRUSA Research | Partyzánská 188/7a | 17000 Prague | 00420 222 263 718 | 00421 220 570 305 | 00420 226 258 861
On March 11, 2024 at 2:33 AM GMT+1 phil wrote:
Hi,
The lastest firmware is just a non functional as the previous firmware. The sensitivity menu has been reintroduced but still doesnt solve the problem.
Have you been reading the GitHub bug?
Phil
From: Zuzana Ungerová info@prusa3d.com Sent: Thursday, March 7, 2024 11:51 PM To: Phil Subject: Re: MK3S with MMU3 Upgrade.
You don't often get email from info@prusa3d.com. Learn why this is important
Hello.
Have you tried the latest FW 3.13.3+3.0.2, please?
Best regards,
—
Zuzana Ungerová
Customer support
PRUSA Research | Partyzánská 188/7a | 17000 Prague | 00420 222 263 718 | 00421 220 570 305 | 00420 226 258 861
On March 5, 2024 at 11:30 PM GMT+1 phil wrote:
Hi Zuzana,
I’m sorry but it appears that you have not read the conversation with Dominik and Jan in the Github bug I have posted.
The 3.13.1 firmware appears to be very broken.
Yes, you can enter M708 A0x19 X2 values between 1-10 but a M707 does not confirm the inputted value has been received by the EEPROM.
Furthermore, when MMU is set to ON in the printer menu the MMU constantly polls the putty session with so many error messages that it is not possible to get an idle cursor to input any of the M708 codes.
The MMU must be set to OFF so the G-Codes can be entered.
None of the suggested G-Code value changes between 1-10 solved the problem.
None of the G-Code values could CONFIRM any of the M708 values were entered. This firmware is extremely poorly written for the MMU3 unless you can empirically prove otherwise.
I also notice that the Github bug I have opened has not been assigned to anyone.
With that in mind I have bought an MMU3 upgrade that is unsupported and does not work.
How will you compensate me or rectify this situation please?
From: Zuzana Ungerová info@prusa3d.com Sent: Wednesday, March 6, 2024 12:45 AM To: Phil Subject: Re: MK3S with MMU3 Upgrade.
You don't often get email from info@prusa3d.com. Learn why this is important
Hello Philip.
We are working on a fix in the FW 3.13.2 and the new FW should be released soon, although we don't have a closer info on this.
If you are missing the tune menu, the sensitivity can be also set through the g-code. You can put command at the start of the g-code directly in Prusaslicer to end it to the printer. Here is the range from 1-10.
M708 A0x19 X1 M84 M708 A0x19 X2 M84 ...
M708 A0x19 X10 M84 Let me know if you require any further help.
Best regards,
—
Zuzana Ungerová
Customer support
Prusa-Support
commented
3 months ago I am unsure as to why this reported bug 4285 was removed
So do us. We wondered that too and only now I realize the author may no longer be on GitHub - maybe claimed all personal data from GitHub as per the GDPR rules. IDK. As usual, we collected as much feedback as possible from there which may eventually be used for further improvements, however, there was no confirmed firmware problem. .
@jmhossler All in all, MMU3 feedback is extremely positive. Please contact our Customer Support for help with your MMU2S. In a few cases it may require some assembly polishing to work fine with the latest firmware which iwas intentionally made friction-sensitive (to a certain extent).
. I'm sorry, it seems the case of a faulty Idler motor being slightly off the part specifications, and our Customer Support can sort this out. @ProfessorFalkan Please follow the indications from Zuzana who is highly qualified to support you with your troubles with the MMU, and consider closing this issue as not firmware-related if you don't mind.
Michele Moramarco Prusa Research
jmhossler
commented
3 months ago I got my mmu3 upgrade and, despite my concerns, decided to go ahead and try this as well despite seeing this bug on the mmu2s as well.
I have good news, and bad news.
I think there is still something wrong with the commands or at least the lifecycle of the startup of the MMU in the most recent versions, as I was unable to even get lucky like @ProfessorFalkan with setting that value before it failed over a serial connection AFTER starting the connection using the M708 command.
For reference, here are the firmware versions I was using when I was still having these issues:
MK3S+ Firmware Version: 3.13.3 MMU3 Firmware Version: 3.0.2
I retried many times, even using M709 to force a reset before using M708 to update using a direct command to set the Idler_sg_thrs_R value. Regardless of if I used X02, X2, X03, X3, X01, X1, the resulting value that got set on the printer was always set to 19, at least when I used the tune option to see what it saw as the set value. How did it get 19? no idea, I think this is part of the bug. Due to the fact that the idler could never home, I do think the Idler_sg_thrs_R was for some reason getting set to 19, even after command sequences like
M708 A0x19 X03
M84
M709I decided to take a stab at building what is in master, though, after I saw that the menu has been updated (though this has not made it to release yet) from having a range of 4-7 to 2-10. I went ahead and just updated that to be 1-10 and built a beta version of the prusa mk3s firmware and flashed my printer.
With this change, I was able to set the sensitivity, or the Idler_sg_thrs_R value, to 2, and the idler was finally able to home correctly and I was able to use the printer. I haven't checked if a value of 3 would have worked for me, I'll attempt that tomorrow, but at the very least I think the changes in master that we should hopefully see by the v3.14 release should include a sufficient range from the menu itself to not require users to have to fuss with this themselves.
However, I do think that there is something to be investigated in terms of how serial commands are interpreted/applied since it seems like the more technical fix to this in the latest release (3.13.3) requires more luck than anything else. My changes to attempt to set the Idler_sg_thrs_R should have been sufficient to fix this issue on the latest release, and the fact that it was not is something to be investigated, IMO, though I do not have the firmware experience to know how to do this myself.
I've learned and seen enough to know that this isn't a problem that effects all users, but a problem still bothers me: why do some users see this consistently so much that they have to set this value lower than what testers needed to get it working? This is where I have basically zero experience with, but I figured I'd post some information about my idler motor in hopes that maybe we can find why/how this failure got missed.
Order date of original MMU2S: 6/20/2020
Motor type: NEMA17 1.8 degree Stepper Motor QR code reference number: 2518-13200213
The reason why I point this out is that I wonder if there was an older version of the motor was quickly replaced, so it was easy to overlook testing on earlier versions of the idler motor that were shipped out. Or, it could just be that this motor is coming up on its 4th birthday, maybe it is just old. I did notice that in the photos that the QR code reference number is different, though everything else is the same. In the assembly guide, it looks like the QR code reference number is 2329-000013.
Anyway, that's all I have. I'll be running a beta version until the increased range is out, since the latest release is busted for at least some users who did the MMU2S -> MMU3 upgrade. Hopefully anyone else having this issue while we wait for the next release will find this post and find the information useful.
gudnimg
commented
3 months ago However, I do think that there is something to be investigated in terms of how serial commands are interpreted/applied since it seems like the more technical fix to this in the latest release (3.13.3) requires more luck than anything else. My changes to attempt to set the Idler_sg_thrs_R should have been sufficient to fix this issue on the latest release, and the fact that it was not is something to be investigated, IMO, though I do not have the firmware experience to know how to do this myself.
@jmhossler I want to add to this thread info which seems to have been lost with the deletion of Github issue 4285. There users confirmed that the G-code is case sensitive.
Octoprint by default capitalises everything. And there is a setting (I don't remember where) which will disable it.
What happens with M708 A0x19 X03 is that the small x will be capitalised, and the printer will interpret: M708 A0 X19.
I've always used the Serial Monitor in Arduino IDE to write stuff like this, as it is not effected by the "Spammy" incoming serial stream from the printer. It's also important that the entire command is sent at once, not one character at a time (I noticed that myself when trying Putty a while ago).
gudnimg
commented
3 months ago Found this comment from @3d-gussner which describes how to handle this in Octoprint https://github.com/prusa3d/Prusa-Firmware/issues/4484#issuecomment-1795331514
I do realise however you're maybe not using Octoprint. But thought I should add this info here anyway.
jmhossler
commented
3 months ago @gudnimg that info is useful! I was mostly using octoprint, but at the end I started to try to use Pronsole to try and send it with a direct connection. Looks like that application might also have been causing the case to change unintentionally from that thread you linked
ProfessorFalkan
commented
3 months ago @gudnimg and @jmhossler for the serial connection I used Putty following the instructions here: https://help.prusa3d.com/article/crash-dump_364959
At the end of the day it doesn't matter what motors are shipped. There should be solid enough processes internally at Prusa to know exactly what motors are shipped with any MMU2's and upgrade kits ever sold. The problem appears to be that the dev's writing the firmware are not accounting for the various models of idler motor being shipped.....hell....the internal processes may NOT be solid enough for them to be able to run a report that tells them all the versions of idler motors ever sold. If you dont know about it then it doesnt exist right? Either way none of this is good and highlights some flaws in the system.
@jmhossler the fact that you had to compile your own firmware blows my mind. This is simply unacceptable for mainstream use.
@Prusa-Support why have you removed the Bug label and replaced it with HW Issue?
Can you provide empirical evidence that clearly shows this is not a bug?
jmhossler
commented
3 months ago @ProfessorFalkan if you look at the commit I reference that has the fix for this, it is a change that has been in the MK3 branch since November 23rd, 2023, it just didn't end up in the 3.13.3 release. And I agree that my current fix isn't something that is acceptable for mainstream use if anyone else encounters it, but I did at least verify that the options have been expanded and they do work for me, without needing to input any commands over a serial connection.
In my mind, I know the issue where the provided configuration options for sensitivity aren't sufficiently wide enough has been fixed, just not released. I feel like this has been mostly resolved, it is just pending release (an ETA would be nice if anyone knows).
I'm currently printing some items now, but if I can confirm that the issue of not being able to set the value was due to this upper case issue for me and that I can downgrade and fix the issue on the latest release by using the M708 A0x19 X02 command, then I do think there isn't much else to be done or said on this issue.
Update: I downgraded back to 3.13.3 and verified that I could use M708 A0x19 X2 to set the idler config and get it in a good state without any firmware change, after following the steps mentioned to turn off capitalization of commands from M708 in the octoprint serial terminal to the printer 🥳
ProfessorFalkan
commented
3 months ago @jmhossler update from me. I received the new Idler motor and it is different from the one in the MMU2. I changed the old for new and I can confirm this fixed the problem. Set the sensitivity to 6 and off it went, happy.
Therefore this is both a firmware and supply chain issue.
For the MMU3 upgrade kit that I bought the instructions clearly mention to salvage the mmu2 idler motor and reuse it. If this is the directive, then I expect that the firmware to support this older motor.
If the firmware does not support the old motor, then the new motor MUST be included in the upgrade kit.
What comes first? the chicken or the egg?
chrisboer
commented
2 months ago I fixed the issue also with Octopi but how will a "normal" user be able to fix this issue.
I still have the old Idler motor by the way it worked with setting M708 A0x19 X3 M84 for me.
But again please test firmware on all possible printermodels.
This is not good for your brand name... !!!
bentdragon
commented
2 months ago I also bought the MM3 upgrade and have printed the plastic parts 4 times as that is what prusa chat said as the tolerances must be out. No change. I thought by buying the MMU3 I would put the MMU2 woes behind me. I am constantly getting the "printer the Idler Cannot Home correctly". I cannot set the sensitivity to anything past 7. I have about 80 hours so far in trying to get this MMU to work. tried, 15 prints and 92 errors. If the mmu2 hardware was not compatible, why do they sell this kit. Should someone have tested this prior to release? How do I get an idler motor as I do not see any MMU3 parts listed? This is not sitting well with me as I have alot of problems with the MK4 as well. it is a factory assembled unit and they have replaced the thermister, the LCD, the motherboard, as we still have issues as the unit constantly hangs. Thank god for My mk3S.
bentdragon
commented
2 months ago Just got off with tech and he says there is no issue with the MMU2 hardware when upgrading to MMU3. Especially the motors? He had me adjust all my settings from the upgrade kit and now I can not print anything from the MMU3, and the printer is only working with the MMU on. ? . Do these guys ever talk to each other.? I am going to buy the Bambu labs X1 carbon, unit as I am done spending money on pre-release equipment. Sorry but love my Prusa MK3S and my MK3S+. But feel like a guinea pig on the MK4 and the MMU3. Hope they figure things out. Honesty is a good thing, as leading people on only frustrates them.
Downgraded the code from 2.7.4 to 2.7.3 and exact same print job now works on MMU3. Seems they didn't test everything. Had to reset all the setting that were changed today from the tech, but after I adjusted the print went off perfect. Guess shouldnt be one of the first to upgrade. But then I thought they would have tested it? Say it isnt so!
Still going to buy a X1 Carbon as it cant be this bad.
Prusa-Support
commented
2 months ago What comes first? the chicken or the egg?
Our official Tech Support comes first. 🙂 No hardware or firmware-heavy knowledge required, and I'm glad to hear that the problem is fixed. Our Customer Support can help you solve the problem or confirm a firmware bug.
.
Should someone have tested this prior to release?
Seems they didn't test everything.
But then I thought they would have tested it? Say it isnt so!
The developers, the internal testers, the external testers, and many volunteering employees of very different competencies and departments tested this product and initial firmware for around one year before the release, and yet continue trying to push the product beyond limits. Unfortunately, I don't have numbers but we are looking at hundreds of people involved (amid newcomers, intermediate, and advanced) with thousands of print hours. I hope this addresses your concern.
Back to the problem now, please give our Tech Support no rest until the problem is resolved. If another proper troubleshooting with any of our agents won't be fruitful, feel free to quote me and mention my name at the end of the conversation with Tech Support. The agent will reach me and we will do our best to escalate the case together.
.
With a reminder that
I recommend closing this issue.
Michele Moramarco Prusa Research
Prusa-Support
commented
1 month ago This case was rather specific and not based on the firmware but on a hardware problem solved via an idler motor replacement.
Please allow me to close this issue and, should newcomers incur similar troubles, please contact our Customer Support as soon as possible for guided hardware troubleshooting and inspection.
Michele Moramarco Prusa Research
bentdragon
commented
1 month ago If it was a hardware issue why did we not replace it ?No dragon's were harmed in the sending of this emailOn May 21, 2024, at 6:38 AM, Prusa-Support @.***> wrote: This case was rather specific and not based on the firmware but on a hardware problem solved via an idler motor replacement. Please allow me to close this issue and, should newcomers incur similar troubles, please contact our Customer Support as soon as possible for guided hardware troubleshooting and inspection. Michele Moramarco Prusa Research
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
chrisboer
commented
1 month ago So I should replace my idler motor ? Is this the solution to my issue ?
Where can I order a new idler motor, I rather do this then spending 80 hours on trying to fix it.
Printer type - MK3S+ Printer firmware version - 3.13.1
MMU upgrade - MMU3 Upgrade from MMU2 MMU upgrade firmware version - 3.0.0
SD card or USB/Octoprint SD card
Describe the bug Upon starting the printer the Idler Cannot Home correctly. This is not a mechanical issue as the idler has completely unimpeded movement when the door is closed or open. The coupler assembly orientation is correct as is the grub screw positioning on the flat of the motor shaft. If I open the door and manually move the idler to its furthermost position it clearly rotates freely. This appears to be an issue with the Idler degree setting which was adjustable in firmware 3.13.2 which has subsequently been pulled. I have used Arduino IDE 2.3.2 with the Rambo board and serialed in on Comm5 to manually adjust the Stallguard threshold value but no inputted value changes the behaviour. The behavior experienced is exactly the same as this https://web.archive.org/web/20230728211129/https://github.com/prusa3d/Prusa-Firmware/issues/4285 In fact, I am unsure as to why this reported bug 4285 was removed as I can confirm it is the issue I am experiencing on the MMU3. As this is the MMU3 I don't want to downgrade the firmware to 1.0.6 as this seems to be for the MMU2.
To Reproduce Start the printer and as long as MMU3 is ON, Idler homing fails immediately thus rendering the MMU3 useless.
Expected behavior When the printer starts and upon initialization of the MMU3 Idler homing will pass the initialization test.
G-code 21:28:13.640 -> start 21:28:16.439 -> echo: 3.13.1-6876 21:28:16.472 -> echo:MMU2:>S0c6. 21:28:16.472 -> ResetRetryAttempts 21:28:16.472 -> SpoolJoin is Off 21:28:16.472 -> echo: Last Updated: Aug 31 2023 10:25:02 | Author: (none, default config) 21:28:16.472 -> echo: Free Memory: 2517 PlannerBufferBytes: 1760 21:28:16.472 -> echo:Stored settings retrieved 21:28:16.610 -> adc_init 21:28:16.610 -> Hotend fan type: NOCTUA 21:28:17.579 -> CrashDetect ENABLED! 21:28:17.982 -> Sending 0xFF 21:28:18.144 -> echo:SD card ok 21:28:28.629 -> echo:MMU2:<S0 A322. 21:28:28.629 -> echo:MMU2:>S1ad. 21:28:28.629 -> echo:MMU2:<S1 A034. 21:28:28.629 -> echo:MMU2:>S210. 21:28:28.629 -> echo:MMU2:<S2 A04f. 21:28:28.629 -> echo:MMU2:>S37b. 21:28:28.629 -> echo:MMU2:<S3 A32e17. 21:28:28.629 -> echo:MMU2:>Wb 533. 21:28:28.629 -> echo:MMU2:<Wb A5c. 21:28:28.684 -> echo:MMU2:>W14 1494. 21:28:28.684 -> echo:MMU2:<W14 A52. 21:28:28.684 -> echo:MMU2:>f021. 21:28:28.684 -> echo:MMU2:<f0 Ac5. 21:28:28.684 -> echo:MMU2:>Q0ea. 21:28:28.684 -> echo:MMU2:<X0 F087. 21:28:28.684 -> echo:MMU2:>R881. 21:28:28.684 -> echo:MMU2:<R8 A08d. 21:28:28.684 -> echo:MMU2:>R1b9e. 21:28:28.684 -> echo:MMU2:<R1b Affbf. 21:28:28.684 -> echo:MMU2:>R1c88. 21:28:28.684 -> echo:MMU2:<R1c Aff60. 21:28:28.684 -> echo:MMU2:>R47b. 21:28:28.684 -> echo:MMU2:<R4 A066. 21:28:28.684 -> echo:MMU2:>R1af5. 21:28:28.684 -> echo:MMU2:<R1a A041. 21:28:29.706 -> echo:MMU2:>Q0ea. 21:28:29.706 -> echo:MMU2:<X0 F087. 21:28:29.706 -> echo:MMU2:>R881. 21:28:29.706 -> echo:MMU2:<R8 A08d. 21:28:29.706 -> echo:MMU2:>R1b9e. 21:28:29.706 -> echo:MMU2:<R1b Affbf. 21:28:29.706 -> echo:MMU2:>R1c88. 21:28:29.706 -> echo:MMU2:<R1c Aff60. 21:28:29.706 -> echo:MMU2:>R47b. 21:28:29.706 -> echo:MMU2:<R4 A066. 21:28:29.706 -> echo:MMU2:>R1af5. 21:28:29.706 -> echo:MMU2:<R1a A041. 21:28:30.697 -> echo:MMU2:>Q0ea. 21:28:30.697 -> echo:MMU2:<X0 E8107df. 21:28:30.697 -> echo:MMU2:>R8*81. 21:28:30.697 -> echo:MMU2:Command Error, last bytes: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 21:28:30.730 -> echo:MMU2:IDLER CANNOT HOME
Video I cannot upload the video for some reason but it is on my personal onedrive. https://1drv.ms/v/s!AgE-5r2a_9WBhNRvXm15a39QcUvNjw?e=4Dnlxz