@foosel: I have 3.8.0-2684 for the MK2.5S and 1.0.6-372 for the MMU2S and everything is fine.
Just a homing of the MMU2S from time to time, usually when I abort a print.
1 Like
Just started a new single filament print: No reset of the printer just homing the MMU2S after a fresh start of the printer. Filament loaded as expected and now heating up.
Thanks for checking @Ewald_Ikemann, I do feel reassured about the firmware considering you have the exact setup.
Yes @foosel it only happens when OctoPrint is connected but not when the USB is connected to the powered Pi with OctoPrint "disconnected." Funny you mention communication, after all my tests I was able to find quite a few cases of Recv: USART2 rx Full!!! whatever that means.
Here's one excerpt where it happened:
2019-09-20 00:06:56,493 - Send: M105
2019-09-20 00:06:56,503 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:26.7
2019-09-20 00:06:58,006 - Recv: MMU => 'start'
2019-09-20 00:06:58,009 - Recv: MMU <= 'S1'
2019-09-20 00:07:00,107 - Recv: start
2019-09-20 00:07:00,109 - Printer sent 'start' while already operational. External reset? Resetting line numbers to be on the safe side
2019-09-20 00:07:00,126 - Send: N0 M110 N0*125
2019-09-20 00:07:00,133 - Recv: echo: 3.8.0-2684
2019-09-20 00:07:00,134 - Recv: echo: Last Updated: Sep 6 2019 19:51:28 | Author: (none, default config)
2019-09-20 00:07:00,137 - Recv: Compiled: Sep 6 2019
2019-09-20 00:07:00,139 - Recv: echo: Free Memory: 2276 PlannerBufferBytes: 1392
2019-09-20 00:07:00,143 - Recv: echo:Stored settings retrieved
2019-09-20 00:07:00,146 - Recv: adc_init
2019-09-20 00:07:00,472 - Recv: FSensor ENABLED
2019-09-20 00:07:00,484 - Recv: echo:SD card ok
2019-09-20 00:07:01,720 - Recv: ok
2019-09-20 00:07:01,724 - Send: N0 M110 N0*125
2019-09-20 00:07:01,747 - Recv: ok
2019-09-20 00:07:01,749 - Send: M113 S2
2019-09-20 00:07:01,753 - Recv: ok
2019-09-20 00:07:01,756 - Send: M105
2019-09-20 00:07:01,765 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:113.6
2019-09-20 00:07:06,498 - Send: M105
2019-09-20 00:07:06,510 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:26.2
2019-09-20 00:07:07,628 - Recv: MMU => 'start'
2019-09-20 00:07:07,634 - Recv: MMU <= 'S1'
2019-09-20 00:07:10,528 - Recv: start
2019-09-20 00:07:10,530 - Printer sent 'start' while already operational. External reset? Resetting line numbers to be on the safe side
2019-09-20 00:07:10,541 - Send: N0 M110 N0*125
2019-09-20 00:07:10,551 - Recv: echo: 3.8.0-2684
2019-09-20 00:07:10,554 - Recv: echo: Last Updated: Sep 6 2019 19:51:28 | Author: (none, default config)
2019-09-20 00:07:10,557 - Recv: Compiled: Sep 6 2019
2019-09-20 00:07:10,559 - Recv: echo: Free Memory: 2276 PlannerBufferBytes: 1392
2019-09-20 00:07:10,561 - Recv: echo:Stored settings retrieved
2019-09-20 00:07:10,564 - Recv: adc_init
2019-09-20 00:07:10,896 - Recv: FSensor ENABLED
2019-09-20 00:07:10,908 - Recv: echo:SD card ok
2019-09-20 00:07:12,146 - Recv: ok
2019-09-20 00:07:12,150 - Send: N0 M110 N0*125
2019-09-20 00:07:12,171 - Recv: ok
2019-09-20 00:07:12,174 - Send: M113 S2
2019-09-20 00:07:12,178 - Recv: ok
2019-09-20 00:07:12,181 - Send: M105
2019-09-20 00:07:12,190 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:113.5
2019-09-20 00:07:13,011 - Recv: USART2 rx Full!!!
2019-09-20 00:07:13,012 - Recv: USART2 rx Full!!!
2019-09-20 00:07:13,038 - Recv: USART2 rx Full!!!
2019-09-20 00:07:16,500 - Send: M105
2019-09-20 00:07:16,514 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:26.6
2019-09-20 00:07:21,502 - Send: M105
2019-09-20 00:07:21,517 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:07:26,503 - Send: M105
2019-09-20 00:07:26,520 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:07:31,504 - Send: M105
2019-09-20 00:07:31,521 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:07:36,506 - Send: M105
2019-09-20 00:07:36,522 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:07:40,551 - Recv: MMU not responding - DISABLED
2019-09-20 00:07:41,508 - Send: M105
2019-09-20 00:07:41,523 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:07:46,512 - Send: M105
2019-09-20 00:07:46,528 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.5
2019-09-20 00:07:51,516 - Send: M105
2019-09-20 00:07:51,534 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:07:56,518 - Send: M105
2019-09-20 00:07:56,535 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.5
2019-09-20 00:08:01,527 - Send: M105
2019-09-20 00:08:01,543 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.5
2019-09-20 00:08:06,531 - Send: M105
2019-09-20 00:08:06,546 - Recv: ok T:25.0 /0.0 B:25.0 /0.0 T0:25.0 /0.0 @:0 B@:0 P:25.6
2019-09-20 00:08:09,457 - Recv: start
2019-09-20 00:08:09,469 - Printer sent 'start' while already operational. External reset? Resetting line numbers to be on the safe side
2019-09-20 00:08:09,487 - Send: N0 M110 N0*125
2019-09-20 00:08:09,498 - Recv: echo: 3.8.0-2684
2019-09-20 00:08:09,501 - Recv: echo: Last Updated: Sep 6 2019 19:51:28 | Author: (none, default config)
2019-09-20 00:08:09,503 - Recv: Compiled: Sep 6 2019
2019-09-20 00:08:09,507 - Recv: echo: Free Memory: 2276 PlannerBufferBytes: 1392
2019-09-20 00:08:09,510 - Recv: echo:Stored settings retrieved
2019-09-20 00:08:09,514 - Recv: adc_init
2019-09-20 00:08:09,822 - Recv: FSensor ENABLED
2019-09-20 00:08:09,834 - Recv: echo:SD card ok
2019-09-20 00:08:11,071 - Recv: ok
2019-09-20 00:08:11,079 - Send: N0 M110 N0*125
2019-09-20 00:08:11,096 - Recv: ok
2019-09-20 00:08:11,101 - Send: M113 S2
2019-09-20 00:08:11,108 - Recv: ok
2019-09-20 00:08:11,533 - Send: M105
I downgraded to the previous firmware version 3.7.1 as you suggested, and again I'm back to the issue I mentioned before (https://github.com/prusa3d/Prusa-Firmware/issues/1974)
In this case my serial log has:
2019-09-20 16:15:30,420 - Recv: Unknown G code: G21
2019-09-20 16:15:32,587 - Recv: echo:busy: processing
2019-09-20 16:15:34,651 - Recv: echo:busy: processing
2019-09-20 16:15:36,830 - Recv: echo:busy: processing
2019-09-20 16:15:38,894 - Recv: echo:busy: processing
2019-09-20 16:15:40,664 - Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 44
2019-09-20 16:15:40,670 - Recv: SILENT MODE: Percent done: 255; print time remaining in mins: -1
2019-09-20 16:15:40,683 - Recv:
2019-09-20 16:15:40,685 - Recv: SD printing byte 1595/2509714
2019-09-20 16:15:40,688 - Recv: 00:03
2019-09-20 16:15:40,692 - Recv: ok
2019-09-20 16:15:40,696 - Send: M105
2019-09-20 16:15:44,334 - Recv: Unknown G code: G21
2019-09-20 16:15:46,464 - Recv: echo:busy: processing
2019-09-20 16:15:48,528 - Recv: echo:busy: processing
2019-09-20 16:15:50,592 - Recv: echo:busy: processing
2019-09-20 16:15:52,657 - Recv: echo:busy: processing
2019-09-20 16:15:54,721 - Recv: echo:busy: processing
2019-09-20 16:15:56,785 - Recv: echo:busy: processing
2019-09-20 16:15:58,231 - Recv: echo:Advance K=30.00
2019-09-20 16:15:58,239 - Recv: E/D=Auto
2019-09-20 16:15:58,272 - Recv: ok T:213.9 /215.0 B:60.3 /60.0 T0:213.9 /215.0 @:45 B@:14 P:31.1
2019-09-20 16:15:58,274 - Send: M27
2019-09-20 16:15:58,469 - Recv:
2019-09-20 16:15:58,471 - Recv: SD printing byte 2074/2509714
2019-09-20 16:15:58,475 - Recv: 00:04
2019-09-20 16:15:58,477 - Recv: ok
2019-09-20 16:15:58,481 - Send: M113 S2
2019-09-20 16:15:59,316 - Recv: ok
2019-09-20 16:15:59,329 - Send: M105
2019-09-20 16:16:00,898 - Recv: ok T:213.7 /215.0 B:60.2 /60.0 T0:213.7 /215.0 @:49 B@:31 P:31.3
2019-09-20 16:16:00,909 - Send: M27
2019-09-20 16:16:01,332 - Recv:
Maybe it's related to the "arduino-usbserial firmware" problem described in this issue comment: https://github.com/prusa3d/Prusa-Firmware/issues/1180#issuecomment-449777357
Anyway, clearly this is not OctoPrint's fault but I am very thankful for your help here. I wish there was a clearer answer but at this point I think I'm stuck figuring out how to flash new usbserial to the board and/or buying a new board from overseas. Of course I promise to report back if I come up with a solution, and if you have any other ideas in the meantime I'm all ears.
Thanks so much, even though mission failed.
If you're going to assemble your own printer then learning how to re-flash the printer's controller board is one of those skills you'll eventually need.
@ajwest: Do you also have this issue when you use Pronterface instead of OctoPrint?
You may consider there is a fault with the USB port section of the Rambo 1.3a board.
I'm also a bit concerned about this line in your first post:
2019-09-19 02:00:20,457 - Send: N8 M862.3 P "MK2.5SMMU2S"*34
This M862.3 command is a riddle to me. It also does not appear in the Prusa Gcode list.
1 Like
Yes, the issue occurs with Ponterface from my Windows computer too, great idea to check! Now I finally feel satisfied that it's definitely an issue with the board failing when it is connected to a USB device, giving some sort of communication overflow but only when heating the bed and connected to a USB/serial output stream.
2 Likes
You may re-flash the firmware of printer and MMU. Sure, there is a check after the upload, but one never knows.
Just wanted to chime in that I seem to be having a similar issue.
Last night I upgraded everything....
OctoPrint to Version 1.3.12rc3
Prusa MK3S to 3.8.0 (2684)
Prusa MMU2S to (1.0.6)
PrusaSlicer to 2.1.0
I only tried a quick print after the upgrade but my behavior is as follows:
Sliced object using MMU model but single color (Extruder2/Tool1).
Sent GCODE to OctoPrint
MK3S heats up
MK3S does 9 point calibration
Print head moves to home and goes right an inch... (where it usually waits for the MMU to load)
and resets like I hit the "X".
After the printer resets it starts all over again doing the calibration.
I will read some of the links above and do some troubleshooting my self but wanted you all to know someone else has a similar issue.
Todd (Tech-Rat)
@Ewald_Ikemann I reflashed MMU too on different computers using different cables and double checked the hash of the downloaded firmware.
@tech-rat Similar setup as me, but different Rambo board. I wonder though, could you try to remove the M140 and M190 commands from your Gcode to see if it gets past the heat bed steps? As described above, my issue is entirely related to operations relating to the heating.
That said, I don't even get to the calibration before my reset happens. But it's good to stay in touch because as I understand it, the firmware between 2.5S and 3S share a lot of the same updates, so we can still be suffering from the same genre of issue.
I am experiencing a similar problem with my I3mk3s MMU2s recently.
Printing from SD works (starting from the printer's panel)
Printing the identical gcode from Octoprint, the job starts, bed levelling runs through but after that the printer resets before loading the filament. When I preload the according filament to the nozzle before starting the print from Octoprint, job runs correctly.
This behaviour is new, everything worked fine before. Unfortunately I (yes, I know, stupid!) I can not circle this is completely as I did overlapping changes and upgrades in Printer Firmaware and Octoprint.
Prusa I3mk3s (upgraded from mk3) with MMU 2s (upgraded from MMU2)
Latest Firmware (3.8.0 and 1.0.6)
Octoprint 1.3.12rc3 on a RPi3
I already deactivated most Plugins in Octoprint, my planned next steps is to downgrade the Firmware of the Prusa and the MMU. Any other suggested steps?
Thanks
1 Like
JoKey - I have basically the exact setup you do, mk3s, mmu2s, and running Octoprint from RPi3. . . I spent close to a month trying to dial the thing in, with the restart after calibration preventing any prints from starting at all. At this point, after trying sooo many things, it is hard to nail down how I got it working, but I'll give it a shot in the hopes that it may help you or someone else who is close to throwing their MMU2 against a wall.
- I went through the individual filament length calibration for all 5 by going into the "secret" menu. There is a great vid on youtube about tips and tricks with the mmu2 that runs through this. The Prusa handbook mentions that this is unnecessary, but I think it helps a TON. I'm not sure why, but I feel like this step is what cleared up the restarts.
- I checked my FINDA at the selector, and I feel like if it is down too far, it can cause false positives or other issues, so I pulled it about 2 or three threads up after trapping filament, then another two threads or so. I think it's better to err on it being too high than too low.
- I double checked the extruder gear alignment, and also that the I/R sensor was showing filament. I had tried disabling that sensor to see if it helped, but it ended up causing more problems. I think the tension screw holding the idler door needs to be on the tighter side. I was afraid at first to go past "flush" with the screw head, but now I have it recessed a little.
I am running the latest firmware and software on the Prusa, on Octo, the MMU2s itself (don't forget that!) as well as making sure Prusa Slicer has the mk3S MMU2S showing as the printer. . . those s's are important! Hope you get printing again, good luck!
Hi @Madpauly!
So do you have a MMU2 or a MMU2S? For the MMU2S hat the IR sensor at the extruder, there is no need for a filament length calibration at all. I erased the values here and never had a problem. So the correct IR sensor adjustment is important.
To your second point: there is a modified selector at Thingiverse that drags down the steel ball at the FINDA with a magnet.
As a hint: The MK3S should have the correct heatbreak the one with the smaller diameter), but one never knows...
Thanks Ewald,
I have the MMU2S, so who knows, maybe while I was messing with filament calibration I bumped the I/R the right way to have it start working! It is true that the sensors are so important; correct adjustment helps loading and unloading issues too. I'll check out that selector mod - that should help with filament sensing up top.
I have an exciting update!
I was going through all my wiring again since my MMU2S upgrade. The MK2.5S has two plugs from the power supply, but the MMU2S board needs one too so they include a power splitter. The directions for the upgrade say:
Follow the cables from the PSU and unplug one connector from the RAMBo board (both are the same).
But the image shows arrows unplugging the power cable which happens to be the heat bed one. Naturally I followed that photo.
Since my reboot issue is directly related to when gcode commands turn on the heat bed (determined by @foosel), I decided to try swapping the splitter to the other (hot end) power port. This has completely solved my issue and I can now print with OctoPrint!
I guess there's some power situation with the heat bed when a bit of power is siphoned off for the MMU2S board. Plugging in the splitter to the hot end port does not appear to cause the same reboot issue.
@Ewald_Ikemann if you have a moment some day, would you mind checking if your MMU2S power splitter is plugged into the hot end or heat bed port? If it's in the hot end side, maybe you could swap it to the heat bed port for a try. That way we can see if it reproduces my original problem for you and we will be able to report this to Prusa support for them modify the upgrade directions. I don't feel comfortable saying for sure that they [Prusa] should explicitly recommend using the hot end side for the splitter without first having some corroborating evidence... and obviously I don't have another MK2.5S MMU2S or know anybody else with this exact setup so it might be nice to give it a whirl for the community.
I'm going to try downgrading to previous firmware temporarily to see if this was also what was causing my slightly different issue. Also I recognize that others have started using this thread as a rally point for their similar issues with MK3 so feel free to continue your discussion despite it being a different technical problem considering you don't need to use the splitter on that printer.
My deepest appreciation to everyone who participated in this troubleshooting adventure, I am so excited to be up and running again!
3 Likes
The same is for the MK3S Version. Tried it for 1 1/2 weeks to find your post and try it on the new board. Same result - it works now!!
1 Like
So after installing the new octoprint 1.3.12 I got the same restart failures again. In the moment it should start to print... the printer resets it self and stops completly. Can anyone confirm this failure?
Setup:
Raspi Pi 4, OctoPrint 1.3.12 - OctoPi 0.17.0
Prusa MK3S (3.8.0) + MMU2S (1.0.6)
Confirmed. After the upgrade to 1.3.12 I started seeing the reset when trying to load a filament. My setup is almost identical to yours (Pi 3B+ instead of Pi4).
I suspected a corrupted upgrade and re-flashed OctoPi, same result.
Thank you, your suggestion was spot on! Adjusted my printer configuration for multiple extruders and it's working again. Was this a change in 1.3.12? Also upgraded all my firmware along the path.
See the post with further information linked in the FAQ entry:
I've also put heads-up into the release announcement and change log, it's really recommended to at least give those a glance on updates 