Other systems do more that just put the command at the top of the queue. They actively run commands simultaneously.
E.g. babystepping runs concurrent with the current move. The Z move is applied to the next step with no accel/decel. If you don’t do this, then a calibration print that has long slow moves would complete those moves before babysteps were applied. This is not what I expect as a user of Marlin/RRF. Putting the commands in the top of the queue doesn’t fix this.
Klippy is running ahead of where the machine actually is in time so its movement queue can actually processed before your command is even issued. This can make klipper “feel unresponsive” when you make an adjustment during a print. Largely how responsive klipper feels is down to how long the moves are that are executing at the time.
So you really need:
- A separate user input queue that can run simultaneously with the print queue
- Customization of many commands to run concurrent with the existing movement queue in a way that users expect (but also doesn’t break things).
- Possibly reaching all the way to the MCU to make changes immediately.(babystepping, speed adjustments, flow multiplier etc.)
Thats very hard to implement. I’m not saying that we shouldn’t do hard things, we should. But the fix is not simply tweaking which end of a queue the commands go into.
(I very naïvely thought I could fix this once, and I was wrong about how hard its going to be)