prusa3d / Prusa-Firmware-Buddy

Firmware for the Original Prusa MINI, Original Prusa MK4 and the Original Prusa XL 3D printers by Prusa Research.
Other
1.15k stars 221 forks source link

[BUG] Failing to boot (BSOD) after installing MMU3 on MK4 #3947

Open pars3cproton opened 5 months ago

pars3cproton commented 5 months ago

Printer type - MK4 + MMU3

Printer firmware version - 6.0 RC1, RC2, Final release

Optional upgrades - MMU3

Describe the bug After installing the MMU3, everytime the printer is turned on it tries to boot, it fails once, tries to boot again and then shows a BSOD message (the same message no matter if it's 6.0 RC1/RC2/Final release.

The only possible fix is "touching the cables" of the MMU3 while it boots, as shown in the video attached (you can also see the message in the video). https://drive.google.com/file/d/10S5PZIgaxnuu6wRmS4JdfCftR7sWLvyO/view?usp=drive_link

With support we thought it was one of the two mmu3 boards fault, I tried replacing them but got the same error. Then I bought another printer to mmu3 cable thinking that was the problem, but it's still showing the same behavior.

Support already has a dump file, but feel free to ask for a new one.

As of now the printer is usable if I boot it touching the cable behind the mmu3.

I tried everything, clearing MMU3 eeprom, factory resetting the printer but nothing seems to work.

m-cas commented 5 months ago

my money is on bad solder (or cracked printed circuit trace) on the board you are pressing and the rest of the MMU unit. By pressing you are bending the material enough to restore the contact ... looks like a production defect, I'd ask for a complete new unit.

pars3cproton commented 5 months ago

my money is on bad solder (or cracked printed circuit trace) on the board you are pressing and the rest of the MMU unit. By pressing you are bending the material enough to restore the contact ... looks like a production defect, I'd ask for a complete new unit.

I already got a replacement for both the sheep board and the pd board (big one and small one of the mmu3), replaced and doing the same. I don't need to push it hard, I just need to lightly touch it. I also bought a new mmu3 to printer cable, at this point all the electronics are replaced but still getting the same behavior.

I don't know much about boards or circuits or firmwares, but my money is on the actual printer buddy board (I have version 27)

m-cas commented 5 months ago

this is clearly mechanical in nature. Something you are bending with your fingers enable the power to reach the MMU (leds on). You could try to push in different places (eg don’t touch the connectors, just the board; push something else, etc etc) to try to find out where is it making a difference

On Apr 24, 2024, at 11:33, pars3cproton @.***> wrote:

my money is on bad solder (or cracked printed circuit trace) on the board you are pressing and the rest of the MMU unit. By pressing you are bending the material enough to restore the contact ... looks like a production defect, I'd ask for a complete new unit.

I already got a replacement for both the sheep board and the pd board (big one and small one of the mmu3), replaced and doing the same. I don't need to push it hard, I just need to lightly touch it. I also bought a new mmu3 to printer cable, at this point all the electronics are replaced but still getting the same behavior.

I don't know much about boards or circuits or firmwares, but my money is on the actual printer buddy board (I have version 27)

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

pars3cproton commented 5 months ago

this is clearly mechanical in nature. Something you are bending with your fingers enable the power to reach the MMU (leds on). You could try to push in different places (eg don’t touch the connectors, just the board; push something else, etc etc) to try to find out where is it making a difference First of all thanks for your answers! :) I tried touching just the cable getting inside the pd board and it boots with that too, pushing the cable inside the connector - not touching the board. If I reboot tho it doesn't boot anymore until I keep the cable pressed inside again. It's weird tho because the cable clicks and it looks in place (I don't feel any jiggle keeping it pushed or not) - also the cable is new. I don't really know what to do at this point

m-cas commented 5 months ago

hypothesis: bad manufactured cables and you have two of the same bad batch. You could try this:

Any chance you have a picture of the cable itself and the socket where it goes in?

On Apr 24, 2024, at 11:54, pars3cproton @.***> wrote:

this is clearly mechanical in nature. Something you are bending with your fingers enable the power to reach the MMU (leds on). You could try to push in different places (eg don’t touch the connectors, just the board; push something else, etc etc) to try to find out where is it making a difference First of all thanks for your answers! :) I tried touching just the cable getting inside the pd board and it boots with that too, pushing the cable inside the connector - not touching the board. If I reboot tho it doesn't boot anymore until I keep the cable pressed inside again. It's weird tho because the cable clicks and it looks in place (I don't feel any jiggle keeping it pushed or not) - also the cable is new. I don't really know what to do at this point

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

pars3cproton commented 5 months ago

Sure, here you go! You can find pics of both old and new cable + the pd board https://drive.google.com/drive/folders/1YdJ2uTDLopkkKX7Hkqpco7Au8qQre-0z

On Wed, 24 Apr 2024 at 12:03, Massimo Castelli @.***> wrote:

hypothesis: bad manufactured cables and you have two of the same bad batch. You could try this:

  • remove the cable from the machine. Hold the plastic connector firmly and push the cables inside. You should see, by looking in the little holes or on the side locking tabs if they move. From what you described the seem not to be making contact until you press. I had cables that looked good but were not completely pushed in giving the same effect.
  • bed very slightly the pins inside the receiving connector and see if it works better (by changing the angle it may make contact)

Any chance you have a picture of the cable itself and the socket where it goes in?

On Apr 24, 2024, at 11:54, pars3cproton @.***> wrote:

this is clearly mechanical in nature. Something you are bending with your fingers enable the power to reach the MMU (leds on). You could try to push in different places (eg don’t touch the connectors, just the board; push something else, etc etc) to try to find out where is it making a difference First of all thanks for your answers! :) I tried touching just the cable getting inside the pd board and it boots with that too, pushing the cable inside the connector - not touching the board. If I reboot tho it doesn't boot anymore until I keep the cable pressed inside again. It's weird tho because the cable clicks and it looks in place (I don't feel any jiggle keeping it pushed or not) - also the cable is new. I don't really know what to do at this point

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074579738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JUUA3V22BZJS6AAJQ3Y657N7AVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUGU3TSNZTHA . You are receiving this because you authored the thread.Message ID: @.***>

m-cas commented 5 months ago

I’d try VERY GENTLY with a pin or a very little pointy object to bend the female contacts on the receiving board a little out and see if this makes a difference; not so much that the connector doesn’t fit anymore but just enough to be sure they touch well-From my phone while mobile, please excuse any errors.On 24 Apr 2024, at 12:21, pars3cproton @.***> wrote: Sure, here you go!

You can find pics of both old and new cable + the pd board

https://drive.google.com/drive/folders/1YdJ2uTDLopkkKX7Hkqpco7Au8qQre-0z

On Wed, 24 Apr 2024 at 12:03, Massimo Castelli @.***>

wrote:

hypothesis: bad manufactured cables and you have two of the same bad

batch.

You could try this:

  • remove the cable from the machine. Hold the plastic connector firmly and

push the cables inside. You should see, by looking in the little holes or

on the side locking tabs if they move. From what you described the seem not

to be making contact until you press. I had cables that looked good but

were not completely pushed in giving the same effect.

  • bed very slightly the pins inside the receiving connector and see if it

works better (by changing the angle it may make contact)

Any chance you have a picture of the cable itself and the socket where it

goes in?

On Apr 24, 2024, at 11:54, pars3cproton @.***> wrote:

this is clearly mechanical in nature. Something you are bending with

your fingers enable the power to reach the MMU (leds on). You could try to

push in different places (eg don’t touch the connectors, just the board;

push something else, etc etc) to try to find out where is it making a

difference

First of all thanks for your answers! :)

