Error at the end of printing

Hi all,

I've been experiencing this error lately:
at the end of printing while receiving the G28 command to go to Home, the printer stops, I report the terminal commands to the offending point.

Another thing, I only noticed now that at the end of each command there is a * followed by a number. It's normal?
In the Gcode is not present.

...
...
...
Send: N95620 M140 S0109
Recv: ok
Send: N95621 M84
22
Recv: ok
Send: N95622 M10747
Recv: ok
Send: N95623 G91
26
Recv: ok
Send: N95624 G1 E-1 F3008
Recv: ok
Send: N95625 G1 Z+0.5 E-5
34
Recv: ok
Send: N95626 G28 X0*85
Recv: echo:enqueueing "ô\x03\x04"
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Printing" to "Error: Printer halted. kill() called!"
Send: M112
Send: N95627 M11246
Send: N95628 M104 T0 S0
33
Send: N95629 M140 S0100
Changing monitoring state from "Error: Printer halted. kill() called!" to "Offline (Error: Printer halted. kill() called!)"
Connection closed, closing down monitor
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0xa67c13f0, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0
125
Recv: start
Recv: echo:V1.1.5
Recv: 1.1.0-RC8
Send: N0 M110 N0*125
Recv:
Recv: echo: Last Updated: 2016-12-06 12:00 | Author: (Jolly, REDACTED URL.)
Recv: Compiled: May 13 2019
...
...
...

Grazie
Daniele

OctoPrint sent G28 X0 and the printer saw this as something garbled. Treat this as...

  • incorrect serial cable for the job: should have internal metallic shielding or ferrite core
  • undervoltage on the Pi: needs the official 5V @ 2.5A power adapter (not a charger)

The *## is a basic checksum. What happens if you manually send G28 X0 to the printer using the terminal tab?

1 Like

Nope. The printer at this point on its own agenda enqueued a garbled command into its own command queue (probably in addition to the original G28, possibly in reaction to it).

This echo:enqueueing line is the firmware informing the host that it enqueued a command internally. Not all firmware does this, some does. It doesn't have anything to do with mirroring what was received from the printer (thankfully, or the serial line would get positively swamped).

1 Like

Any guesses as to what the firmware had in mind? Was that some magic reset sequence or something?

I am using a smartphone charger, now I try to change the power supply with 2,5 ÷ 3A.
I try to change also usb cable.

1 Like

If I send G28 X0, the head goes to X=0, so the command is correct.

Today he made a similar mistake, in previous prints he didn't.

...
...
...
Send: N138058 G1 E-1 F30051
Recv: ok
Send: N138059 G1 Z+0.5 E-5
25
Recv: ok
Send: N138060 G28 X0 Y046
Recv: echo:enqueueing "er "
Recv: Error:Printer halted. kill() called!
Changing monitoring state from "Printing" to "Error: Printer halted. kill() called!"
Send: M112
Send: N138061 M112
28
Send: N138062 M104 T0 S031
Send: N138063 M140 S0
90
Changing monitoring state from "Error: Printer halted. kill() called!" to "Offline (Error: Printer halted. kill() called!)"
Connection closed, closing down monitor

the strange thing is that it always happens after sending the G28 command.
Thanks for your help so far and sorry for my not perfect english.

I forgot to say that this error appeared after I changed the drivers to the Anycubic Mega S printer with DRV8825. I don't know if it can depend on this.

What did you say, what printer you are using?

And:

What firmware?

What happens when you enter G28 X0 Y0 in the terminal?
And what happens when you enter G28 X Y in the terminal?

None at all. Feels like corruption to me. GCODE is plain text.

My printer is a Anycubic Mega S with firmware V1.1.5
In the terminal both with command G28 X0 Y0 and with command G28 X Y the head goes to X=0 and Y=0.

So no errors when typing in from terminal...

Right, no errors from terminal.
However, this error does not occur on all prints.

I understood what the error depends on, my micro sd was corrupt, every day it gave me more and more errors, I changed microsd and installed everything new and now it is not giving me more problems.

Since I printed without Octoprint for the above problem, I realized that the printer prints better without Octoprint than with Octoprint.
I show you the print results


what can it depend on?
The gcode file is the same.

This is systematic issue: The ongoing USB Conspiracy Theory?
This may help: New Plugin: Anti Stutter - Need Testers

Here are some prints from today using Arc-Welder (I think it is the same print) streaming from OctoPrint:

Results will vary by firmware for sure, and you may need to change some firmware settings and recompile. G2/G3 support isn't universal ATM.