Marlin: [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).

[RobPlk]

Sorry for google translate :)
Connected pc to the 3d printer in the terminal issuing the command "M23 file.gcode" then "M24" works fine.
The octoprint on terminals M23 and M24 also works well. Only issuing the command by the "Print" button suspends printing by 99%.

[Ideaforge738]

Do not use the 512K option with the SKR Mini E3 v1.2 boards that have the STM32F103RC chips installed. The chips are only 256K and you can easily create a firmware image that while it may appear to work , will cause odd issues that vary depending on what is enabled and the generated firmware size. Disabling EEPROM EMULATION doesn't solve this issue.
The 512K option is for the boards that shipped with STM32103RE chips.

[Loafdude]

@Ideaforge738 Have you done some independent research regarding this or are you basing this off the datasheet?
It has been well established that the STM32F103RC chips do have 512k flash available despite the datasheet saying otherwise.

[thisiskeithb]

It has been well established that the STM32F103RC chips do have 512k flash available despite the datasheet saying otherwise.

Yes, take a look at the original PR with some links to videos & other posts with more information on these chips actually having 512k available.

[looxonline]

Do not use the 512K option with the SKR Mini E3 v1.2 boards that have the STM32F103RC chips installed. The chips are only 256K and you can easily create a firmware image that while it may appear to work , will cause odd issues that vary depending on what is enabled and the generated firmware size. Disabling EEPROM EMULATION doesn't solve this issue.
The 512K option is for the boards that shipped with STM32103RE chips.

This is not the cause. I'm using the 256k env.

[Ideaforge738]

@Ideaforge738 Have you done some independent research regarding this or are you basing this off the datasheet?
It has been well established that the STM32F103RC chips do have 512k flash available despite the datasheet saying otherwise.

I have used the same chips on these and other boards ( I do embedded development) . You can verify the size by using a JTAG on the board but most people don't have that capability. I have yet to see a single reliable source say that they contain any more than what ST says that they do. and I have never seen one show up on a JTAG as more than 262144 bytes free. If people are saying it has more because they can flash a large file to it that doesn't mean anything except that the flasher isn't properly verifying what was written.

I have seen people assuming that maybe they are failed 512K chips marked as 256K because they failed quality testing, but that isn't true either since ST changes the ROM on the chip to point to the available flash size and even if present on the die you cannot write to that area since as far as the chip is concerned that region doesn't exist.

[looxonline]

@Ideaforge738 Have you done some independent research regarding this or are you basing this off the datasheet?
It has been well established that the STM32F103RC chips do have 512k flash available despite the datasheet saying otherwise.

I have used the same chips on these and other boards ( I do embedded development) . You can verify the size by using a JTAG on the board but most people don't have that capability. I have yet to see a single reliable source say that they contain any more than what ST says that they do. and I have never seen one show up on a JTAG as more than 262144 bytes free. If people are saying it has more because they can flash a large file to it that doesn't mean anything except that the flasher isn't properly verifying what was written.

I have seen people assuming that maybe they are failed 512K chips marked as 256K because they failed quality testing, but that isn't true either since ST changes the ROM on the chip to point to the available flash size and even if present on the die you cannot write to that area since as far as the chip is concerned that region doesn't exist.

I'm also an embedded dev and I have seen this sort of behavior from manufacturers on several occasions. Sometimes it just does not pay to have two different dies manufactured when you can get better costs by combining and then setting fuses. I highly doubt that flashers are not validating the written bytes since that is a pretty cut and dry procedure using standard commands to the chip. If it was not happy with the memory region being accessed (R or W) it would throw an error in response to that access request and the process would fail. Also, I would not expect to see a multitude of different flashers failing in the same way. It seems as if ST are using the same die and have not disabled their internal fuses to prevent use of this. In any event, this thread is not about the flash size and since I am experiencing the same issues using the 256k env the issue is not related to the flash size either. If you would like to discuss the flash size then it would be better to open another thread.

[floxflux]

I have the same issue as op.
Stuck on the last layer when octoprint is connected. The end gcode is not executed at all. The hot end and the bed stayed hot until i manually select cooldown on the lcd. Using marlin 2.0.2 on skr mini e3 1.2 with octopi 0.17

[boelle]

@everyone