I tried touching just the cable getting inside the pd board and it boots

with that too, pushing the cable inside the connector - not touching the

board. If I reboot tho it doesn't boot anymore until I keep the cable

pressed inside again. It's weird tho because the cable clicks and it looks

in place (I don't feel any jiggle keeping it pushed or not) - also the

cable is new.

I don't really know what to do at this point

Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you commented.

Reply to this email directly, view it on GitHub

https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074579738,

or unsubscribe

https://github.com/notifications/unsubscribe-auth/AURA4JUUA3V22BZJS6AAJQ3Y657N7AVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUGU3TSNZTHA

.

You are receiving this because you authored the thread.Message ID:

@.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

ClaGre commented 5 months ago

Since touching sometimes it works and sometimes it doesn't, couldn't it be a “simple” cold solder that doesn't make contact properly?

m-cas commented 5 months ago

that is a valid possibility. I’d try with the pins first (lowest effort). Then, if you‘re handy with a solder, refresh the soldering on the connector. My bet is that one of the two will fix it...

On Apr 24, 2024, at 13:08, ClaGre @.***> wrote:

Since touching sometimes it works and sometimes it doesn't, couldn't it be a “simple” cold solder that doesn't make contact properly?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

pars3cproton commented 5 months ago

Bending the pin slightly didn’t work. i can try resoldering the pin on the pd board, it’s just weird to me that 2 pd board of 2 different batches show the same behavior…

On Wed, 24 Apr 2024 at 13:35, Massimo Castelli @.***> wrote:

that is a valid possibility. I’d try with the pins first (lowest effort). Then, if you‘re handy with a solder, refresh the soldering on the connector. My bet is that one of the two will fix it...

On Apr 24, 2024, at 13:08, ClaGre @.***> wrote:

Since touching sometimes it works and sometimes it doesn't, couldn't it be a “simple” cold solder that doesn't make contact properly?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074735726, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JQWOV3L4G57WMDVLQDY66KGJAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUG4ZTKNZSGY . You are receiving this because you authored the thread.Message ID: @.***>

m-cas commented 5 months ago

oh well, let’s go for another classic: take a metal brush or anything mildly abrasive and try to scrub the contacts of the cable and the board clean from a possible oxydation … if this doesn’t fix it, try to push the cable really well into the socket … I’d not try with the solder before having asked prusa support though…

Another possibility is to see if you cn verify the contacts with a tester both on the cable side and on the board side and see if you find any “wobbling when pressed” … try the power lines first (easier to find and from the look of the problem probably the culprit).

On Apr 24, 2024, at 13:50, pars3cproton @.***> wrote:

Bending the pin slightly didn’t work. i can try resoldering the pin on the pd board, it’s just weird to me that 2 pd board of 2 different batches show the same behavior…

On Wed, 24 Apr 2024 at 13:35, Massimo Castelli @.***> wrote:

that is a valid possibility. I’d try with the pins first (lowest effort). Then, if you‘re handy with a solder, refresh the soldering on the connector. My bet is that one of the two will fix it...

On Apr 24, 2024, at 13:08, ClaGre @.***> wrote:

Since touching sometimes it works and sometimes it doesn't, couldn't it be a “simple” cold solder that doesn't make contact properly?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074735726, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JQWOV3L4G57WMDVLQDY66KGJAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUG4ZTKNZSGY . You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

pars3cproton commented 5 months ago

I have 2 of every electronic component, so I can experiment :D i broke the housing of the pin on the sheep board (big one) and probably you were right, those pins are not making good contact with the pd board, since I can just bend the pd board lightly and it works, but if I let go of my hand it doesn’t. I might just end up soldering the two boards together, but I’ll try your new options first!

On Wed, 24 Apr 2024 at 13:56, Massimo Castelli @.***> wrote:

oh well, let’s go for another classic: take a metal brush or anything mildly abrasive and try to scrub the contacts of the cable and the board clean from a possible oxydation … if this doesn’t fix it, try to push the cable really well into the socket … I’d not try with the solder before having asked prusa support though…

Another possibility is to see if you cn verify the contacts with a tester both on the cable side and on the board side and see if you find any “wobbling when pressed” … try the power lines first (easier to find and from the look of the problem probably the culprit).

On Apr 24, 2024, at 13:50, pars3cproton @.***> wrote:

Bending the pin slightly didn’t work. i can try resoldering the pin on the pd board, it’s just weird to me that 2 pd board of 2 different batches show the same behavior…

On Wed, 24 Apr 2024 at 13:35, Massimo Castelli @.***> wrote:

that is a valid possibility. I’d try with the pins first (lowest effort). Then, if you‘re handy with a solder, refresh the soldering on the connector. My bet is that one of the two will fix it...

On Apr 24, 2024, at 13:08, ClaGre @.***> wrote:

Since touching sometimes it works and sometimes it doesn't, couldn't it be a “simple” cold solder that doesn't make contact properly?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074735726>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AURA4JQWOV3L4G57WMDVLQDY66KGJAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUG4ZTKNZSGY>

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074772383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JUEHL7EC6XVP3KQE33Y66MYRAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUG43TEMZYGM . You are receiving this because you authored the thread.Message ID: @.***>

m-cas commented 5 months ago

at least you’ve found the issue :D direct soldering is a little heavy handed though. With all double and a broken connector housing, I’d try to resolder the connector, put some good glue on the broken plastic and try again if this works…

On Apr 24, 2024, at 14:08, pars3cproton @.***> wrote:

I have 2 of every electronic component, so I can experiment :D i broke the housing of the pin on the sheep board (big one) and probably you were right, those pins are not making good contact with the pd board, since I can just bend the pd board lightly and it works, but if I let go of my hand it doesn’t. I might just end up soldering the two boards together, but I’ll try your new options first!

On Wed, 24 Apr 2024 at 13:56, Massimo Castelli @.***> wrote:

oh well, let’s go for another classic: take a metal brush or anything mildly abrasive and try to scrub the contacts of the cable and the board clean from a possible oxydation … if this doesn’t fix it, try to push the cable really well into the socket … I’d not try with the solder before having asked prusa support though…

Another possibility is to see if you cn verify the contacts with a tester both on the cable side and on the board side and see if you find any “wobbling when pressed” … try the power lines first (easier to find and from the look of the problem probably the culprit).

On Apr 24, 2024, at 13:50, pars3cproton @.***> wrote:

Bending the pin slightly didn’t work. i can try resoldering the pin on the pd board, it’s just weird to me that 2 pd board of 2 different batches show the same behavior…

On Wed, 24 Apr 2024 at 13:35, Massimo Castelli @.***> wrote:

that is a valid possibility. I’d try with the pins first (lowest effort). Then, if you‘re handy with a solder, refresh the soldering on the connector. My bet is that one of the two will fix it...

On Apr 24, 2024, at 13:08, ClaGre @.***> wrote:

Since touching sometimes it works and sometimes it doesn't, couldn't it be a “simple” cold solder that doesn't make contact properly?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub < https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074735726>,

or unsubscribe < https://github.com/notifications/unsubscribe-auth/AURA4JQWOV3L4G57WMDVLQDY66KGJAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUG4ZTKNZSGY>

. You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2074772383, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JUEHL7EC6XVP3KQE33Y66MYRAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZUG43TEMZYGM . You are receiving this because you authored the thread.Message ID: @.***>

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

m-cas commented 5 months ago

were you able to solve the issue?

pars3cproton commented 5 months ago

Not really, but it’s better. Keep fiddling with it now put it in a position where it boots half the time without touching anything 😅

On Fri, 26 Apr 2024 at 12:51, Massimo Castelli @.***> wrote:

were you able to solve the issue?

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2079151713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JTLJFPD562XPPD7CL3Y7IWTZAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZGE2TCNZRGM . You are receiving this because you authored the thread.Message ID: @.***>

HaWiWe commented 5 months ago

I have the same BSOD problem when the MMU3 is connected. The fix for me is to leave the USB cable plugged into the MMU (it does not have to be connected to a computer or anything, which logically shouldn't do anything). Video of it can be found here: https://youtu.be/CG1UNtzrMik Support is also stumped as to what the reason is.

pars3cproton commented 5 months ago

What kind of sorcery is that?? It does work as you said, if I keep the cable plugged in I have 100% boot success!

On Wed, 1 May 2024 at 10:30, HaWiWe @.***> wrote:

I have the same BSOD problem when the MMU3 is connected. The fix for me is to leave the USB cable plugged into the MMU (it does not have to be connected to a computer or anything, which logically shouldn't do anything). Video of it can be found here: https://youtu.be/CG1UNtzrMik Support is also stumped as to what the reason is.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2088149968, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JRJUMO6D2NCIKCTJRTZACRYTAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGE2DSOJWHA . You are receiving this because you authored the thread.Message ID: @.***>

HaWiWe commented 5 months ago

Glad to be of help. :) I agree with above poster who said it might be something with soldering, conductive whatever, but noone knows what exactly. As long as that works (and it does, I printed a 510 colour-change Benchy in 8:10 hours) I am okay with it. :P

m-cas commented 5 months ago

… if I were to bet on it, the problem seems to be related to the power lines. The soldering (bad assembly batch) or the bad connection (bad connector production batch) prevent the power to reach the mmu (thus no leds on on the MMU) unless you ‘press’. With the usb cable you deliver power through an alternative path and all parts are now happy.I could also bet that the hw engineers at prusa are already looking at this :)-From my phone while mobile, please excuse any errors.On 1 May 2024, at 11:37, HaWiWe @.***> wrote: Glad to be of help. :) I agree with above poster who said it might be something with soldering, conductive whatever, but noone knows what exactly. As long as that works I am okay with it. :P

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

