Prusa MK2.5S MMU2S restarts when print initiated while OctoPi is connected

Get Help
5

It doesn't happen when I print from SD card, it happens when I print from SD card and OctoPrint is connected.

I am able to print when the USB cable is plugged in but while not "Connected" through OctoPrint. That said, I am not in total disagreement that it's not something to do with my printer, which is why I've come here with the hope that others may have a similar issue and we can get to the bottom of what's going on together.

The reset occurs right as the print is requested whether or not I print a model requiring multiple colours, though that's probably not a helpful thing to mention considering the MMU is connected and feeding the filament regardless, even if it's only one.

I have since tried other electrical plugs in my house in case it's a power thing, no change.

Next I would like to think of a way to connect something "communicating" with the printer over USB with the Pi but not OctoPrint, to see if I can isolate if it's a data connection in general causing it or the response from OctoPrint as a software. Does anyone have any thoughts on how I can "listen" without responding to the messages sent by the printer whatsoever?

Either way, thanks for taking the time to read and think about my issue here.

6

Let me repeat that question.

Also something to check: serial.log of a print initiated through the controller while OctoPrint is connected. Maybe there's an overlap that helps identify what's happening.

7

serial.log (41.0 KB)

Oh yes good idea to compare. Here I have attached the log for a print started from the printer's interface (file lives on printer's SD card), and after it failed/reset the printer I started the print again from OctoPrint. Hopefully that shows them side-by-side a bit easier.

The "Tx" command from what I've learned is the command used when the MMU is asking the user to select a filament for a single-colour print. In all of my tests, I have been manually clicking on the screen "Filament 1" which is a normal step. It's either before or right after that selection when the restart occurs, so maybe you're onto something there. That said, a multi-colour print with explicit T0, T1, etc. where the user is not asked to select which filament, still resets the printer right after the point in the log saying "Recv: start, Printer sent 'start' while printing..."

This afternoon when I get home I am going to replace the SD card to a completely new one and do a full reinstall of OctoPi again just in case there's something funky there (I replaced the Pi, cables, power, but not the SD card itself so it's the final thing to swap for all avenues on the Pi hardware side). This feels unlikely though because the Pi has no obvious interruption in its functioning and it's a high speed 32GiB micro card.

And I'm still interested in finding some way to 'listen' from a software other than OctoPrint so we can nail down if it's just that I have something connected and engaging the USB port or software related to OctoPrint/OctoPi communicating/doing something we're missing.

8

Could it be similar to this issue?

Because it seems like the MMU is doing startup stuff, OctoPrint thinks the print is in progress, then it actually "starts" and OctoPrint gets confused? Then OctoPrint disconnects and reconnects and whenever this happens my printer restarts.

My printer has always "rebooted" when I click the "Connect" button on OctoPrint, so perhaps the reboot itself is just a byproduct of OctoPrint disconnecting and reconnecting again?

I'll keep at it, but I wonder if there's a way to tell OctoPrint to ignore all "start" commands? Could I just have it continue normally even if it sees that command come in?

9

When OctoPrint sees a start, it doesn't reconnect, it simply assumes that the printer did a reset (because start should only ever be sent as first message after a reset). OctoPrint isn't resetting the printer when it sees start, OctoPrint sees start because something reset the printer.

The question is why is the printer resetting in the first place.

What I find also interesting is that the printer stopped responding altogether here:

2019-09-19 14:15:11,426 - Send: M105
2019-09-19 14:15:40,501 - Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2019-09-19 14:15:40,513 - Send: M27
2019-09-19 14:16:10,521 - Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2019-09-19 14:16:10,528 - Send: M105
2019-09-19 14:16:40,536 - No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

Nothing that I see in the log that gets sent from OctoPrint to the printer should trigger a restart, and I also don't see any proof that it does a serial reconnect.

From the looks of the log the printer simply restarts right around heatup during the start of a print.

Experiment: Create a MMU GCODE file but remove the temperature commands. On a stock Marlin you could even set it to dry-run mode so it doesn't try to extrude with M111 S8 (same to disable) but I have no idea whether Prusa has that in their firmware - the joy of forks.

Another experiment: Remove anything but the start code from a file known to trigger the issue and see if you still reproduce. Keep removing lines until you no longer reproduce.

The only thing you'll be able to listen in without implementing the whole protocol (not a lot of fun) would be the messages generated out-of-line by the firmware, but still, might be worth a try. You want to take a look at any serial terminal, e.g. picocom or Putty or something, and simply connect to the serial port at the baudrate OctoPrint also gets a successful connection with (115200 most likely).

10

Well now Gina, you are onto something with this temperature thing!

I did as you suggested and removed the temperature set lines from the gcode and sure enough the print starts as expected.

In fact, when OctoPrint is connected and I click "Preheat" from the printer itself, the reset occurs even when no print is started.

And here is the log for when I use OctoPrint to set the nozzle to 215 and bed to 60. Again the printer restarts. serial.log (5.0 KB)

The M140 S60 "set bed temp" command causes the reboot, and M190 S60 "wait for bed temp" both individually cause the reboot when either is left in the code. Furthermore, after removing those lines and my print had started, I used the menu to turn on the head bed and it immediately rebooted.

I'm a bit perplexed at how to solve this now though, clearly it's an issue with the power management on my printer related to the heat bed but only when OctoPrint is running?

Anyway thank you for your troubleshooting steps thus far, I guess it's something to bring up with Prusa but I fear there's no way they're going to be able to help beyond agreeing with what we've determined here together.

11

It only happens when OctoPrint is connected, not when just the USB is plugged in? Because otherwise I'd suggest some form of power leak through the USB cable.

Another alternative that I've seen with a printer from a different vendor could be too much going on in some interrupt handlers, causing stuff to get out of sync if serial communication is also involved. The case where I observed that before only caused an epic ton of communication issues since the serial could not be fed properly due to some floating point math within a heater interrupt handler, but I don't know, maybe it could also cause a reset if some watchdog triggers. That would definitely be a firmware issue then though.

It would be interesting to know if other people with an MMU observe similar issues with that firmware or if yours is an isolated case. The former would indicate a firmware bug, the latter an issue with your printer.

Might be worth a shot to downgrade to another firmware version.

@Ewald_Ikemann was it you who also has an MMU? What firmware are you using with it and does everything work?

12

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

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.

14

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.

15

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.

16

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

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
18

You may re-flash the firmware of printer and MMU. Sure, there is a check after the upload, but one never knows.

19

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)

20

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

21

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
22

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.

  1. 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.
  2. 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.
  3. 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!

23

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

24

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.