Octoprint is sending m112 to my prusa mk3s+ with MMU2 after recent prusa firmware update

foosel · March 8, 2022, 2:45pm

Please share another system info bundle. ~~Did you also restart OctoPrint and reconnect?~~ Never mind, you said you rebooted

leesmithsworkshop · March 8, 2022, 2:51pm

I connected again and this time it will print.

Recv: T:254.90 E:0 B:109.9
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N62 M105*19
Recv: LCD status changed
Recv: ok
Send: N63 M109 S255*95
Recv: Full RX Buffer
Recv: ok
Recv: ok T:255.2 /255.0 B:110.0 /110.0 T0:255.2 /255.0 @:39 B@:81 P:0.0 A:35.3
Send: N64 G28 W*86
Recv: Error:Line Number is not Last Line Number+1, Last Line: 18
Recv: Resend: 19
Recv: ok
Send: N19 M105*31
Recv: Error:Line Number is not Last Line Number+1, Last Line: 18
Recv: Resend: 19
Recv: ok
Recv: ok T:255.2 /255.0 B:110.0 /110.0 T0:255.2 /255.0 @:39 B@:81 P:0.0 A:35.3
Send: N20 M105*21
Recv: ok T:255.2 /255.0 B:110.0 /110.0 T0:255.2 /255.0 @:39 B@:81 P:0.0 A:35.3
[octoprint-systeminfo-20220308145050.zip|attachment](upload://mhDy6dkWZTpaItnLxglp2l8IZHM.zip) (67.0 KB)

foosel · March 8, 2022, 2:52pm

Still complains about a full rx buffer however, so something still is not right. Please share another system info bundle. The truncated serial.log sadly tells me nothing as everything relevant happens before your excerpt there.

Also see

github.com/prusa3d/Prusa-Firmware

M112 After heating up

opened 05:19AM - 29 Dec 21 UTC

sarf2k4

bug

**Printer type** - [e.g. MK3S, MK3, MK2.5S, MK2.5, MK2S, MK2] MK3S **Printer firmware version** - [e.g. 3.8.1, 3.8.1-RC1, ...] 3.10.1-4697 **MMU upgrade** - [e.g. MMU2S, MMU2, MMU1] MMU2S **MMU upgrade firmware version** - [e.g. 1.0.6, 1.0.6-RC2, ...] 1.0.6-372 **SD card or USB/Octoprint** Octoprint Via USB **Describe the bug** After heating up the hotend to the target temp, M112 suddenly called out **To Reproduce** It randomly came at the exact same g-code location, but not 60-100% will be able to reproduce **Expected behavior** No M112 Issued? **G-code** Here is my g-code where the M112 often occurred commented below. Yes, this is the start g-code, I only changed S180 instead of the stock settings, the rest are stock g-code from prusa ``` M862.3 P "[printer_model]" ; printer model check M862.1 P[nozzle_diameter] ; nozzle diameter check M115 U3.10.0 ; tell printer latest fw version G90 ; use absolute coordinates M83 ; extruder relative mode M104 S180 ; set extruder temp M140 S[first_layer_bed_temperature] ; set bed temp Tx M190 S[first_layer_bed_temperature] ; wait for bed temp M109 S[first_layer_temperature] ; wait for extruder temp //My M112 issues always at this point, after the M109 above <=============== G28 W ; home all without mesh bed level G80 ; mesh bed leveling ;go outside print area G1 Y-3 F1000 G1 Z0.4 F1000 ; select extruder Tc ; purge line G1 X55 F2000 G1 Z0.3 F1000 G92 E0 G1 X240 E25 F2200 G1 Y-2 F1000 G1 X55 E25 F1400 G1 Z0.2 F1000 G1 X5 E4 F1000 M221 S{if layer_height<0.075}100{else}95{endif} G92 E0 ; Don't change E values below. Excessive value can damage the printer. {if print_settings_id=~/.*(DETAIL @MK3|QUALITY @MK3).*/}M907 E430 ; set extruder motor current{endif} {if print_settings_id=~/.*(SPEED @MK3|DRAFT @MK3).*/}M907 E538 ; set extruder motor current{endif} ``` Following is from the terminal on the Octoprint's web interface on where the M112 occurred. ``` LCD status changed ok Full RX Buffer N72 M109 S230*92 LCD status changed ok N73 G28 W*80 N74 G80*34 Error:Line Number is not Last Line Number+1, Last Line: 18 Resend: 19 M112 N75 M112*19 N76 M104 T0 S0*16 N77 M104 T1 S0*16 N78 M104 T2 S0*28 N79 M104 T3 S0*28 N80 M104 T4 S0*29 N81 M140 S0*92 ``` **Video** Don't think I could reproduce this very easily **Additional Note** I checked several other 'similar' issues, it might be my thermistor started to acting up due to its age or something, but I could be wrong. As of this writing, previous print job goes without any M112 issued, and I reconnected the octoprint again, start the print job, no M112 issued

leesmithsworkshop · March 8, 2022, 2:52pm

octoprint-systeminfo-20220308145050.zip (67.0 KB)
sorry I attached it in the text block

foosel · March 8, 2022, 2:54pm

It's still sending Tx without line number and check sum, same for Tc. So something about the changes didn't take at all.

leesmithsworkshop · March 8, 2022, 2:57pm

I logged on with ssh and edited the file as your post says and saved before rebooting.

leesmithsworkshop · March 8, 2022, 3:02pm

it didn't remember the changes so I have tried again, saved the file and loaded it back in to be sure.

foosel · March 8, 2022, 3:05pm

You've set serial.timeout.sendChecksumWithUnknownCommands and serial.timeout.unknownCommandsNeedAck to true. That's not what was posted in the linked comment or how it looked in the example

Try this instead, via SSH as well:

~/oprint/bin/octoprint config set --bool serial.sendChecksumWithUnknownCommands true
~/oprint/bin/octoprint config set --bool serial.unknownCommandsNeedAck true

Should hopefully be less error prone.

leesmithsworkshop · March 8, 2022, 3:11pm

Oh I put them in timeout: my mistake

leesmithsworkshop · March 8, 2022, 4:05pm

HI, are these commands reset after a reboot and this is the correct command to view it
sudo nano ~/.octoprint/config.yaml

I am not seeing them after the a reboot and it didn't help. I know how to get around the problem, just pre heat the bed and nozzle first then I am not seeing any errors.

leesmithsworkshop · March 8, 2022, 4:15pm

and I am seeing this problem more today because I am printing in asa and it takes a long time to warm up.

foosel · March 8, 2022, 5:17pm

Try the config statements I told you to use and for the love of all that is holy don't use sudo for editing a user readable config file. sudo usually isn't needed and just blindly slapping it in front of commands can break stuff.

And yes, this should persist a reboot.

leesmithsworkshop · March 8, 2022, 5:29pm

sorry I don't know much about these operating systems so it's not always easy for me to understand what I should be doing.
I did enter them as you requested and removed my mistakes, but it made no change. I had to carry on printing so have not had chance to try anything again.

foosel · March 8, 2022, 5:32pm

If it keeps reverting after a reboot then something might also be up with your file system. That's out of OctoPrint's control though. In general I was told by Prusa that these settings should be fixing the issue, which is rooted in the firmware not being able to handle getting Tx or Tc pushed "out of order" so to speak. OctoPrint has always been doing this unless the above settings were set to true, but something in the latest firmware caused this to now lead to a cascade of errors in communication which in the end results in an M112 and disconnect.

If you can't get the settings to work, I suggest to roll back the firmware update for now and then wait for OctoPrint 1.8.0.

leesmithsworkshop · March 8, 2022, 6:22pm

This is after the config statements

leesmithsworkshop · March 8, 2022, 6:25pm

and after a reboot they are missing so I will look into this problem.

Charlie_Powell · March 8, 2022, 6:33pm

What are you doing to close and save the file? What key combinations?

leesmithsworkshop · March 8, 2022, 6:34pm

ctrl O to write and ctrl X to exit. if I load the file back in the values are in the saved file.

leesmithsworkshop · March 10, 2022, 10:02am

Just thought I would add that since I started pre heating I am not having the problem so I will continue to do this. I have not had time to look at why it will not remember those changes and think I will just make a new sd install and try that.

system · June 8, 2022, 10:03am

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.