After the printer heats up and is about to start the bed probe octoprint is seeing some error and sending m112. it's mainly the first print after power up and then will be ok for the rest of the day.
Send: N159 G80*28
Recv: Error:Line Number is not Last Line Number+1, Last Line: 18
Recv: Resend: 19
Should resend line 19 but no sufficient history is available, can't resend
Changing monitoring state from "Printing" to "Error"
Send: M112
Send: N160 M112*38
Send: N161 M104 T0 S0*39
Send: N162 M140 S0*96
Changing monitoring state from "Error" to "Offline after error"
Connection closed, closing down monitor
Closing down send loop
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyACM0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6ed74390, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
1.7.3, Version 0.18.0, running on Raspberry Pi 3 Model B Rev 1.2, Prusa Mk3s+ with MMU2s, prusa3d_fw_3_10_1_MK3S_1_0_6_MMU2S, chrome, windows 10, ... as much data as possible
I added those two lines, rebooted the pi and prusa and tried the same gcode from the first print today and it gave the comminucations errors and then stopped just after it reached the correct temps.
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: N143 M105*33
Recv: T:255.52 E:0 B:110.0
Recv: LCD status changed
Recv: ok
Recv: Full RX Buffer
Send: N144 M109 S255*107
Recv: ok
Send: N145 G28 W*100
Recv: ok T:254.5 /255.0 B:110.0 /110.0 T0:254.5 /255.0 @:51 B@:82 P:0.0 A:34.1
Send: N146 G80*18
Recv: Error:Line Number is not Last Line Number+1, Last Line: 18
Recv: Resend: 19
Should resend line 19 but no sufficient history is available, can't resend
Changing monitoring state from "Printing" to "Error"
Send: M112
Send: N147 M112*35
Send: N148 M104 T0 S0*44
Send: N149 M140 S0*105
Changing monitoring state from "Error" to "Offline after error"
Connection closed, closing down monitor
Closing down send loop
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)
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.
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
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.
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.
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.
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.