pars3cproton commented 5 months ago

It would make sense, but the usb is just plugged in and not connected to anything, as the other user said. And I was able to pinpoint the fault to either the cable or the pd board plug

On Wed, 1 May 2024 at 12:12, Massimo Castelli @.***> wrote:

… if I were to bet on it, the problem seems to be related to the power lines. The soldering (bad assembly batch) or the bad connection (bad connector production batch) prevent the power to reach the mmu (thus no leds on on the MMU) unless you ‘press’. With the usb cable you deliver power through an alternative path and all parts are now happy.I could also bet that the hw engineers at prusa are already looking at this :)-From my phone while mobile, please excuse any errors.On 1 May 2024, at 11:37, HaWiWe @.***> wrote: Glad to be of help. :) I agree with above poster who said it might be something with soldering, conductive whatever, but noone knows what exactly. As long as that works I am okay with it. :P

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2088248900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JWEUJGNSHXEB2JGWMDZAC5Y5AVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGI2DQOJQGA . You are receiving this because you authored the thread.Message ID: @.***>

pars3cproton commented 5 months ago

This is a very funny bug btw!

On Wed, 1 May 2024 at 12:13, parsec proton @.***> wrote:

It would make sense, but the usb is just plugged in and not connected to anything, as the other user said. And I was able to pinpoint the fault to either the cable or the pd board plug

