[BUG] SKR Mini E3 1.2, prints from SD don't finish correctly with Octoprint or Pronterface connected

[RedOctobyr]

Description

SKR Mini E3 1.2 board. If I print from the SD card, with Octoprint or Pronterface in Connected state (not just plugged-in), prints do not finish correctly.

When finished, the filename on the screen keeps scrolling, Octoprint will show the status as 99% (not 100%), and I cannot start another print from the LCD. I select the file, confirm Print, and nothing happens.

Steps to Reproduce

Required: Please include a ZIP file containing your Configuration.h and Configuration_adv.h files. Marlin issue 11-27-19.zip

1. Boot up printer.
2. Connect Octoprint or Pronterface via the USB cable. Just having the cable plugged in won't cause it. They need to be in a connected state.
3. Print a job from the SD card. I typically do this using the LCD, but printing from SD using Octoprint also seems to cause the issue.
4. When the print job finishes, the filename continues scrolling at the bottom of the LCD. If Octoprint is connected, it will show the status as 99%, not 100%. And if I try to print another job, using the LCD, I can't. I select the file, select Print, and nothing happens. Octoprint seems to sort of lose control, after the job finishes like this, I can't use Octoprint to turn the heats on.

Printing as "streaming" from Octoprint (using gcode uploaded internally to Octoprint) is OK.

Expected behavior: [What you expect to happen] Should finish prints normally.

Actual behavior: [What actually happens] Finishes in a state where I cannot print another job.

Additional Information

I'm using Marlin 2.0.x that I downloaded 11-23-19.

I get the same behavior using the precompiled "firmware-bltouch-for-z-homing.bin" file from BigTreeTech, here: https://github.com/bigtreetech/BIGTREETECH-SKR-mini-E3/tree/master/firmware/V1.2

This makes me think the issue is not with how I'm configuring & compiling the firmware.

Octoprint is running on a Raspberry Pi, Pronterface is on my laptop, so 2 different connected devices cause the issue. I usually have the +5V pin covered in the USB cable, but have tried it with that uncovered as well. Prints work normally with either device just plugged in (but not actually Connected), and printing from the SD card.

[danym21]

can you please check, do you have G91 in the end script from the print? I have a issue that when this is in, the machine wait for a click to resume print. I have not figured out yet why.

edit: please forget the G91 I have removed this part and now he stops earlier.

[RedOctobyr]

I do have a G91 in my Cura End GCode.

Interestingly, when I first tried Marlin 2.0 with this board, a week prior, using firmware configured by two different Github users (when you had to use PlatformIO 4.0.3, not 4.1.0), I had different symptoms. At the end of a print, the heats would stay on, and the nozzle would remain on the part, in the last location it was printing. It wouldn't "park" the nozzle off the bed.

Part of what was strange to me was that it seemed to "crash" right at the end of the print. There was a command to retract the extruder, and then it was supposed to turn the heats off. Somehow the heats weren't getting turned off, something about that end code seemed to make things hang.

Now, it's better. The heats turn off, and the nozzle "parks" itself. But other problems remain.

[looxonline]

I had the exact same problem with the heaters staying on but it is intermittent. Using code from early October so I suppose it is time to upgrade.

[boelle]

@RedOctobyr will you open a new issue for the other problems?

[RedOctobyr]

I wasn't planning to, should I? I'm new at this. By the other problems, are you referring to when it was keeping the nozzle & bed heats on at the end of a print, and keeping the nozzle positioned on the part?

That happened when I was using firmware configured on GitHub by two different users, and they may have updated their setups since then. I think I'd downloaded them on 11/17. And when I downloaded Marlin 2.0.x directly myself on 11/23, it had the issues described in my initial post. Fortunately, the heats no longer remain turned on, and the nozzle parks itself properly.

That's the most recent copy that I've tried. I have not yet attempted to try updating my firmware with the latest release. I'm new at this, including how to properly use GitHub to update my copy in Visual Studio Code. I understand there's a way to have VSC combine new files with the changes that I'd previously made myself, but I haven't explored this yet.

[boelle]

I just saw you write this:

f. But other problems remain.

[RedOctobyr]

I see, sorry, I should have been clearer. The "other problems" I was referring to are what's described in the first post.

Previously, it did those, as well as keeping the nozzle and bed heats on at the end of the print, as well as leaving the nozzle at the last-printed position on the part.

