I noticed that the motherboard CPU is heating up unnecessarily even when idle.
After logging in via SSH and checking with htop, I saw that the xindi process continuously loads the CPU, and it even runs in two instances.
I investigated what might be causing the load and found that in MakerbaseParseMessage.cpp, the parsing loop has a sleep time that is far too short. The parameter of usleep is set to 5, which is interpreted in microseconds, and is extremely small.
I am not sure if the intended value was 5 milliseconds instead, which would require the parameter to be 5000. In any case, I modified the source code, rebuilt the xindi binary, replaced the existing one on the printer, and the CPU load issue disappeared.
Most likely even 5000 is too small, and a value such as 50000 could also work fine, since the screen remains responsive at that setting as well, in my opinion.
If possible, I kindly ask you to fix this in future firmware updates to avoid unnecessary CPU load and overheating. This issue affects all X series printers.
CPU usage of the factory-compiled xindi binary shown on the Fluidd interface graph:
CPU usage with my rebuilt, fixed xindi binary:
I noticed that the motherboard CPU is heating up unnecessarily even when idle.
After logging in via SSH and checking with htop, I saw that the xindi process continuously loads the CPU, and it even runs in two instances.
I investigated what might be causing the load and found that in MakerbaseParseMessage.cpp, the parsing loop has a sleep time that is far too short. The parameter of
usleepis set to 5, which is interpreted in microseconds, and is extremely small.QIDI_MAX3/src/MakerbaseParseMessage.cpp
Line 203 in ec09329
I am not sure if the intended value was 5 milliseconds instead, which would require the parameter to be 5000. In any case, I modified the source code, rebuilt the xindi binary, replaced the existing one on the printer, and the CPU load issue disappeared.
Most likely even 5000 is too small, and a value such as 50000 could also work fine, since the screen remains responsive at that setting as well, in my opinion.
If possible, I kindly ask you to fix this in future firmware updates to avoid unnecessary CPU load and overheating. This issue affects all X series printers.
CPU usage of the factory-compiled xindi binary shown on the Fluidd interface graph:
CPU usage with my rebuilt, fixed xindi binary: