I have recently been working on a motor control project using Klipper, and after hearing from a printer developer, I am now studying to add support for a laser galvanometer. Of course, since I am not a professional developer, it will take a long time, but I believe that, given Klipper’s architecture, I can attempt this by modifying the firmware (src), adding Python modules, specifying pinouts, and replacing the kinematics.
I was wondering if there have been any research efforts, projects, or discussions regarding such an implementation. As far as I know, SLS4ALL only modifies the firmware (src) part of Klipper and uses a different control solution. I would like to confirm whether Klipper has the potential to support such a structure and whether my understanding is correct.
Not sure what you are talking about,
Klipper was created around stepper motors and cartesian coordinates.
So, technically, gcode is decoded, and added to the queue, and there motion planner creates moves from it, then it travels beneath to chelper, where itersolver calls kinematic code solve equations and generate step timings, which later happens to be transferred to MCU.
MCU just executes simple actions on time, like make a pulse on a step pin.
Firmware has no idea what is under control.
That is it.
As said in the endless attempts to do something with that, well.
If you want to support something different, then step/dir, there possible should be a decoder of pulses, which will in the end drive your drive.
If there is a different equation, like the laser galvanometer is fixed, and only angles and Z high changes - then there is an additional kinematic code needed.
I think it will be similar to delta kinematics in some way.
So, would it be correct to understand that I should write the necessary commands in a way that they can be added to the motion planner queue, while the firmware simply acts as a pass-through for communication? And similarly, any abstraction, pin initialization, and other configurations should be implemented as Klipper modules?
So, would it be correct to understand that I should write the necessary commands in a way that they can be added to the motion planner queue
I’m not sure that I fully understand what you mean by adding something to the motion planner queue.
If you plan to do that, you will need to replace high-level Python code with motion planning as far as my understanding goes.
while the firmware simply acts as a pass-through for communication
Generally speaking, firmware is always “pass-through”, klipper just schedules what and when will “pass-through”. The only exception is bulk sensor integration (like accelerometer data reporting) and homing procedures, which are integrated into the MCU.
And similarly, any abstraction, pin initialization, and other configurations should be implemented as Klipper modules?
Yes, most of the time, it is simpler and better to do so in a high-level code.
You can easily look at any sensor integration to grasp an idea and choose one that you are more familiar or simpler to understand.
Simple example any i2c temperature sensor.
An “ultimate” example is a TMC drivers integration.
You might want to start at Code overview - Klipper documentation to gain the relevant understanding. Kinematics and similar is also touched in the following chapters.
I apologize for not being able to test and respond immediately due to some recent busy matters. I review and apply all responses irregularly, and I truly appreciate your kindness as always!