# Possible threading issue in Klippy? **URL:** \ **Category:** General Discussion\ **Created:** [April 4, 2022, 5:46pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492 "2022-04-04T17:46:24Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 4, 2022, 5:46pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/1 "2022-04-04T17:46:25Z")
We are a couple of people trying to make a nice and clean setup on the Creality CR-10 Smart Pro, the discussion is over on Reddit. Two different errors keep plaguing the installs, a “Move out of range” error and a “Timer too close” error. We are running both Mainsail and Fluidd on the internal WiFi board (OpenWRT) and we see the same type of errors. We are using the Creality installed 8GB SD card for storage. For the former error, (at least) one of the coordinates will be completely out of whack, for instance the error may look like this: `Move out of range: 122.074 3000.000 69.984 [6018.842]` For me it typically happens before the G1 line in ```auto BED_MESH_CALIBRATE BED_MESH_PROFILE LOAD=default G1 X295 Y5 Z50 F5000 ``` in the startup script. Once it has happened, only saving&restart of the printer.cfg file will cure it. If only a new attempt at printing is made, it will fail with the same coordinates just after probing is done. A friend of mine with an Ender 3 S1 and an RPi3 also sees the same problem on occasion. This is NOT the same as the configuration mistake typically made when forgetting to account for the probe offset when probing the bed. It will work more than 9 out of 10 times. The “Timer too close” has happened both when uploading a file from PrusaSlicer and during printing of a Benchy. The fact that the errors are not exclusive to the Creality WiFi card, but happens more frequently along with the random data corruption suggests to me either a threading problem or a stray pointer somewhere, but I do not have the knowledge of python to quickly find any apparent issues. The two errors may be caused by the same issue or they could be completely separate matters. Running the latest from GitHub. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 4, 2022, 7:10pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/2 "2022-04-04T19:10:17Z")
It’s not possible to offer any help without a log file showing the errors. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 4, 2022, 7:19pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/3 "2022-04-04T19:19:45Z")
Also when you say internal wifi board, is that the same as the Creality wi-fi box? If it is, you’re not going to have a good experience running Klipper on it. That only has a single core 580Mhz mips processor with 128MB of RAM. That’s half the speed of the original Pi Zero which is already too slow to handle Klipper and a webcam at the same time. ---
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 4, 2022, 7:33pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/4 "2022-04-04T19:33:41Z")
It is the same - not running a webcam on it though. The speed shouldn’t cause commanding random coordinates, although it could explain the MCU shutdowns. Will capture a set of logs the next time I see the problem, could be today, could be in a week. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 4, 2022, 7:40pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/5 "2022-04-04T19:40:35Z")
Yes, the out of range error is likely unrelated to the hadware you’re using. Without a log though it’s impossible to offer any advice. The timer too close error is usually either a communication issue, or their wasn’t enough processor time available. ---
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 4, 2022, 7:43pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/6 "2022-04-04T19:43:43Z")
I guess the post was first and foremost to get reports of the problem out of the woodwork, of the three people I know running Klipper all have seen it. So I think it may be underreported and possibly a hint to a larger underlying problem. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [April 4, 2022, 7:57pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/7 "2022-04-04T19:57:35Z")
Or it is as simple as @jakep_82 hinted at: The box is simply too slow to run Klipper. Edit: Another spitball: Guess you are running this OpenWRT fork on it. Maybe just something in there that does not play nice with Klipper. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 4, 2022, 8:03pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/8 "2022-04-04T20:03:44Z")
I’m actively running Klipper on 3 different printers, and I don’t have this problem on any of them. I’m also a helper on Discord where we have 12,000+ members and I’m not seeing this reported by anyone running common hardware. I think it’s more likely something specific to your hardware and/or configuration. ---
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 6, 2022, 5:42am UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/9 "2022-04-06T05:42:21Z")
With respect to the hardware being slow; yes, by today’s standards it is, 25 years ago the CPU spec on the Creality WiFi Box would have been found on a mid to high-end SGI workstation. It is _plenty_ fast enough to keep up with the demands of a single 250kbps serial port, it is just a matter of priority. And AFAICT Klipper - at least in KlipperWRT form - does not make any priorities. Everything, hard realtime, soft realtime and non-realtime runs at the same system priority. Only klipper.py is hard realtime, everything else is just a nuisance if they are delayed. I changed /etc/init.d/klipper to invoke klipper with `nice --9`, just randomly picking a priority higher than default, I could then successfully print with sustained 100% CPU utilization, a load factor \>4 and five dashboards. Dashboards were lagging, of course, but the main thing was that the operation of the printer itself was unaffected. Before I did the change, running `find /` on it while printing would cause an immediate MCU shutdown. ---
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 6, 2022, 4:03pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/10 "2022-04-06T16:03:24Z")
Hmmm. Didn’t quite expect that one. Overstressed it with external loads yesterday without issue, now it died again, timer too close. [klippy-log.zip](https://klipper.discourse.group/uploads/short-url/m4mzJW8bpKSzJ4uavj4qqtCztE4.zip) (255.8 KB) ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 6, 2022, 4:30pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/11 "2022-04-06T16:30:02Z")
Here’s the stat graph. Not sure what’s happening, but you can see the problem at the end. ![Stats](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/0/03ef07ba35260d3d51a4155a3996e7a3e81237b2.png) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [April 6, 2022, 4:30pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/12 "2022-04-06T16:30:21Z")
There are some tools you can use to analyze the Klipper log (details at [Debugging - Klipper documentation](https://www.klipper3d.org/Debugging.html#generating-load-graphs) ). For example, your log shows ( `scripts/graphstats.py klippy-3.log -s` ): ![load](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/b/bdf920bc18d94093e952dd642634e9cbe2b04f92.png) The host cpu is clearly struggling to keep up during the entire duration (blue system load average is regularly above 100%). It’s actually fairly impressive that Klipper ran as long as it did. Ultimately, it looks like you also went into memory swap (note the decreasing yellow line) which finally killed it. FWIW, low end host cpus aren’t a target for me. I don’t know of anyone currently working on it. -Kevin ---
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 6, 2022, 5:17pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/13 "2022-04-06T17:17:05Z")
Interesting graph. I will admit to being very fresh to Klipper - like 8 days in… Given a large enough print, that available memory line could become a problem for any CPU, it could look like a memory leak. It could, of course, also be a garbage collector not having time to run… Load above 1 isn’t a problem as long as the processes waiting are soft realtime or less, IMHO there is something very wrong if a sudden spike of incoming web interface requests will cause a disruption to the hard realtime application, it should have explicit priority. That was what I attempted with my change to the startup script, and it almost worked. I just didn’t foresee the swap issue. The Benchy Gcode is only 2.5MB, so not in anyway massive. I have a NUC running Ubuntu and a few Atlassian applications sitting next to the printer, I guess the next step is to hook that up to the printer and try again. ---
**Author:** ![enderbender](https://avatars.discourse-cdn.com/v4/letter/e/9de053/32.png) [@enderbender](https://klipper.discourse.group/u/enderbender)\ **Post date:** [April 6, 2022, 6:52pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/14 "2022-04-06T18:52:26Z")
> Given a large enough print, that available memory line could become a problem for any CPU, it could look like a memory leak. It could, of course, also be a garbage collector not having time to run… Load above 1 isn’t a problem as long as the processes waiting are soft realtime or less, IMHO there is something very wrong if a sudden spike of incoming web interface requests will cause a disruption to the hard realtime application, it should have explicit priority. That was what I attempted with my change to the startup script, and it almost worked. I just didn’t foresee the swap issue. The Benchy Gcode is only 2.5MB, so not in anyway massive. The graph Kevin posted clearly shows your system is heavily loaded. If you run some number crunching application that doesn’t care about latency and processes getting temporarily no computing time or has to wait on disk thats okay. With software like klipper which needs to calculate and send stuff out with not too much delay, that’s not a really good idea. You can now spend days and weeks analyzing and improving Linux scheduling, nice, ionice, cgroups, running latencytop and whatnot, compile kernels, change schedulers and options, Hz numbers, ticks, noticks, disk cache settings, vm dirty ratio and whatnot. Maybe you get it right. Maybe not because you run into one of the many Linux scheduling issues, especially with direct attached sdcard or mmc storage (i.e. heavy disk access will stall _everything_ no matter how much you optimize everything you can just mitigate it a bit, not fix it). I’d do some more basic checks i.e. if it’s swapping etc. but if there’s nothing obvious I wouldn’t spend the time and just use a more powerful machine. Much easier and more reliable. > I have a NUC running Ubuntu and a few Atlassian applications sitting next to the printer, I guess the next step is to hook that up to the printer and try again. You mean running klipper on the same machine that runs Atlassian applications? Those Atlassian Java memory and CPU hogs? That sounds like asking for trouble again 😉 ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 6, 2022, 7:16pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/15 "2022-04-06T19:16:16Z")
General info about running Klipper on something other than a Pi can be found at [this link.](https://www.klipper3d.org/FAQ.html#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3) Take special note of the warnings about running intensive general-purpose computing tasks on the host computer. ---
**Author:** ![subwooferbone](https://avatars.discourse-cdn.com/v4/letter/s/45deac/32.png) [@subwooferbone](https://klipper.discourse.group/u/subwooferbone)\ **Post date:** [April 6, 2022, 7:33pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/16 "2022-04-06T19:33:59Z")
enderbender, I don´t disagree that it’s heavily loaded, I’m just saying it should be able to handle it because the fraction taken by the hard realtime system is manageable. Unless the chimney on the Benchy is very compute intensive, which I don’t think it is. I could be mistaken. But I did do a few more checks and I found that logd was using a 51200kiB memory buffer. Reduced that by a factor 10 and instantly had a lot more RAM available. Printing the bench again with exactly the same Gcode now, so we’ll see how we fare. By the looks of things, it was RAM that took us out. It’s not easy to get hold of a Pi these days. ---
**Author:** ![enderbender](https://avatars.discourse-cdn.com/v4/letter/e/9de053/32.png) [@enderbender](https://klipper.discourse.group/u/enderbender)\ **Post date:** [April 6, 2022, 8:09pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/17 "2022-04-06T20:09:23Z")
Well. This is an interesting coincidence. Now I just had that out of range error you reported subwooferbone. But I have plenty of procesing power, it’s a Pi4. It also happened inside the startscript. Usually first it homes XY, then goes to the front right. It only went to the right, but not to the front. The next move then gave the out of range error. Edit: It happened here: ```auto [gcode_macro START_PRINT] gcode: {% set BED_TEMP = params.BED_TEMP|default(70)|float %} {% set EXTRUDER_TEMP = params.EXTRUDER_TEMP|default(220)|float %} M140 S{BED_TEMP}; Bett Temp setzen ohne warten auf Ziel Temp M104 S150; Extruder Temp auf 150 Grad setzen ohne warten auf Ziel Temp G28 X Y; Home XY Achse G1 X260 Y0 F5000; Nach ganz vorne Rechts fahren ``` Instead of going to the front right, it only went to the right, not to the front, then it continued heating, after heating was done, the out of range error occured. [klippy-outofrange.log](https://klipper.discourse.group/uploads/short-url/sv3MJx2G9j4d2aduGjOE7vHLJzJ.log) (5.1 MB) ---
**Author:** ![enderbender](https://avatars.discourse-cdn.com/v4/letter/e/9de053/32.png) [@enderbender](https://klipper.discourse.group/u/enderbender)\ **Post date:** [April 6, 2022, 8:56pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/18 "2022-04-06T20:56:23Z")
Now I just pressed the “restart” button on the klipperscreen and it’s giving me the exact same error again. I’ll leave the printer and the Pi on now in case somebody wants me to try or do something to further narrow this down. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 6, 2022, 9:00pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/19 "2022-04-06T21:00:04Z")
Are you sure the printer is in absolute mode (G90) and not relative (G91)? Issuing `G1 X260 Y0 F5000` while in relative mode would do exactly what you describe, and the subsequent `G1 X259.5 Y0 F6000` would result in the printer attempting to move X to 519.5 which matches your error. ---
**Author:** ![jakep\_82](https://avatars.discourse-cdn.com/v4/letter/j/ea666f/32.png) [@jakep\_82](https://klipper.discourse.group/u/jakep_82)\ **Post date:** [April 6, 2022, 9:11pm UTC](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492/20 "2022-04-06T21:11:01Z")
Looking at your config, you have G91 in your PAUSE macro, but I don’t see a G90 anywhere to put the printer back into absolute. You might want to add that to your START\_PRINT macro if it’s not explicitly added by your slicer. [Next page](https://klipper.discourse.group/t/possible-threading-issue-in-klippy/2492.md?page=2)