On Wed, 1 May 2024 at 12:12, Massimo Castelli @.***> wrote:

… if I were to bet on it, the problem seems to be related to the power lines. The soldering (bad assembly batch) or the bad connection (bad connector production batch) prevent the power to reach the mmu (thus no leds on on the MMU) unless you ‘press’. With the usb cable you deliver power through an alternative path and all parts are now happy.I could also bet that the hw engineers at prusa are already looking at this :)-From my phone while mobile, please excuse any errors.On 1 May 2024, at 11:37, HaWiWe @.***> wrote: Glad to be of help. :) I agree with above poster who said it might be something with soldering, conductive whatever, but noone knows what exactly. As long as that works I am okay with it. :P

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2088248900, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JWEUJGNSHXEB2JGWMDZAC5Y5AVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGI2DQOJQGA . You are receiving this because you authored the thread.Message ID: @.***>

HaWiWe commented 5 months ago

My friend said that that was the reason that I can't be an influencer: I also find the bug to be really funny and interesting. He said to become an influencer I would have had to make a 2-hour rant about it, namedropping other companies that do it a lot better. :P

m-cas commented 5 months ago

LOL true!In my case is the ‘I need to find out what it is and fix it’ spirit that gets tickled by this kind of errors. After having looked at the video I wonder if there is a ground problem that the antenna (the usb cable) helps to sway a little so that it works again.  It would be nice to hear from a prusa engineer!-From my phone while mobile, please excuse any errors.On 1 May 2024, at 13:57, HaWiWe @.***> wrote: My friend said that that was the reason that I can't be an influencer: I also find the bug to be really funny and interesting. He said to become an influencer I would have had to make a 2-hour rant about it, namedropping other companies that do it a lot better. :P

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