Now, with the firmware I downloaded 11/23, it's just the stuff described in the first post.

[boelle]

@RedOctobyr since 2.0 was just released a few days ago has this changed this issue at all?

[RedOctobyr]

I downloaded the current 2.0 this morning, made my edits, and compiled it.

I only had a chance to do a single print today, but that one actually finished properly, with Octoprint connected. I will get to try it some more tomorrow, but this is encouraging.

[RedOctobyr]

Unfortunately, in a few prints today, sometimes they have finished correctly.

And other times they've behaved like I described in previous posts. Except now it's also keeping the nozzle and bed heats on, and keeping the nozzle positioned on the part, when it finishes the print. And I can't start another print. It had previously kept the heats on, and the nozzle positioned on the part, when it finished, using firmware set up by other users. But the newer bugfix version I downloaded 11/23/19 did not do that.

These are with Octoprint connected.

[looxonline]

I can confirm that this is still happening, even with the latest build. I'm trying to test various scenarios and this is still just a theory but it seems as if when I apply USB power first and then turn on the main PSU that is when it will freeze at the end of the print with the heaters still on. Will need to perform many more prints to confirm 100%.

[RedOctobyr]

Thank you for sharing your results. I have the +5V USB pin covered, so my Pi cannot power the main board. And I can still have problems printing.

It typically happens, for me, when printing from the SD card, but with Octoprint (or Pronterface) Connected to the printer (not just plugged in). If I have the cable plugged-in, but have not Connected Octoprint, things are OK.

But it doesn't seem to have the problem every time, using the most-recent version of Marlin 2.0 that I downloaded on Dec 7.

[looxonline]

100% the same issues I experience. I print from SD for quality reasons but monitor using octoprint. Sometimes it will complete the print, park the heads and turn off the heaters. Other times it will complete the print, not park the head, turn off the heaters but be unusable until a power cycle. Other times it will not park the head, leave the heaters on and respond to nothing over the USB serial interface.

[boelle]

@RedOctobyr is the issue still the same with all the updates in the last 5 days?

[boelle]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

[looxonline]

btw, who can confirm there is an issue? use the same configs as OP and the same hardware if possible

I can confirm that I have exactly the same issues as the op using the V1.0 SKR E3 Mini. Also printing from SD but using Octoprint to monitor. Really dangerous as I've come to find my bed and hotend on and parked mid way through the final G-code several times hours and hours after the print should have completed.

[pistifonok]

100% the same issues I experience. I print from SD for quality reasons but monitor using octoprint. Sometimes it will complete the print, park the heads and turn off the heaters. Other times it will complete the print, not park the head, turn off the heaters but be unusable until a power cycle. Other times it will not park the head, leave the heaters on and respond to nothing over the USB serial interface.

i have exactly the same issue with my CR-10S but using the SKR 1.3 board. Im using the latest bugfix-2.0.x

[tomash]

Confirming same issue.