is the problem also there on latest bugfix 2.0.x? that is what is used to make the releases like 2.0.2 and 2.0.3 but its updated daily so ALMOST always newer than the releases

[floxflux]

its there on 2.0.2

[boelle]

and 2.0.3?
and bugfix 2.0.x ?

[gonzaloalbito]

Same problem when connected to BTT TFT35 screen.

[sjasonsmith]

I made a change 6 days ago that may have fixed this. Somebody needs to re-test with bugfix-2.0.x and report back. This change is not yet in a release.

16749

[gonzaloalbito]

I'd just build the latest version and will give it a try for the next prints

[Taomyn]

Yesterday I compiled bugfix 2.0.x from a download, files are dated 6th Feb, and although the prints ended fine with OctoPrint if I aborted/cancelled a print, the printer remains in limbo waiting to resume. If I disconnect then reconnect in OctoPrint it clears the problem. I can't test from SD because I disable it for more space.

[sjasonsmith]

the printer remains in limbo waiting to resume.

So it seems like the original behavior is fixed, but there is now another issue with the unexpected pause.

This seems to match the description of #16808 that somebody else just filed. I thought this had already come up recently, but I can't find the relevant issues/PRs/commits.

[Taomyn]

@sjasonsmith at least it's hopefully not something I miss-entered when customising my build - the last build I had working without the issue was back in mid-Jan. I should have also stated that this is with the original Melzi board (1.1.4) that came with my Ender 3 Pro. I also used VSCode with the Auto Marlin Builder extension to build an Optiboot version.

Let me know if you need any more information from my build.

[gonzaloalbito]

5 of 5 successful ending prints makes me think this is finally solved.
I'm not sure it's related but I'd noticed another strange behavior when octoprint or the BTT LCD screen are attached to the printer:
After some printing time, the printing process begins doing micro-pauses. Steppers are stopped a fraction of a second each 10-20s or so. Not enough to be noticeable without paying a lot of attention, but enough to leave bubbles in the print walls.
I though it was my SD card at first time, but during a print with this problem I disconnected the octoprint usb cable and the screen and it started to work properly without these pauses after that moment.
I will take some pictures or maybe a video and report this as a separate issue.

[Taomyn]

@gonzaloalbito have you tested aborting/cancelling prints? As per my report before normally ending prints are fine, but when I cancel the job in OctoPrint the printer remains in "limbo" waiting to resume.

[gonzaloalbito]

@gonzaloalbito have you tested aborting/cancelling prints? As per my report before normally ending prints are fine, but when I cancel the job in OctoPrint the printer remains in "limbo" waiting to resume.

I've not tested it yet since in order to preserve print quality from the micropause bubbles I've disconnected the octoprint... I'm currently printing some pieces agaist the clock so I will try to test it when my print queue is finished...

[thinkyhead]

when I cancel the job in OctoPrint

@Taomyn — Do you know what OctoPrint is sending when it cancels? To find out you can use M111 S3 and Marlin will echo back whatever it gets from the host.

[Taomyn]

@thinkyhead I'll try and find out tonight, but this week I might not be able to use the printer until Friday.

[thinkyhead]

If it's just a standard install of OctoPrint I can also check to see what it throws out on a cancel.

[sakoula]

Hi, I was wondering are the fixes described in this thread are in the latest 2.0.4.4 release? Thanks!

[sakoula]

Hi! any feedback on whether this has been fixed on 2.0.5?

[dan-youd]

I have this same issue on an SKR Mini 1.2 only when connected to OctoPrint. This is with the 512k USB and none USB branches. Both act the same, then I needed to activate the none USB branch to get my PID's tuned as it consistently disconnected when using octoprint to autotune before the change.

I'd upgraded my blower fan and fan duct last night and forgotten that I still had it connected to OctoPrint from when I was setting my Z Offset, then started a print. When I came back the nozzle was say on the top layer cooking the filament and leaving a big blob of plastic. This is a really bad issue to have. Any other issues I can put up with, but an issue that involves freezing with the bed and nozzle stuck at temp is definitely something that needs to be priority to fix.

[sakoula]

Hey there! Keep up the amazing work you have been doing with Marlin!!!