pars3cproton commented 5 months ago

One thing that is tickling me is that maybe the bootloader expect the MMU to react faster than it could and the usb plugged in might put a small delay on it, giving it time to properly boot. i don’t even know if it makes sense lol

On Wed, 1 May 2024 at 14:09, Massimo Castelli @.***> wrote:

LOL true!In my case is the ‘I need to find out what it is and fix it’ spirit that gets tickled by this kind of errors. After having looked at the video I wonder if there is a ground problem that the antenna (the usb cable) helps to sway a little so that it works again. It would be nice to hear from a prusa engineer!-From my phone while mobile, please excuse any errors.On 1 May 2024, at 13:57, HaWiWe @.***> wrote: My friend said that that was the reason that I can't be an influencer: I also find the bug to be really funny and interesting. He said to become an influencer I would have had to make a 2-hour rant about it, namedropping other companies that do it a lot better. :P

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2088377248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JQPEDKRHKN5DV3IKG3ZADLPJAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGM3TOMRUHA . You are receiving this because you authored the thread.Message ID: @.***>

m-cas commented 5 months ago

The only thing inside a usb cable is at most a couple of resistors to tell the system that powering the lines is ok… and 20cm of cable in this case…-From my phone while mobile, please excuse any errors.On 1 May 2024, at 14:13, pars3cproton @.***> wrote: One thing that is tickling me is that maybe the bootloader expect the MMU

to react faster than it could and the usb plugged in might put a small

delay on it, giving it time to properly boot. i don’t even know if it makes

sense lol

On Wed, 1 May 2024 at 14:09, Massimo Castelli @.***>

wrote:

LOL true!In my case is the ‘I need to find out what it is and fix it’

spirit that gets tickled by this kind of errors. After having looked at the

video I wonder if there is a ground problem that the antenna (the usb

cable) helps to sway a little so that it works again. It would be nice to

hear from a prusa engineer!-From my phone while mobile, please excuse any

errors.On 1 May 2024, at 13:57, HaWiWe @.***> wrote:

My friend said that that was the reason that I can't be an influencer: I

also find the bug to be really funny and interesting. He said to become an

influencer I would have had to make a 2-hour rant about it, namedropping

other companies that do it a lot better. :P

—Reply to this email directly, view it on GitHub, or unsubscribe.You are

receiving this because you commented.Message ID: @.***>

Reply to this email directly, view it on GitHub

https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2088377248,

or unsubscribe

https://github.com/notifications/unsubscribe-auth/AURA4JQPEDKRHKN5DV3IKG3ZADLPJAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBYGM3TOMRUHA

.

You are receiving this because you authored the thread.Message ID:

@.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

F1rst-Lay3r commented 5 months ago

I have a similar issue with 6.0.0 and a MMU3 on the MK4. Difference is that I think mine is not hardware related. When I revert to 6.0.0 RC2, the BSOD is gone. Re flashing to 6.0.0 and the BSOD is back. Sometimes I'm able to boot without a BSOD.

Also with 6.0.0 there are some random beeps now and then, that are also gone when I revert to 6.0.0 RC2.

For now I keep running on 6.0.0 RC2, without issues.

thadogg commented 5 months ago

Hello, Exact same problem here. The USB cable workaround worked perfectly. This is definitely a critical bug/defect...

F1rst-Lay3r commented 4 months ago

Ever since I reverted back to firmware 6.0.0 RC2, I was able to boot fine without any BSOD. Up untill today that is, today I could hardly boot at all. So I tried the 'unconnected' USB cable workaround and for now it's working.

fnordsh commented 4 months ago

I seem to have the same or a similar issue - for me a reliable workaround is to press and hold the MMU3's reset button until the bootup of the MK4 is finished. After that, everything works fine.

image

PS: I will test the "USB cable method" when my current print is finished. Edit: The USB cable method seems to work 9 out of 10 times.

