When I upload gocode files, the CPU utilization rate is 100%, which is abnormal

Get Help
1

What is the problem?

My gcode file size is about 70Mb. Recently, I found that after uploading the G-code file, the CPU utilization rate almost reaches 100%, and it has been maintained for a long time before it can return to the normal 7%

What did you already try to solve it?

If the size of the uploaded file is smaller, such as about 20Mb, this state will recover to 7% in about 30 seconds.

Have you tried running in safe mode?

YES,remain the same

Did running in safe mode solve the problem?

No.

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
octoprint-systeminfo-20220106182343.zip (115.4 KB)

cut
cut1718×1610 210 KB

Additional information about your setup

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

OctoPrint 1.7.2 Python 3.7.3 OctoPi 0.18.0
OctoPi version:Raspberry Pi 4 Model B Rev 1.2
printer:UM2+
firmware:Marlin Ultimaker2; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://github.com/Ultimaker PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ultimaker EXTRUDER_COUNT:1,
browser:Google Chrome,version:96.0.4664.110,
operating system:windows10

WRITE HERE

2

As fair as I know, OctoPrint performs some simple analysis of the gcode file to guess how long it is going to print for, the rough size of the design etc... It should stop slamming the cpu when you decide to start the print
N.B When you see a time estimation for your gcode file, the cpu usage should have reduced
N.B. 2 - Usage of 100% means that a single core of your CPU is fully used, but there are 4 of them on the Pi 4, so it should still have adequate performance for your needs

3

An hour has passed since I uploaded the G-code file. Click the file drop-down arrow. The arrow is gray and cannot display the printing time and other information.

1641467003(1)
1641467003(1)778×942 61.1 KB

Thank you.

4

I believe you were printing when submitting the analysis. Unfortunately I am therefore unable to see anything related to the gcode analysis.
However, is the cpu still high while the arrow is grey? Is it a gcode file?

5

I would also recommend to have a look at the solutions proposed here

6

Do you always ha the DEBUG mode on?

Inside your 9200 lines of octoprint.log, about 8800 lines are just DEBUG infos.

7

It's definitely trying to gcode analysis according to the log files. There's no sign of it finishing the analysis in there. So I would say that's what is using the CPU time, trying to analyse the file. Maybe there is something wrong with the file, and it's making the gcode analysis take long time.

Can you share it so we can test it out?

8

Yes, in order to record the event information in detail, I always set the logging level to debug.

9

The file size is about 70mb. How can I share it with you?

10

Through log file analysis, I found a large number of error messages as follows:
octoprint.filemanager.analysis - ERROR - Analysis for local:hobby/xxx/UM2_xxxV4X6(50mm).gcode ran into error: No analysis result found

11

Finally, I found a problem when I checked the G-code file. A large number of garbled codes in the g-code file are found, which should be the BUG of the slicer (Cura 4.12.1). It has nothing to do with octoprint.thanks to all.

12

Keep in mind that a SD card has a certain amount of write cycles.
When you always do the DEBUG (which is only necessary when a dev asks for it), the SD card will fail soon.

In addition, the octoprint.log will become quite huge and fill up the SD card quite fast.

13

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