Prusa-firmware: 3.4.0-RC1 Firmware for Prusa i3 MK3 M600 filament change causes reset

[TimothyGold]

Issue identified with 3.4.0-RC1 Firmware for Prusa i3 MK3. I added M600 to do a color change that works just fine in the last stable release. When the M600 is reached the filament change is triggered but when when the last command is sent to continue the print the controller resets and destroys the print.

[Tech-outreach]

I have the same result. Prusa MK2.5

[dalgibbard]

Printing from SD or Octoprint? Possibly related to #1043

[derjungewilde]

same issue here. tried several time and every time the mk3 resets after filament change

[Phydam]

I ran the same gcode from SD card and Octoprint. From the SD card the filament change was fine and the print completed. From Octoprint the filament change failed as others have experienced. I rolled back to the last stable FW release and was able to do the color change from SD card and octoprint without issue.

[Phydam]

I ran the test again from Octoprint and captured the following from the console in Octoprint:

Recv: echo:busy: paused for user
...
Recv: echo:busy: paused for user
Recv: echo:busy: processing
...
Recv: echo:busy: processing
Recv: start
Printer sent 'start' while printing. External reset? Aborting job since printer lost state.
Send: N0 M110 N0125
Changing monitoring state from "Printing" to "Cancelling"
Recv: start
Recv: echo: 3.4.0-RC1-1170
Recv: echo: Last Updated: Aug 13 2018 15:23:38 | Author: (none, default config)
Recv: Compiled: Aug 13 2018
Recv: echo: Free Memory: 1929 PlannerBufferBytes: 1392
Recv: echo:Hardcoded Default Settings Loaded
Recv: adc_init
Recv: CrashDetect ENABLED!
Recv: PAT9125_RES_X=0
Recv: PAT9125_RES_Y=240
Recv: PAT9125_init:1
Recv: FSensor DISABLED
Recv:
Recv: echo:SD card ok
Recv: Error:No Line Number with checksum, Last Line: 0
Recv: Resend: 1
Send: N0 M110 N0125
Recv: ok
Send: N1 M113 S296
Recv: ok
Send: N2 M8429
Recv: ok
Send: N3 M117 35% L=-/-90
Recv: ok
Recv: ok
Send: N4 M117 Print Done81
Recv: ok
Send: N5 M117 Print Done80
Send: N6 M117 35% L=-/-95
Recv: ok
Recv: ok
Send: N7 M117 Print Done82
Send: N8 M117 Print Done93
Recv: ok
Send: N9 M104 T0 S040
Recv: ok
Send: N10 M140 S084
Recv: ok
Send: N11 M106 S0*87
Recv: ok
Recv: ok
Changing monitoring state from "Cancelling" to "Operational"
Send: M105
Recv: ok T:239.5 /0.0 B:60.1 /0.0 T0:239.5 /0.0 @:0 B@:0 P:33.6 A:31.7
....

[dalgibbard]

I wonder if this is related to what I saw when crash detection occured, the printer paused and waited for me to agree to continue, and then when I continued, octoprint had lost contact with the printer, resulting in an inability to continue. Some sort of timeout issue/lack of keepalive messages perhaps?

[jettoblack]

Same thing just happened to me. Lost a 10 hour print near the end. :(

Printing with 3.4.0-RC1 and Octoprint, a false filament runout was detected. I selected "Yes" to unload the filament, then when prompted selected "Yes" that the filament had unloaded successfully. When re-inserting the filament, the printer rebooted. Maybe due to this message?

Recv: fsensor_oq_meassure_stop, 114 samples
Recv: st_sum=20495 yd_sum=341 er_sum=2 er_max=1
Recv: yd_min=1 yd_max=8 yd_avg=2 sh_avg=5
Recv: fsensor_oq_result
Recv: er_sum = 2 OK
Recv: er_max = 1 OK
Recv: yd_avg = 2 OK
Recv: yd_max = 8 OK
Recv: yd_min = 1 OK
Recv: yd_dev = 7
Recv: yd_qua = 2
Recv: sh_avg = 5 OK
Recv: fsensor_oq_result OK
Recv: start
Printer sent 'start' while printing. External reset? Aborting job since printer lost state.

Here is the last part of the Octoprint log. Sorry for the bad paste, don't know what happened here.

ecv: fsensor_autoload_check_start - autoload ENABLEDRecv: Recv: echo:busy: paused for userRecv: echo:busy: paused for userRecv: echo:busy: paused for userRecv: echo:busy: paused for userRecv: echo:busy: paused for userRecv: echo:busy: paused for userRecv: fsensor_autoload_check_stop - autoload DISABLEDRecv: Recv: fsensor_oq_meassure_startRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: echo:busy: processingRecv: fsensor_oq_meassure_stop, 114 samplesRecv: st_sum=20495 yd_sum=341 er_sum=2 er_max=1Recv: yd_min=1 yd_max=8 yd_avg=2 sh_avg=5Recv: fsensor_oq_resultRecv: er_sum = 2 OKRecv: er_max = 1 OKRecv: yd_avg = 2 OKRecv: yd_max = 8 OKRecv: yd_min = 1 OKRecv: yd_dev = 7Recv: yd_qua = 2Recv: sh_avg = 5 OKRecv: fsensor_oq_result OKRecv: startPrinter sent 'start' while printing. External reset? Aborting job since printer lost state.Changing monitoring state from 'Printing' to 'Operational'Send: M84Recv: startPrinter sent 'start' while already operational. External reset? Resetting line numbers to be on the safe sideRecv: echo: 3.4.0-RC1-1170Recv: echo: Last Updated: Aug 13 2018 15:23:38 | Author: (none, default config)Recv: Compiled: Aug 13 2018Recv: echo: Free Memory: 1929 PlannerBufferBytes: 1392Recv: echo:Hardcoded Default Settings LoadedRecv: adc_initRecv: CrashDetect ENABLED!Recv: PAT9125_RES_X=0Recv: PAT9125_RES_Y=240Recv: PAT9125_init:1Recv: PAT9125_RES_X=0Recv: PAT9125_RES_Y=240Recv: PAT9125_init:1Recv: FSensor ENABLEDRecv: echo:SD card okRecv: echo:Unknown command: "84"(2)Recv: okSend: M104 T0 S0Recv: fsensor_autoload_check_start - autoload ENABLEDRecv: Recv: ok

[PavelSindler]

We are currently working on it. Unfortunately we haven't fixed it yet, as we were busy with multimaterial v2, but it has the highest priority now and it will be fixed in final 3.4.0 release.

[PavelSindler]

Fixed in PR https://github.com/prusa3d/Prusa-Firmware/pull/1092.