fnordsh commented 4 months ago

Just a thought: Is there maybe a floating input somewhere that can, depending on the read value, delay or otherwise influence the MMU3 boot process?

m-cas commented 4 months ago

… or a ground imbalance or something like this. Definitely something that an HW engineer at Prusa shouldn‘t have problems at finding out what is is give how easy it is to reproduce and the three workarounds known to bypass it.-From my phone while mobile, please excuse any errors.On 27 May 2024, at 18:57, Fnord Prefect @.***> wrote: Just a thought: Is there maybe a floating input somewhere that can, depending on the read value, delay or otherwise influence the MMU3 boot process?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

sascape commented 4 months ago

I've had this problem since assembly over a month ago. I thought I had assembled the MMU incorrectly but I noticed that when I hold the MMU at a different angle in my hand during boot up, I have no problems. Once it is booted up, the printer and MMU work perfectly!

As soon as my current print finishes, I will try the cable trick. It would be very funny if this fix worked.

pars3cproton commented 4 months ago

The different angle thing is due to the mmu to printer cable, you’ll notice that even just touching that slightly where the plug is (mmu side) will make it boot. And yes, the cable trick works, I’m bsod free since someone here mentioned it!

On Tue, 28 May 2024 at 18:05, sascape @.***> wrote:

I've had this problem since assembly over a month ago. I thought I had assembled the MMU incorrectly but I noticed that when I hold the MMU at a different angle in my hand during boot up I have no problems. Once it is booted up the printer and MMU work perfectly!

As soon as my current print finishes, I will try the cable trick. It would be very funny if this fix worked.

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2135618515, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JXU6EJXJRSAOC5VHKTZESTMNAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVGYYTQNJRGU . You are receiving this because you authored the thread.Message ID: @.***>

sascape commented 4 months ago

Well, the cable seems to be in the right position right now (weirdly, I had the boot bug just a few hours ago). The printer boots up correctly every time I cut the power or reset. I don't want to push my luck and I will wait for the moment the bug reoccurs. Right now I need reliability. I'm happy to test around with the cables in 1-2 weeks when I have finished my time-sensitive projects.

tlachmann commented 4 months ago

Hi, having the same issue as descrided here, https://forum.prusa3d.com/forum/original-prusa-i3-mmu3-hardware-firmware-and-software-help/pd-board-issue-overcurrent-overvoltage/

After some more investigation, I assume that this is caused by the inrush current while the capacitors are charging. The LDO circut on the PD-board consumes also an inrush current at the same time. I´m not sure if it is possible to softstart the MMU 24 Volts Rail or to changing the time bias of the overcurrent detection. I assume that allowing the higher inrush current for additional 50µSec could help.

Greets Thorsten

tlachmann commented 4 months ago

yesterday I did some measurements.. my opinion, that issue is annoying...

But first: having a micro-USB cable plugged into the MMU, does not have quick-fix the behavior on my side, it still shows MMU Overcurrent

Now the annoying part, the measurements...

My assumption was then, that combining the three GND wires coming from MK4 to connect the single shunt has "fixed" the isssue. But I was also wrong, after bridging the 2mOhms shunt, the issue was back again, persistantly, removing the bridge, results that the issue was gone... So for me it seems, that even the 0,002 Ohms resistor limits the inrush current on the 24Volts sufficiently...

But I did also some measurements of the inrush current in the working environment.

I measured a peak current up to 25A at the moment when the 24V is switched on. the time period above 10A is approx 1.8 to 2mSec. Then the current reduces quickly below 0.5A

See attachd screeners.

PD-Board-current - 1 PD-Board-current - 2

m-cas commented 4 months ago

Good work! So your hypothesis is that the usb cable plugged-in leading nowhere is fixing the problem (for a few at least) because it acts like a little capacitor changing the inrush?What about the ‘bend things a little’ that seem to work for others? Is that consistent with your observations?Now on the permanent solution: board changes (long time to fix) or an adapter containing some passive components (faster)?-From my phone while mobile, please excuse any errors.On 4 Jun 2024, at 17:31, Thorsten Lachmann @.***> wrote: yesterday I did some measurements.. my opinion, that issue is annoying... But first: having a micro-USB cable plugged into the MMU, does not have quick-fix the behavior on my side, it still shows MMU Overcurrent Now the annoying part, the measurements...

On my side, the Overcurrent issue is persistant, so if i want to boot the MK4 with mmu in factory default setup, no chance, always the Overcurrent notice.

Once I prepared for the current measurement, cut the three GND wires from MK4 to MMU approx 5 cm to the PD-Board and put a 2mOhms Measurement shunt in beetween which has the effect, that the Issue is gone, no longer a overcurrent failure, of course , the shunt has only 0.002 Ohms...

