Mid print halting and hung up on "processing" in terminal

Get Help
1

What is the problem?

Halting print a few moves in. It happens at the same point every time, but there seems to be an "ok" missed and the printer just stays in a state of "echo:busy:processing". I cannot cancel, turn off hot end or bed - I just have to kill it at the wall.

What did you already try to solve it?

Different models - similar initial print duration, then stops. Stops at the same point every time.
Reformatted SD and re-uploaded firmware in a previous state that worked. Reset EEPROM settings, saved and rebooted.
Tried to continue a print using "Fake Acknowledgement" - did nothing still just processing.
Temperatures remain stable, so not waiting for any heating.
Not convinced it was a power issue - never had any problems before, and it stops at exactly the same Gcode every time. I would expect some variation if a power issue?

Have you tried running in safe mode?

No

Did running in safe mode solve the problem?

I am not sure it is a problem with Octoprint.

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

octoprint-systeminfo-20230608213919.zip (473.8 KB)

Second system info with serial.log turned on (this again has a failed print which has halted):
octoprint-systeminfo-20230608222354.zip (501.9 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Termimal Log of typical failure from start to finish here:
failed print terminal.zip (1.5 KB)

Printer is a Voxelab Aquila, but changed out mainboard for SKR 1.4 with TMC2209 drivers for X,Y,Z,E0 and Z2 on the E1 driver. Firmware is 2.1.x bugfix and zip file with configurations in is attached
Configuration.zip (98.2 KB)
I have adjusted "pins_BTT_SKR_V1_4.h" to open the serial for the LCD DWIN screen as well as the "Conditionals_LCD.h" (this is more for information just in case because was all working fine before).

I am plugged in from Pi Zero 2 running Octoprint via USB to the mainboard.

2

try in safe mode, reupload while running in that mode and try again. If it doesn't do it then it's a plugin issue. If it does then it's a gcode issue or an OctoPrint issue. Based on your description it sounds like possibly an unsupported gcode command or firmware not playing right.

3

Thanks bud!

I tried safe mode - still happened.

I have fixed it, but I am not 100% sure what fixed it. Here is what I did:

  • Downloaded latest 2.1.x bugfix and re-configured and compiled from scratch
  • Re-flashed firmware using SD card (normally I remote flash from octoprint).
  • Printed a test print from the SD card - Success
  • Printed a test print from octoprint - Success.

Problems are either:

  • I messed something up in the configuration files, not too sure this is the case because I did use "compare file" is VS code and took across all my normal settings one by one - but probably the most reasonable solution.
  • There was a small issue with previous bugfix release that has now been addressed. This problem arose when I was doing a bunch of testing on M600 command - second most likely I think
  • There was something in memory that couldn't clear properly, and printing from SD card cleared it up - not too sure this is even how this works?
  • Something else my simple mind cannot understand - also very likely
  • Pixies messing with me from the bottom of the garden - wouldn't put it past them.

Thanks and I hope this helps someone.

4

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