What causes a regular GCODE X+Y+E command to be considered unknown?

What is the problem?

Octoprint freezes regularly. I could not find a cause for this in the log files. However, when I check the status of the octoprint server in the command line immediately after the freeze, I see the error message as shown in the attached screenshot.

An unrecognized GCODE command is listed here. I assume that this is also the cause of the freeze. Does anyone have any idea what is causing this?

PS: I have to add that this freezing occurs when printing but occasionally also when octoprint is in idle state.

What did you already try to solve it?

I have tried different slicers. Mainly I use Cura. In safe mode these errors do not seem to occur. So I thought that maybe the Arc Welder plugin could produce a faulty gcode here. But that doesn't seem to be the reason - deactivating this plugin doesn't lead to any improvement. And as far as I know, no other plugin changes the Gcode sent after slicing ...

Have you tried running in safe mode?

Yes

Did running in safe mode solve the problem?

Basically yes, because I have not experienced any freezing in safety mode so far. In normal mode, even if I deactivate 98% of all plugins, this error occurs again. Therefore, I am somewhat at my wits end.

Systeminfo Bundle

octoprint-systeminfo-20220627083826.zip (3.7 KB)

WRITE HERE

Additional information about your setup

Raspberry Pi 4 Model B Rev 1.2
Marlin 2.0.9.3
Octoprint 1.8.1
Cura 5.0.0 (and tried also with older versions)
Simplify 3D 4.1.2

grafik

This is not a GCODE command, this is just a bunch of coordinates/extrusion amount.

A GCODE moving command usually starts with a G, like G1

https://reprap.org/wiki/G-code

The log contents is quite small to tell where this happend, but you may check your Start GCODE in your slicer or OctoPrint for a missing command (G..).

You may share a small gcode file

Dear ewald,

thank you. I should have been more specific.

screeny2

Via Notepad++ I determined this coded at line 18691. Nothing looks unusual here.

What is the 2% you did not deactivate?

You also may enable the serial.log and try a print so that we can see what is happening there.

What printer do you use? Is the Marlin firmware from that company?

Dear ewald,

sorry I am printing on an Ender 3 Pro

I checked the serial.log a few time after freezing occurs. (another Post) But nothing to determine here.

In fact these problems appeared again after some months when I updated my firmware again and made some settings myself ... nevertheless I don't understand why this line in the Gcode is declared as unknown command or what could have led to this error message.

Marlin_2-0-9-3_configuration.zip (85.0 KB)

Maybe it has to do with this issue or something with the buffer size?

Could you please share the serial.log

The command was declared as unknown because it was the G1 at the start was omitted. Some plugin does not behave correct.
So, again:

The octoprint.log in the systeminfo bundle is way to short to get any useful information from it. Usually we find a list of installed plugins, but without it, we even can make a wild guess what plugin the culprit could be.

Dear ewald,

ok - I deleted the old logs, set the log level to debug and then started a new print today at 16:40. At 17:22 the whole thing froze again. But obviously not necessarily because of an unknown command but because of some other reason I just can't find.

Here is the System Info Bundle pulled after the server restart:

octoprint-systeminfo-20220627172734.zip (41.1 KB)

I'm already trying myself silly ...

Somehow I have the feeling that there might be a problem with the buffer - that could also explain why there is nothing concrete in the logs, right?

Please enable DEBOG mode only when a plugin dev asks for it. From the about 2700 lines in the octoprint.log, only 477 are useful.

Somehow there is a gap in the octoprint.log between 17:22:11 and 17:26:40 so that the lines in the snapshot do not appear there.

The buffer seems ok.
But there is this issue with resend line N25796.

Have you thought about reinstalling the firmware?

Please check these plugins to be sure they are not the culprit.

Dear Ewald,

thank you for your commitment, but somehow we are not getting anywhere here.

Anyway, the gap between 17:22:11 and 17:26:40 occurred because Octoprint froze here - and this is exactly my problem. What causes this freeze? And most importantly: Why does this occur even when Octoprint is idle, i.e. not printing?

You have detected a resent line N25796. What causes these resends? Because an OK is not tranceived? Because again e.g. G1 was skipped before the coordinates? Something is causing Octoprint to go completely off the rails here - and it's not the firmware that's crashing either. The firmware automatically shuts down the temperature after 5 minutes because nothing more comes from Octoprint.

And yes, I have already reinstalled the firmware several times and tried various parameters. Currently I'm testing whether within Marlin an activated ADVANCED_OK feature could bring something.

PS: There is a setting in the advanced option of Octoprint: Simulate additional ok for resend requests If recognized as necessary / Always / Never ... would it be an idea to set this to ALWAYS?

SIGKILL implies that the process is being killed. Not freezing, but killed - either by the OS or by another process. This is always done with explicit intent. Something is deliberately killing the octoprint service.

Dear octoprintfan111,

thank you - this is an interesting new tip.

I just bought an EMI filter for the 230V power supply, because there are already several suspicions that the Creality mainboards are extremely sensitive to voltage fluctuations or certain induced frequencies. This I will test the next few days and also additional ferrite clamps on the USB cable etc. ...

Now I wonder if such influences could cause such a SIGKILL command to be triggered? And especially where this comes from - from Octoprint itself or from the OS?

This SIGKILL is triggered regularly, or rather irregularly, in my setup apparently by a wide variety of reasons. Sometimes it seems to be a swallowed G1 command and then another time something completely different ...

A silly question: Could the Virtual Environment also have something to do with it? Would it make sense to install Octoprint in a non-VENV and then import the backup to it?

You can see - I'm pretty much stuck in the dark here with this problem ...

As you have mentioned, Creality printers are very susceptible to EMI interference as well as being a generator of EMI which isn't a good combination. The USB cable needs to be high quality, shielded, short, and have ferite beads at both ends. The routing of the USB cable as well as the routing of other cables within the printer have a major influence on the reliability of communications and ability to successfully print. The location of the RPi relative to the printer can also have an effect.

This forum has numerous topics on Creality communications challenges with numerous suggested fixes.

1 Like

One thing I have found that causes the resends is having the baud rate incorrectly set (too high). This can be seen very often with the lower quality cables

I finally settled on using 57600 for my fixed baud rate and my resend count is a steady zero.
I am not using a super fast printer and the lower baud rate is more than adequate for my needs.

Maybe you could try setting a fixed (and lower than present) baud rate both from the firmware and matching it from octoprint to see if that may fix the freezes.