My assumption was then, that combining the three GND wires coming from MK4 to connect the single shunt has "fixed" the isssue. But I was also wrong, after bridging the 2mOhms shunt, the issue was back again, persistantly, removing the bridge, results that the issue was gone... So for me it seems, that even the 0,002 Ohms resistor limits the inrush current on the 24Volts sufficiently... But I did also some measurements of the inrush current in the working environment. I measured a peak current up to 52A at the moment when the 24V is switched on. the time period above 10A is approx 1.8 to 2mSec. Then the current reduces quickly below 0.5A See attachd screeners. PD-Board-current.-.1.jpeg (view on web) PD-Board-current.-.2.jpeg (view on web)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

tlachmann commented 4 months ago

I don't know which influence the USB cable from scientific side has. in the schematic of PCB version 0.3 the ID pin of the microUSB cable isn't connected, normaly the ID Pin controls switching from USB Slave to OTG. If it would be connected to MCU and maybe the cable has that pin grounded, then I could imagine. For me the USB cable is more or less a esotherik thing.

image

But even the fact, that the difference of an 0.002 Ohms Resistor (some cables has higher resistance) fixes the behavior on my side, is also not explainable, at least not at that tiny value.

On the other hand, I´m sure that a resistor between 1 and 1.4 Ohms on the 24 Volts Input of the PD-Board could act as a current limiter. On the other side, this value shuldn´t also not have a influence to the Stepper functionality.

Greets Thorsten

tschaerni commented 4 months ago

I don't know which influence the USB cable from scientific side has. in the schematic of PCB version 0.3 the ID pin of the microUSB cable isn't connected, normaly the ID Pin controls switching from USB Slave to OTG. If it would be connected to MCU and maybe the cable has that pin grounded, then I could imagine. For me the USB cable is more or less a esotherik thing.

Maybe it adds a tiny amount of capacitance (which every cable has), or it just applies some pressure to the board, which would cause the same as some people have experienced (including myself) with putting small amount of pressure to the board.

Kinda a shame that the MMU3 seems to work really well, but is plagued by such a weird hardware bug.

IIRC, adding a capacitance could limit the inrush current, so a small value choke might be a better solution than a shunt resistor.

HaWiWe commented 4 months ago

For me the USB cable is more or less a esotherik thing.

I tried for a loooot of boots. So no, it is definitely not an esoteric thing but something that does work and does fix it for most of the people who have that bug even though there is no logical explanation for it. It don't find the bug too bad, rather curious. :D

pars3cproton commented 4 months ago

But in all of this, did prusa aknowledge it or not?

On Tue, 4 Jun 2024 at 21:20, HaWiWe @.***> wrote:

For me the USB cable is more or less a esotherik thing.

I tried for a loooot of boots. So no, it is definitely not an esoteric thing but something that does work and does fix it for most of the people who have that bug even though there is no logical explanation for it. It don't find the bug too bad, rather curious. :D

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware-Buddy/issues/3947#issuecomment-2148235490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AURA4JUJF2CLUOOLQ4Y55HDZFYHOPAVCNFSM6AAAAABGVWVUZCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBYGIZTKNBZGA . You are receiving this because you authored the thread.Message ID: @.***>

fnordsh commented 4 months ago

Hi, having the same issue as descrided here, https://forum.prusa3d.com/forum/original-prusa-i3-mmu3-hardware-firmware-and-software-help/pd-board-issue-overcurrent-overvoltage/

Are you sure this is the same issue? I never got the overcurrent error, but I do get the BSOD on boot when I don't have the USB cable connected to the MMU3. Holding the MMU's reset button also helps.

"Esoteric" is a nice way to put it. ;-) In my experience, weird semi-deterministic bugs like this are often related to floating inputs. I'm sorry that I don't have much time to investigate further right now, but I would first check if all MCU input pins are initialized properly, with pullups except where they are explicitly not needed.

Next thing to try would be adding a few seconds of delay in the MMU's boot process. (Based on the observation that holding the MMU's reset until the MK4 has finished booting works reliably for me.) Not sure if I would classify that as fix or rather as a workaround, though. ;-)

HaWiWe commented 4 months ago

Yes, for every new MMU update I have a short conversation with the support, telling them it's still there and him confirming that they are still looking for the reason.

tlachmann commented 4 months ago

If the open USB cable would add capacitiy, then it also need to be charged on boot, which would worse the issue.

electrically that usb cable represents a antenna and maybe it acts like that and disturbes the MCU on boot which adds a delay.

tschaerni commented 4 months ago

If the open USB cable would add capacitiy, then it also need to be charged on boot, which would worse the issue.

electrically that usb cable represents a antenna and maybe it acts like that and disturbes the MCU on boot which adds a delay.

A crap, I meant inductance, not capacitance, that would lower the in rush current.

Yes, for every new MMU update I have a short conversation with the support, telling them it's still there and him confirming that they are still looking for the reason.

I'm also gonna get a replacement board in a few days, it'll probably be unresolved, but they asked me to send my board back so they can investigate it.

