Please provide a minimal example of MCU Command: `queue_step`?


I’m trying to acheive a low response time equivalent of LinuxCNC’s Python Interface jog command, which has this signature: jog(command, jjogmode, joint_num_or_axis_index, velocity[, distance]])

So, I think I need to send MCU Commands: MCU commands - Klipper documentation

For example, if I wanted to run these steps on the X-axis motor:
x_step_durations = [2000 - pow(10*i, 1/2) for i in range(200)] # in micros

I’d send 200 MCU Commands:
queue_step oid={oid} interval={duration} count=1 add=0

I don’t know how to get oid, and I don’t know how to go about sending this message. I was hoping to get a minimal example of how to do that from a Python script.

Also, I understand that there is step compression - is that something I could feed this list to, and get something more optimized?

Or, is my question naive or lazy in some way? Is there another approach entirely I should be taking?

1 Like

I’m still looking for a solution for responsive joystick control, and don’t have a much better idea than this.

I’ve also tried asking here: How best to code manual jog with keyboard or joystick?

You may have a look here Real time control of a Voron 2.4 using a gamepad especially koconnor’s answer.

Good luck, hcet14

@hcet14 It seems to read, “give up”. :frowning:

I’ve done responsive keyboard/joystick control of multiple steppers from scratch, multiple times, on Arduino. I feel like, if I could get under the complexity of klipper, to send individual steps to each motor, I could get done what I need to. However, I don’t understand klipper well enough to know if that’s so.

Do you want to add this behavior to klippy, or to make a complete host replacement for jogging?

In klippy the queue_step commands are generated by an iterative solver that follows the motion of a trapezoidal queue. The (velocity) trapezes are generated by the move planner in It ensures that the toolhead can be stopped after the “event horizon” of the gcode it already had access to.

I wouldn’t recommend bypassing all of it, it is likely easier to reuse the reusing the solver, kinematics and trapq. But you’ll have to figure out how to fill the trapq (and possibly how to update it), while ensuring that the toolhead can reach standstill from all steps in the way.

I’m not sure.

I think that most of Klipper does not apply to how I want to use it, and may even get in the way. I would really like to avoid writing kinematics, g-code parser, etc., if possible.

The machine I’m controlling is a photography rig, with a stage that has 3 rotational axes, and a camera that has 3 positional axes. I have other weird machines that I want to control next. I’m mostly setting up waypoints by manually driving to them them with joystick, then having the machine smoothly go through the waypoints.

Klipper may be the wrong tool for the job. I’m really looking for a programmable motion platform for developing robotics projects, where the motors/joints are sometimes manually controlled with joysticks.

I would wholeheartedly agree to this statement. Klipper is a 3D printing firmware and as such has way different requirements.


Welcome to my club :wink:, but that’s why I follow this forum. Hopefully the followed replies helped you.

Ok, thanks for letting me know!

If anyone has a better solution, please let me know. Right now, LinuxCNC seems to do what I want, but it requires so much hardware that it’s prohibitively large and expensive, for my plans. The way klipper can use 1 computer to control many MCU’s, most of them 3d printer control boards, is what I want.