Using Klipper Board for non-3D Printer (CNC) Applications?

Hi All,

Edit: Revised title to distinguish between CNC (precompiled G-Code) and non CNC (real time control) applications.

I’ve been working with 3D printers for years. I’ve had several printers, modified most of them, and built one from scratch - though I’ve never used Klipper.
Now though, I have a non-3D printer application, and Klipper seems to be becoming the flavour of choice for 3d printer boards.

My application is a camera pan-tilt-slider (3 axis). I would like to control the device with a physical hand controller OR via a programmable web interface. The intention is to use a raspberry pi as a primary controller, then I would pass instruction to a 3d printer board to drive the stepper motors including homing functions.

As I understand it, this should be possible, but I can’t find any information on implementing this.

Ideally, I would use one of the more modern Klipper boards from Aliexpress (Mellow, BTT etc)

Any suggestions?

Thanks in advance.

If you want realtime control over the device with the hand controller, Klipper is not a good choice.

Thanks for the response. The intention would be to interpret hand controller inputs with a raspberry pi, then feed instructions to the Klipper board. To simplify the problem - ignore the inputs to the raspberry pi. Is there a way to stream commands (G-code or other) to a klipper board? To be honest, I thought that was the entire premise of Klipper… forgive my ignorance if that’s not the case.

Klipper is a two part firmware. Host software on the Pi reads gcode and sends compressed step commands to the MCU on the control board. This involves a buffer which would cause a noticeable delay between command and move. Not a problem for a 3D printer executing a gcode file, but not great if you’re trying to control a camera. It would be fine for running a preprogrammed gcode though if you wanted a specific panning shot.

That makes sense - I guess there would be some element of buffer management to avoid lag as you say. The commands you input from a hand controller would be far fewer than what you get from a sliced print file, so it wouldn’t take long to get through the buffer. This would require some consideration, but I don’t expect it to be a show-stopper.
Preprogrammed paths is my primary goal - it will bea timelapse photography rig that works in a move-shoot-move manner, so in this case, a buffer would not be an issue. But I want to pick a design pathway that allows future expansion and alternative use cases.

Do you know where I might find information about sending it raw g-code commands from a raspberry pi that isn’t using the host software?

EDIT - Scrap that - I should have read the documentation first.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.