tlachmann commented 4 months ago

Hi, having the same issue as descrided here, https://forum.prusa3d.com/forum/original-prusa-i3-mmu3-hardware-firmware-and-software-help/pd-board-issue-overcurrent-overvoltage/

Are you sure this is the same issue? I never got the overcurrent error, but I do get the BSOD on boot when I don't have the USB cable connected to the MMU3. Holding the MMU's reset button also helps.

"Esoteric" is a nice way to put it. ;-) In my experience, weird semi-deterministic bugs like this are often related to floating inputs. I'm sorry that I don't have much time to investigate further right now, but I would first check if all MCU input pins are initialized properly, with pullups except where they are explicitly not needed.

Next thing to try would be adding a few seconds of delay in the MMU's boot process. (Based on the observation that holding the MMU's reset until the MK4 has finished booting works reliably for me.) Not sure if I would classify that as fix or rather as a workaround, though. ;-)

regardless of the message BSOD/Overcurrent notice, the symptoms looks identical, so my assumption is that both has the same cause.

Subtle3D commented 4 months ago

Had the MMU3 overcurrent issue happen on 2 MK4s.

What led to it: It worked fine on during install and firmware updates. MMU prints would work but on starting a print it kept saying there was filament detected and needed to unload before being able to assign tools. It would ask for filament type, heat up and unload (nothing) then go to the filament selection page. Up to this point the filament sensor reading always reported off.

In the settings menu, disabling the filament sensor also disabled the MMU. Reenabling the sensor, then reenabling the MMU caused an instant reboot into MMU overcurrent.

Multiple reboots, unplugging replugging MMU, changing MMU sheep board, changing PD board, booting with each plug for steppers and Pinda sensor unplugged one at a time, caused no change. Booting without the MMU plugged in allowed the MK4 to boot, then plugging in the MMU and enabling it in setting again caused reboot to MMU overcurrent.

"Fix" The USB cable plugged in "trick" stated above, allowed everything to boot normally and the MMU works for both of the printers (so weird). Don't know how or if the filament sensor issue plays into this but the filament issue that led to this no longer exists on these printers either.

If the current spike on boot is non-damaging, then an interim fix until a proper hardware (if that's the issue) fix might be a firmware change to disable or increase the overcurrent detection limit for the first few seconds during MMU booting.

Subtle3D commented 4 months ago

Addition to my previous post.

I have several other MK4's with MMU3's that also had the filament detection issue on MMU3 install and disabling/enabling the filament sensor and MMU in the settings page stopped the detection issue and did Not cause an MMU overcurrent. (Definition of insanity? Same actions different results :)

tlachmann commented 4 months ago

Today I had a chance to measure current when the MMU overcurrent error appers, and compared to my previous non-error measurements, I can´t measure an overcurrent. in my previous measurement an peak overcurrent upt to 25A (for a very little time) happens, now the printer detected an overcurrent, while only 10,10A was reached (yellow line 20,20mV/2mOhms Shunt = 10,10A) , and switched off the 24 V Supply when it reached only 12-13V (blue line)

I think now it seems it is a wrong positive interpretation in the software.

99F5CE39-D8CE-480D-ABBC-CB6BED99799E_1_102_o

tlachmann commented 4 months ago

I spend some time to take a brief view into the code, and found that normally the MMU is "soft" powered up with a pulsed power-up procedure. But I didn´t see anything that looks like a pulsed power-up procedure.. So it seems that the issue is really software based and the pulsing didn´t happen, or it happens but the electronic isn´t able to execute, what I think is more realisitc.

Because in the code the voltage will be switched on for 5µSec and off for 70µSec, this repeats for 15000µSec. But the problem is, the voltage needs under none fault condition approx 1000µSec to rise from 0 to only 5 Volts, 3500µ secounds from 0-24Volts.... that wouldn`t work.

Source: https://github.com/prusa3d/Prusa-Firmware-Buddy/blob/b1b77f69574daa16b57e7361bc469ea14daa57e4/src/mmu2/mmu2_power.cpp#L20

using namespace buddy::hw;

// The code below pulse-charges the MMU capacitors, as the current inrush
// would due to an inferior HW design cause overcurrent on the xBuddy board.
// In case overcurrent would still be triggered, increase the us_total
// value to pre-charge longer.
static constexpr uint32_t us_high = 5;
static constexpr uint32_t us_low = 70;
static constexpr uint32_t us_total = 15000;
  if (!config.can_power_up_mmu_without_pulses()) {
      CriticalSection critical_section;

      for (uint32_t i = 0; i < us_total; i += (us_high + us_low)) {
          {
              buddy::DisableInterrupts disable_interrupts;
              MMUEnable.write(Pin::State::high);
              delay_us_precise<us_high>();
              MMUEnable.write(Pin::State::low);
          }
          delay_us(us_low);
      }
  }

  MMUEnable.write(Pin::State::high);