Ender 3 with SKR Mini E3 v.1.2, ordered on October 2019, so installed without any additional firmware flashing (youtuber Teaching Tech has flashing instructions due to deficiencies in older revisions' firmware). Octoprint v. 1.3.12, running on Raspberry Pi 3, stock set of plugins.

Printing from SD card via Octoprint. The print is finished, header parked up, bed slid forward, temperatures reset, there is still connection with the printer and temperature status messages are received by Octoprint:

Recv: T:20.62 /0.00 B:20.62 /0.00 @:0 B@:0

But the progress is stuck at 99% and making another print requires power cycling. This also blocks the camera timelapse from being rendered.

Attaching screenshot of the situation. Are there logs I could provide to help nail down the problem?

[tatusah]

I would judge against this being a bug. Tried both Octoprint 1.3.12 and 1.4RC3 with SKR e3 mini v1.2 printing and finishing just fine from onboard SD card through Octoprint. Running Marlin bugfix last time compiled with yesterdays commits. Could anyone of the ones having problems upload configurations?

[sjasonsmith]

Could anyone of the ones having problems upload configurations?

Posting the sliced gcode might be helpful as well. There may be commands at the end of the file causing it to delay for a long time, or wait for a temperature that will never be reached, etc.

[tomash]

The same gcode printed fine on the same stack with stock Ender 3 mainboard (some Marlin 1.x).

Here's the gcode file with which I had the last occurence of this -- I dare to say -- bug: https://filedn.com/l59TRkaeyBJ7dEitRt1dELV/api_sb_top_v3_6h30_028magic.gcode (top of case for atomic pi sbc)

There are also some connection inconsistencies after upgrading to SKR Mini mainboard, sometimes after a print (that ended successfully because printed straight from Octoprint, not from SD) there was a series of connection timeouts that required reconnecting or doing a full restart of Octoprint machine.

[looxonline]

I would judge against this being a bug. Tried both Octoprint 1.3.12 and 1.4RC3 with SKR e3 mini v1.2 printing and finishing just fine from onboard SD card through Octoprint. Running Marlin bugfix last time compiled with yesterdays commits. Could anyone of the ones having problems upload configurations?

The problem is that this does not happen consistently. I can print the same gcode 10 times and on the 11th time it will happen. I've physically watched the head freeze in the middle of the final gcode movement command and just sit there with the heaters still enabled indefinitely. Other times the final movement will complete but the heaters will stay on. Other times the final movement will complete, the heaters will turn off but the printer will be completely unresponsive to any commands that you give it until a restart. There is definitely something fishy going on. No smoke without a fire.

[Dracrius]

@tatusah This is 100% a marlin bug! I just built a build for my new skr mini e3 1.2 from Marlin 2.0.1 release and it had two major issues! Firstly MIN_PROBE_EDGE was totally janked luckily I found that fix and applied it manually but this is 10x worse. It kinda bothers me some are trying to claim its not a bug. It took me 2min to find multiple post on different site siting the same issue. As stated it is intermittent but EVERY post I've read has two thing in common they are printing from SD while connected to Octoprint and "The printer freezes during end code". Now with it being that consistent you can not tell me it is not a bug.

I have been testing it after it happens a few times. I tested with 3 different g codes, at 3 different print lengths, 2 times each and had 2 failures. From 10min - 6hr every failure/freeze even previous ones happens only during end code, one during a 10min print the other just now at the end of 6hr while I was at work for another 2hrs. Unfortunately my terminal was clear by the time I made it to check what line it failed at to see if it was consistent. It appears to successfully disable my stepper motors but nothing else as the head stay at the end position melting a blob into the model but the same gcode doesn't always fail.

My End Gcode for Comparison

M140 S0
M107
; Ender 3 Custom End G-code
G4 ; Wait
M220 S100 ; Reset Speed factor override percentage to default (100%)
M221 S100 ; Reset Extrude factor override percentage to default (100%)
G91 ; Set coordinates to relative
G1 F1800 E-3 ; Retract filament 3 mm to prevent oozing
G1 F3000 Z20 ; Move Z Axis up 20 mm to allow filament ooze freely
G90 ; Set coordinates to absolute
G1 X0 Y235 F1000 ; Move Heat Bed to the front for easy print removal
M84 ; Disable stepper motors
; End of custom end GCode
M82 ;absolute extrusion mode
M104 S0
;End of Gcode
;SETTING_3 {"extruder_quality": ["[general]\\nversion = 4\\nname = FDG 0.4mm Noz
;SETTING_3 zle - Terrain v4\\ndefinition = creality_legacy_ender3\\n\\n[metadata
;SETTING_3 ]\\ntype = quality_changes\\nquality_type = draft\\nsetting_version =
;SETTING_3  9\\nposition = 0\\n\\n[values]\\nacceleration_travel = 1000\\ncool_f
;SETTING_3 an_full_at_height = 0.4\\ncool_min_layer_time = 7\\ncool_min_speed = 
;SETTING_3 2\\ninfill_pattern = grid\\ninfill_sparse_density = 5\\njerk_layer_0 
;SETTING_3 = 10\\njerk_print = 15\\nmaterial_final_print_temperature = 195\\nmat
;SETTING_3 erial_flow = 100\\nmaterial_initial_print_temperature = 195\\nmateria
;SETTING_3 l_print_temperature = 195\\nretraction_amount = 4\\nroofing_layer_cou
;SETTING_3 nt = 2\\nskin_line_width = 0.4\\nskin_preshrink = 0.9\\nspeed_wall_0 
;SETTING_3 = 25\\ntop_bottom_pattern = lines\\ntop_bottom_thickness = 0.8\\ntop_
;SETTING_3 thickness = 1\\ntravel_compensate_overlapping_walls_enabled = False\\
;SETTING_3 nwall_thickness = 0.8\\n\\n"], "global_quality": "[general]\\nversion
;SETTING_3  = 4\\nname = FDG 0.4mm Nozzle - Terrain v4\\ndefinition = creality_l
;SETTING_3 egacy_ender3\\n\\n[metadata]\\ntype = quality_changes\\nquality_type 
;SETTING_3 = draft\\nsetting_version = 9\\n\\n[values]\\nacceleration_enabled = 
;SETTING_3 False\\njerk_enabled = False\\nmaterial_bed_temperature = 60\\nretrac
;SETTING_3 tion_combing = infill\\n\\n"}

M140 S0
M107
; Ender 3 Custom End G-code
G4 ; Wait
M220 S100 ; Reset Speed factor override percentage to default (100%)
M221 S100 ; Reset Extrude factor override percentage to default (100%)
G91 ; Set coordinates to relative
G1 F1800 E-3 ; Retract filament 3 mm to prevent oozing
G1 F3000 Z20 ; Move Z Axis up 20 mm to allow filament ooze freely
G90 ; Set coordinates to absolute
G1 X0 Y235 F1000 ; Move Heat Bed to the front for easy print removal
M84 ; Disable stepper motors
; End of custom end GCode
M82 ;absolute extrusion mode
M104 S0
;End of Gcode
;SETTING_3 {"extruder_quality": ["[general]\\nversion = 4\\nname = FDG 0.4mm Noz
;SETTING_3 zle - Terrain v4\\ndefinition = creality_legacy_ender3\\n\\n[metadata
;SETTING_3 ]\\ntype = quality_changes\\nquality_type = draft\\nsetting_version =
;SETTING_3  9\\nposition = 0\\n\\n[values]\\nacceleration_travel = 1000\\ncool_f
;SETTING_3 an_full_at_height = 0.4\\ncool_min_layer_time = 7\\ncool_min_speed = 
;SETTING_3 2\\ninfill_pattern = grid\\ninfill_sparse_density = 5\\njerk_layer_0 
;SETTING_3 = 10\\njerk_print = 15\\nmaterial_final_print_temperature = 195\\nmat
;SETTING_3 erial_flow = 100\\nmaterial_initial_print_temperature = 195\\nmateria
;SETTING_3 l_print_temperature = 195\\nretraction_amount = 4\\nroofing_layer_cou
;SETTING_3 nt = 2\\nskin_line_width = 0.4\\nskin_preshrink = 0.9\\nspeed_wall_0 
;SETTING_3 = 25\\ntop_bottom_pattern = lines\\ntop_bottom_thickness = 0.8\\ntop_
;SETTING_3 thickness = 1\\ntravel_compensate_overlapping_walls_enabled = False\\
;SETTING_3 nwall_thickness = 0.8\\n\\n"], "global_quality": "[general]\\nversion
;SETTING_3  = 4\\nname = FDG 0.4mm Nozzle - Terrain v4\\ndefinition = creality_l
;SETTING_3 egacy_ender3\\n\\n[metadata]\\ntype = quality_changes\\nquality_type 
;SETTING_3 = draft\\nsetting_version = 9\\n\\n[values]\\nacceleration_enabled = 
;SETTING_3 False\\njerk_enabled = False\\nmaterial_bed_temperature = 60\\nretrac
;SETTING_3 tion_combing = infill\\n\\n"}

[tatusah]

If it's more consistent then it is at least helpful in trying to investigate this. Would you @Dracrius send the configs so that I can mirror your setup. Personally I have done adjustments to the Marlin buffer settings and also using the modified 512K environment with the control board.

If custom end G-code processing is stopping at the point where steppers are disabled I'd at least recommend moving M104 S0 before the M84 in the end code to increase the chances that the hotend gets disabled.

This is my custom end G-code for reference, it's a bit customized version of Cura default end code for Ender 3:

M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed

G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positionning

G1 X0 Y200 ;Present print

M117 Print Completed
M300 S440 P200 ; Make Print Completed Tones
M300 S660 P250
M300 S880 P300

M106 S0 ;Turn-off fan

M501 ; drop unwanted custom settings
M84 X Y E ;Disable all steppers but Z

Perhaps it's worth testing if this end code behaves any different. Haven't seen problems with this so far with the Octoprint on Pi 3 B+. I can try the end code from the previous post.

[ManuelMcLure]

@tatusah Slightly unrelated, but the M104/M140 ends up being executed out of order with the movements in the buffer, so your end code has the possibility of executing the last few moves/extrusions with the heaters turned off which could end up causing a jam. You should put an M400 before the M104 so that all movements are complete before turning off the heaters.

[tatusah]

Thanks for the tip @ManuelMcLure. I'll adjust the code.

[Dracrius]

@tatusah The move away from the print and to present the bed in my end gcode should fire off before the stepper motors are disable but the print freezes with the head in contact with the model every time so its skipping most of the end gcode except the M84 and then freezing or at least thats how it seems so I dont see moving it helping but I can try moving the M104 S0. Here are my Config files Configs.zip

[tomash]

What seems to be consistent (for me) is that such hangup ends up messing with printer communication. Sometimes it's shown in Octoprint terminal, see pasted lines from log below. Sometimes after that the connection is oficially lost and Octoprint prompts to reconnect (which is good because it also triggers rendering timelapse). Sometimes there's no error sign other than stalled 99% progress and the printer's own control interface (screen + rotary encoder) being able to move the header but unable to auto-home (!).

Aforementioned last entries in terminal:

Recv: SD printing byte 3077077/3077093
Recv: ok
Send: M27
Send: M105
Send: M27
Send: M27
Send: M27
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: M27
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.
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.

[Loafdude]

I believe this may be the same issue I discovered independently here https://github.com/MarlinFirmware/Marlin/issues/16509

Are you guys using the STM32F103RC_bigtree_512K or STM32F103RC_bigtree_512K_USB enviroment? Can you test using the non_USB version as it fixes my freezing issues. I was also able to get the printer to respond again by disconnecting and reconnecting serial on windows pronterface. I am also able to consistently reproduce my problem using PID autotune sequence.

[RedOctobyr]

I use the _512K version. That's interesting about the autotune sequence causing similar issues. If nothing else, a way to cause (or test for) what may be the problem, without needing to actually print stuff, is interesting.

I've had the problem on long (hours) and short (10 minutes) prints, the duration doesn't seem to be important.

I don't think I've tried explicitly telling Octoprint to Disconnect after the printer kind of freezes, to see if the printer starts responding again.

Merely as a matter of curiosity, I've wondered what it is about the end sequence that causes a problem. Why does it always happen then, never (for me) in the middle of a print? Especially since sometimes the nozzle stays parked on the part. Maybe it's the issuing of a temperature-change command, after doing a bunch of print stuff, that confuses things? I don't remember if my normal Cura code shuts off the heats before or after moving the nozzle away from the part. I guess I could comment-out the last temperature changes, for instance, and see if it suddenly finished OK.

(My apologies for not following up with answers to some questions myself. I have not updated to the latest Marlin. I'm new at this, and need to figure out how to pull the latest version in VSC, since I understand it can then go line-by-line and let you decide whether to keep the individual edits you'd made. That sounds easier than making all my edits again, from scratch, onto a fresh copy of the files. If there's a link to a guide for updating yourself to the latest Marlin in VSC, I'd appreciate it. But I do not want to side-track this discussion.)

[thisiskeithb]

I'm wondering if emulated EEPROM has anything to do with these issues. Do these problems go away with FLASH_EEPROM_EMULATION disabled? You'll have to use an SD card with an eeprom.dat file on it to test.

[Loafdude]

I disabled emulated EEPROM (confirmed EEPROM.DAT now exists on SD) but still get freezing when running M303 S240 C10. I cannot speak for these end-of-print failures.

[Vertabreak]

being connected to any USB interface like octoprint ect with attempting to print from SD card will results in a large number of problems just don't do it. the connected USB interface thinks your trying to print with it and doesn't understand the SD card is in use.

[tatusah]

Definitely interesting case. I haven't yet had any problems with either the end of the print or pid tuning through Octoprint. I still have to do some cross testing with different configurations. One difference I seem to have compared to @Dracrius configuration is that I have ADVANCED_OK and AUTOREPORT_SD_STATUS enabled. I enabled those initially because it improved the functionality of my touch screen and as it's connected also through serial (the TFT port) it might also be the reason why I haven't seen problems with Octoprint either. So maybe I'll disable those and see if it will invoke the errors.

[Loafdude]

@tatusah Do you use STM32F103RC_bigtree_512K or STM32F103RC_bigtree_512K_USB? Any chance you would be willing to flash my configuration or share yours so I can test my config.

I suspect the serial port code or a resource conflict is freezing the system. The fact I can 'unfreeze' the system by initialising a new connection to the serial port implies the serial init routine is restarting the trouble code or freeing the resource and reallocating it which then unfreezes the system.

If anyone experiencing this "end-of-print freeze" issue can recreate and test to see if disconnect/reconnect serial port releases the freeze that would be very helpful to see if this is the same problem as #16509

@Vertabreak I'm speechless. Your saying Merlin cannot reliably TX serial traffic while printing from SD and that doing so may cause Merlin to freeze?

[tatusah]

Yes, 512K_USB since that environment was included in Marlin. @Loafdude you have SERIAL_PORT and SERIAL_PORT_2 settings the other way around compared to my and Bigtreetech config in Marlin example configs.

[Loafdude]

I have tried all of these. I have also decreased baud rate with no effect.

define SERIAL_PORT -1

define SERIAL_PORT_2 2

define SERIAL_PORT 2

define SERIAL_PORT_2 -1

define SERIAL_PORT -1

//#define SERIAL_PORT_2 2

Any chance getting a copy of your configs?

[tatusah]

Yeah, I'm not sure if it makes that much of a difference but something I noticed. Here is mine, if you want to check them. Take note that I have custom settings for adjusting bed zero and limits for probing so probably you shouldn't compile and flash these straight without making adjustments.

Marlin_ender3_custom.zip

[Loafdude]

Awesome, Thanks! I actually don't have to move anything to do a PID autotune so it should be ok but I will review.

[tatusah]

Oh, and it also has PIDTEMPBED enabled.

[Loafdude]

No Go. I did PID autotune (M303 S240 C10) via pronterface and still get freezing No modifications to the config.

This is based on bugfix-2.0.x? Maybe I'll try dev-2.1.x

Edit-- Also tried disconnecting LCD screen but no difference.

[thisiskeithb]

Maybe I'll try dev-2.1.x

bugfix-2.0.x is more up to date than that branch.

[Loafdude]

@tatusah Can you compile and post a fw.bin? I just want to see if something is different in my environment. If mine still fails after that do you mind sending a pid autotune manually? M303 S240 C10?

[boelle]

@RedOctobyr do you still have a problem or do you just need help?

[Dracrius]

@boelle this is still an active problem! Only thing i print from sd is test prints but if octoprint is connected SD prints often lockup during end gcode. Ignoring most of the end code skipping to disable motors which is almost the last command and freezes with a heated head in the last position of the print!

[Loafdude]

Dracrius, While frozen, if you disconnect from serial and reconnect does the system unfreeze? This could still be related to #16509

[RedOctobyr]

@RedOctobyr do you still have a problem or do you just need help?

I believe I still have the problem. But I apologize, I have not yet sat down to figure out how I pull in the latest Marlin code in VSC, to see if the behavior still exists for me.

Based on what other people are reporting, I'd expect the problem will still be there, but I have not confirmed that yet.

[looxonline]

Dracrius, While frozen, if you disconnect from serial and reconnect does the system unfreeze? This could still be related to #16509

I experienced the same issue. The system is so frozen that nothing seems to bring it back to life. Physically removing the USB and replacing it does not work nor does disconnecting in software and reconnecting. The reconnect in Octoprint does not work so I'm assuming it's not getting some serial handshake it's expecting. If you try to send commands to turn the heaters off when its frozen it will ignore them. It even ignores an emergency stop.

[Loafdude]

Ok thanks @looxonline , I still believe there is an issue with the SKR and switching between tasks. Something is taking all the resources from the main program loop. I notice slow responses in the UI while the machine is moving and during UBL. The only thing I've seen interrupt my freezing problem is the runaway protection. Perhaps they are setup as watchdogs / interrupts which bypass the main program loop.

[tomash]

Dracrius, While frozen, if you disconnect from serial and reconnect does the system unfreeze? This could still be related to #16509

Reconnection, even when working, does not result in zeroing the print status. And the printer's rotary encoder interface allows for manually moving on all the axis, manipulating the temperature etc. but does not allow for auto-home (nothing happens after running auto home).