So I was testing 2.0.5.1 and I cannot replicate the bug. I was just printing small prints and I need to print some more in order to be 100% sure. However I have a question. Inside ./Marlin/src/MarlinCore.cpp I see this

case 4:                                   // Display "Click to Continue..."
  #if HAS_RESUME_CONTINUE                 // 30 min timeout with LCD, 1 min without
    did_state = queue.enqueue_one_P(
      print_job_timer.duration() < 60 ? PSTR("M0Q1P1") : PSTR("M0Q1S" TERN(HAS_LCD_MENU, "1800", "60"))
    );
  #endif
  break;

which essentially pauses the printer once the print from the sd is over for 30minutes / 1800 seconds waiting for a 'click' on the lcd knob.

During that time on the octoprint console I get these messages (with M111 S3 on):

Recv: X:0.00 Y:116.91 Z:8.42 E:-4.00 Count X:0 Y:9353 Z:3393
Recv: echo:M106 S0
Recv: echo:M104 S0
Recv: echo:M140 S0
Recv: //action:notification Ender-3 Ready.
Recv: echo:M84
Recv: echo:M31
Recv: //action:notification 7m 19s
Recv: echo:Print time: 7m 19s
Recv: echo:M77
Recv: echo:M0Q1S1800
Recv: //action:prompt_end
Recv: //action:prompt_begin M0 Stop
Recv: //action:prompt_button Continue
Recv: echo:busy: paused for user
Recv:  T:169.17 /0.00 B:56.67 /0.00 @:0 B@:0
Recv: echo:busy: paused for user
Recv:  T:166.39 /0.00 B:56.61 /0.00 @:0 B@:0
Recv: echo:busy: paused for user

I think 30minutes is way long for users that are using both LCD and Octoprint. I think it can be either configurable or a fixed value of 1 minute.

Any thoughts?

I have already written a small patch changing this and adding a #define SD_COMPLETE_TIMEOUT "60" on Configuration.h but want to ask for your thoughts.

[sakoula]

Hi everyone,

I am not experiencing the issue anymore on 2.0.5.1 and 2.0.5.2

[tsndr]

It happened to me again on 2.0.5.3 :/

[boelle]

@RedOctobyr
Please test the bugfix-2.0.x branch to see where it stands.

[c3D-Dan]

Same issue here with SKR pro 1.1 and 2.0.5 using TMC2208 drivers for x and y axes (128 microsteps). Printing from SD card. Was working fine for months, now fails every print. Usually after an hour or so. Hotends stay hot, TFT24 stays responsive, info display stays working. Even able to successfully “stop” the print via the LCD menu.

Last updated the firmware a couple of months ago. Will try newer version.

This issue seems to be the gift which keeps on giving. No one seems is to have an answer.

Have tried different SD Card, same issue
Will try reducing driver current
Will try reducing microstepping to 64 or 32x
Will also try replacing the BTT TFT24 with a standard 12864 and report back

[looxonline]

Same issue here with SKR pro 1.1 and 2.0.5 using TMC2208 drivers for x and y axes (128 microsteps). Printing from SD card. Was working fine for months, now fails every print. Usually after an hour or so.

Last updated the firmware a couple of months ago. Will try newer version.

This issue seems to be the gift which keeps on giving. No one seems is to have an answer.

Have tried different SD Card, same issue
Will try reducing driver current
Will try reducing microstepping to 64 or 32x
Will also try replacing the BTT TFT24 with a standard 12864 and report back

This may not be the same issue. The issue in question here causes a failure around the very last G-code to be implemented and results in the hotend and bed remaining on and the printer becoming unresponsive.

On another note, why not let the TMC drivers do your microstepping interpolation instead of specifying it in the code and making your micro work extra hard thereby increasing the potential for other issues to creep in?

[c3D-Dan]

I’m not sure you can run them higher than 32x in standalone mode. I’d certainly prefer to do that if you know how I can get higher without intervention from Marlin?

[looxonline]

I’m not sure you can run them higher than 32x in standalone mode. I’d certainly prefer to do that if you know how I can get higher without intervention from Marlin?

In both stand alone mode and UART/SPI mode the TMC can do the interpolation. For UART/SPI simply make sure that the #define INTERPOLATE true line is not commented out in configuration_adv.h. You will then have 256 microsteps interpolated by the TMC for only 16 microsteps calculated by Marlin and thereby greatly reduce the load on your MCU.

