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?
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.
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.
The command was declared as unknown because it was the G1 at the start was omitted. Some plugin does not behave correct.
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.
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:
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.
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.