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

Get Help
1

serial.log (8.5 KB) octoprint.log (203.0 KB)

Hello, I have the Prusa MK2.5S MMU2S.

Prusa recently came out with a firmware update 3.8.0 (prusa3d_fw_MK25S_3_8_0_2684_RAMBo13a_en-fr.hex) which I flashed fresh directly from the Prusa Slicer following their instructions. I am able to print directly from SD normally when no Raspberry Pi is plugged in.

I took a fresh SD card with my Pi3 and flashed the latest OctoPi 1.3.11 using Etcher as instructed and used the update feature to make sure it's the latest. I did not install any plugins. I am plugged into my printer with a USB cable, and have replaced and retried various cables for both the power and USB connection to the printer. OctoPrint in safe mode experiences the same issue.

When I press "Print" from the OctoPrint interface my printer almost immediately resets itself the same as if I pressed the "X" button on the panel.

Here is what happens as I press Print on a model that prints fine when initiated from the printer directly when the Pi is not plugged in:

2019-09-19 02:00:20,274 - Changing monitoring state from "Operational" to "Starting"
2019-09-19 02:00:20,330 - Send: N0 M110 N0*125
2019-09-19 02:00:20,359 - Recv: ok
2019-09-19 02:00:20,362 - Changing monitoring state from "Starting" to "Printing"
2019-09-19 02:00:20,371 - Send: N1 M73 P0 R254*23
2019-09-19 02:00:20,385 - Recv: NORMAL MODE: Percent done: 0; print time remaining in mins: 254
2019-09-19 02:00:20,389 - Recv: SILENT MODE: Percent done: 255; print time remaining in mins: -1
2019-09-19 02:00:20,390 - Recv: ok
2019-09-19 02:00:20,393 - Send: N2 M201 X9000 Y9000 Z500 E10000*56
2019-09-19 02:00:20,401 - Recv: ok
2019-09-19 02:00:20,404 - Send: N3 M203 X500 Y500 Z12 E120*15
2019-09-19 02:00:20,413 - Recv: ok
2019-09-19 02:00:20,416 - Send: N4 M204 P2000 R1500 T2000*83
2019-09-19 02:00:20,426 - Recv: ok
2019-09-19 02:00:20,429 - Send: N5 M205 X10.00 Y10.00 Z0.20 E2.50*58
2019-09-19 02:00:20,437 - Recv: ok
2019-09-19 02:00:20,440 - Send: N6 M205 S0 T0*37
2019-09-19 02:00:20,446 - Recv: ok
2019-09-19 02:00:20,449 - Send: N7 M107*34
2019-09-19 02:00:20,454 - Recv: ok
2019-09-19 02:00:20,457 - Send: N8 M862.3 P "MK2.5SMMU2S"*34
2019-09-19 02:00:20,467 - Recv: ok
2019-09-19 02:00:20,470 - Send: N9 M115 U3.7.2*108
2019-09-19 02:00:20,475 - Recv: ok
2019-09-19 02:00:20,477 - Send: N10 G90*33
2019-09-19 02:00:20,482 - Recv: ok
2019-09-19 02:00:20,485 - Send: N11 M83*40
2019-09-19 02:00:20,492 - Recv: ok
2019-09-19 02:00:20,496 - Send: N12 M104 S215*80
2019-09-19 02:00:20,503 - Recv: ok
2019-09-19 02:00:20,506 - Send: N13 M140 S60*97
2019-09-19 02:00:20,512 - Recv: ok
2019-09-19 02:00:20,515 - Send: Tx
2019-09-19 02:00:20,518 - Send: N14 M190 S60*107
2019-09-19 02:00:21,758 - Recv: start
2019-09-19 02:00:21,761 - Printer sent 'start' while printing. External reset? Aborting job since printer lost state.
2019-09-19 02:00:21,786 - Send: N0 M110 N0*125
2019-09-19 02:00:21,795 - Changing monitoring state from "Printing" to "Cancelling"
2019-09-19 02:00:21,941 - Recv: echo: 3.8.0-2684
2019-09-19 02:00:21,944 - Recv: echo: Last Updated: Sep  6 2019 19:51:28 | Author: (none, default config)
2019-09-19 02:00:21,948 - Recv: Compiled: Sep  6 2019
2019-09-19 02:00:21,951 - Recv: echo: Free Memory: 2276  PlannerBufferBytes: 1392
2019-09-19 02:00:21,954 - Recv: echo:Stored settings retrieved
2019-09-19 02:00:21,956 - Recv: adc_init
2019-09-19 02:00:22,125 - Recv: FSensor ENABLED
2019-09-19 02:00:22,134 - Recv: echo:SD card ok
2019-09-19 02:00:22,896 - Recv: ok
2019-09-19 02:00:22,904 - Send: N0 M110 N0*125
2019-09-19 02:00:22,906 - Recv: MMU => 'start'
2019-09-19 02:00:22,908 - Recv: MMU <= 'S1'
2019-09-19 02:00:22,920 - Recv: ok
2019-09-19 02:00:22,923 - Send: N1 M108*43
2019-09-19 02:00:22,929 - Recv: Unknown M code: $1 M108
2019-09-19 02:00:22,930 - Recv: ok
2019-09-19 02:00:22,932 - Send: N2 M84*29
2019-09-19 02:00:22,937 - Recv: ok
2019-09-19 02:00:22,939 - Send: N3 M104 T0 S0*34
2019-09-19 02:00:22,944 - Recv: ok
2019-09-19 02:00:22,947 - Send: N4 M140 S0*97
2019-09-19 02:00:22,953 - Recv: ok

The strange part to me is that when I start a print from the printer itself, with OctoPrint running but without using its interface to initiate the print, the same reset occurs.

I also ran sudo apt-get update and sudo apt-get upgrade then restarted but the same issue is occuring, even though many libraries seemed to update themselves. I also happen to have another Pi3 which I tried by swapping the SD card, with no change.

I don't know if it's worth noting, but the previous Prusa firmware was also causing me problems which I logged as an issue here: https://github.com/prusa3d/Prusa-Firmware/issues/1974

Before my MMU I was printing non-stop with OctoPrint so I don't believe there are any fundamental compatibility issues with my Rambo board as a whole.

Thank you for any insight you can provide me on this "Printer restarts when print initiated while OctoPi connected" issue. I don't know what I'm going to do without OctoPrint!

1 Like
2

That one looks odd. Is it supposed to be literally Tx instead of e.g. T0 or T1?

3

The reset of the MMU2 is quite usual.
It is like homing of the printer itself. When the MMU is in an unknown condition, it is forced back to the initial positions to make sure everything is ok.
I have the same here and got quite familiar with it.

4

The reset of the MMU2 is quite usual.
It is like homing of the printer itself. When the MMU is in an unknown condition, it is forced back to the initial positions to make sure everything is ok.
I have the same here and got quite familiar with it.

As you notice, it also happens when you print from SD card. So it belongs to behaviour of the printer, not OctoPrint

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.