[c3D-Dan]

Ok So you're saying

define INTERPOLATE true // 0..256

and

define X_MICROSTEPS 16 // 0..256

??? Or should I set X_MICROSTEPS to 256?

[sjasonsmith]

Can somebody verify whether the original reported issue (Prints don't finish correctly from SD) is still a problem? It looks like this thread may have diverged into other unrelated topics.

[c3D-Dan]

Likely related to #18358

[c3D-Dan]

@looxonline #define INTERPOLATE is negated by defining TMC2208_STANDALONE. In fact the whole section of code is negated.

[looxonline]

@looxonline #define INTERPOLATE is negated by defining TMC2208_STANDALONE. In fact the whole section of code is negated.

Google TMC microplyer. Not going to discuss it more on this thread because it is off topic but you should not set your microsteps to 256 in the code. If you want to discuss it further you are welcome to create another relevant thread and tag me.

[looxonline]

Can somebody verify whether the original reported issue (Prints don't finish correctly from SD) is still a problem? It looks like this thread may have diverged into other unrelated topics.

User @tsndr reported that it was still happening on 2.0.5.3 and since there has been no subsequent release (and no further feedback on bugfix) it would appear as if nothing would have changed. I have disconnected octoprint from my E3 mini because this issue was too dangerous and therefore I have not seen it happening.

[c3D-Dan]

@looxonline #define INTERPOLATE is negated by defining TMC2208_STANDALONE. In fact the whole section of code is negated.

Google TMC microplyer. Not going to discuss it more on this thread because it is off topic but you should not set your microsteps to 256 in the code. If you want to discuss it further you are welcome to create another relevant thread and tag me.

@looxonline That was the first thing I did. TMCs own documentation don't clarify whether interpolation (microplyer) is automatic IF microstepping is set to 16x, just that It can interpolate from 16x. Further no indication if the TMC driver NEEDS to be jumpered, in UART or otherwise for this to occur. (bearing in mind im clearly going FROM a jumpered, UART configuration.

You've come up with a "work around" with explicit configuration settings, yet they make no sense. Discussing it here is entirely appropriate.

[sakoula]

Can somebody verify whether the original reported issue (Prints don't finish correctly from SD) is still a problem? It looks like this thread may have diverged into other unrelated topics.

have not happened to me and have been on 2.0.5.3 for a while now. I think unless someone else has a different opinion it should be considered closed. In the case it is happening to someone please share your configuration.h configuration_adv.h and platformio.ini

[c3D-Dan]

To be clear, what’s the longest print any of those who want this closed have experienced? I got a little over 24 hrs before a freeze today. Running 2.0.5.3. I have also completely changed the board and stepper drivers.

[looxonline]

To be clear, what’s the longest print any of those who want this closed have experienced? I got a little over 24 hrs before a freeze today. Running 2.0.5.3. I have also completely changed the board and stepper drivers.

Print time had no bearing on the end result for me. It was always the last g-code of the print whether it was 3 days or 15 minutes.

[sjasonsmith]

@c3D-Dan & @tsndr, are your hangs occurringly randomly during the print, or only at the end?

This thread has grown to encase multiple different issues. Addressing multiple issues at once causes problems, because it means nothing can ever be closed. It is also confusing for contributors, because details about a problem are hidden throughout many unrelated issue reports. It is best to allow one open issue to address a single problem, then open additional issues if different problems are found.

Short Summary

• If Marlin thinks your print is still in progress after your print is completely finished, we should continue to discuss it here.
• If your prints are hanging randomly, this is the wrong issue, and it should be allowed to be closed.

What this issue was originally
The original issue was that the printer thought the print was still in progress after a print. The printer was still responsive, but you could not start another print. From the original issue:

_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._

What people seem to be discussing now
The remaining issues I see involve the entire board hanging at some time during the print, and leaving heaters enabled.
There are several other open issues specific to this, and it would be more productive to move your discussion to them. The one linked below has had some very in-depth debugging performed, and provides a workaround which may help reduce the chance of the issue occurring.
https://github.com/MarlinFirmware/Marlin/issues/18358 - Nested interrupts corrupt LR ( AKA printer freezes mid print with heaters on )

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.