Where is the difference - 10 times X1 vs 1 times X10
-
@dc42 said in Where is the difference - 10 times X1 vs 1 times X10:
Every task that has a to meet a deadline to maintain the expected results/performance is a real time task. Step pulse generation is hard real-time, so hard that it is normally done by an ISR, not an RTOS task. Planning is a softer real-time task, because occasional underruns in the movement queue can be tolerated. Reading and parsing GCode commands from file is softer still.
From an engineering POV, Klipper should be using a RTOS for the planner. It gets away without using one because there is usually enough CPU power to keep up, especially when using a multicore Pi and the Pi is not being used for anything else (e.g. slicing).
Good clarity. Missing a deadline, even at the medium soft levels, ruins a print. Running "far enough in advance to usually get away with it" is not the same.
-
@dc42 Well, well, well... seems Klipper users have encountered MCU bottlenecks.
Not trying to pick on anyone, just found a relevant issue come to light and I thought it would be nice to tie it all in.
-
@bot looking that log file he's not going over 40%... and is using rather conservative settings ( 1/16 on ramps with 80mm/sec print and 130mm/sec move) .. I guess this would be seen a lot if it's a common problem (especially as a whole lot is using 1/32 and 1/64) ... something smells bad there
-
It seems that the new version of Klipper has potentially introduced some "MCU-stopping" bugs. It could be related to their very interesting "input-shaping" feature.
But yeah, this is on a RAMPS, so I'm really just poking fun. The point is, it happens.
