MarlinFirmware / MarlinFirmware/Marlin
[FR] Support custom kinematics (e.g. non-linear delta)
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 17.6k
- Forks
- 19.7k
- Avg merge
- 3d 5h
- Merged PRs (30d)
- 21
Description
### Is your feature request related to a problem? Please describe.
I have built a delta 3d printer prototype which is not a "linear" delta, and encountered some issues while adapting the kinematics computation. But I managed to get it to work (at least partly).
### Are you looking for hardware support?
No
### Describe the feature you want
Marlin supports several kinematics like cartesian or linear delta, but it would be nice if it was possible to add *any* kinematics in a modular way. Currently this is not straightforward because several parts of the code make some implicit assumptions based on the set of supported kinematics. One such assumption is the relation between Z direction and steppers directions. Another is a linear mapping of Z-only moves between cartesian coordinates and stepper coordinates.
A related feature request is #25617. There is also #7679, but it didn't receive as much feedback.
### Additional context
While trying to get my new "radial delta" printer to work, I started to adapt Marlin to my case, by changing `inverse_kinematics()` (as suggested by @Graylag-PD), as well as `forward_kinematics_DELTA()`.
I would like to share a few issues that I had to address (in Marlin 2.0.8):
- In endstops.cpp, `Endstops::update()` tests for a subset of endstops depending on stepper travel direction and kinematics :
```
if (stepper.motor_direction(Z_AXIS_HEAD)) { // Z -direction. Gantry down, bed up.
[...]
else { // Z +direction. Gantry up, bed down.
```
This has to be adapted. In my case, increasing Z moves all steppers toward the "min" endstops, while decreasing Z move toward the Z min probe (I had a few crashes before understanding this).
- In motion.cpp, `update_software_endstops` has a delta-specific section which does some software endstop and `delta_clip_start_height` computations, only valid for a traditional linear delta, and `set_axis_is_at_home` also adds the Z probe offset to all stepper axis positions, which is again linear-delta specific.
- In motion.cpp, `line_to_destination_kinematic()` and `segmented_line_to_destination()` skip the segmentation for Z-only moves, as an optimization. This is based on the assumption that Z only moves translate linearly to stepper coordinates, which is true for both cartesian and linear delta printers, but not in my case.
There may be more places that need to be adapted that I haven't found yet, but those at least require attention for implementing exotic kinematics. I'm not able to contribute a full abstract kinematics feature to Marlin, but maybe my findings can at least help someone with similar needs to save some time !
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading endstops.cpp at Endstops::update() and motion.cpp at update_software_endstops, set_axis_is_at_home, line_to_destination_kinematic(), and segmented_line_to_destination(). Compare the existing linear-delta assumptions with the reported radial-delta behavior and inspect related issues #25617 and #7679. Done requires defining a modular path for custom kinematics that addresses the listed direction, endstop, positioning, and segmentation cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- embedded-iot
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100