LinuxCNC S-Curve Accelerations

The "Cannot reset free planner position while in motion" error means that LinuxCNC does things to the planner while homing that I did not anticipate. This is one of the things I wanted to have tested and is very valuable information - thanks! It means I have to look more closely at that part of the code. There is no quick fix unfortunately; it will take some time: I have to set up some kind of testing rig and figure out how to handle these cases.

---

A good parameter to look at would be joint.N.acc-cmd. Without a jerk-limited planner you will see step changes (or just a flat line - so trigging best done on joint.N.vel-cmd) while jogging a joint. With smooth1d you should see a gradual, linear change in acc-cmd.

But again, at the moment I've only replaced the joint jogging planner, so you will not see any difference on axis jogs nor on coordinated motion, i.e. while running a G-code program. Only on un-homed joint jogs.

hI arvidb
Wanted to know if progress in work?
What equipment do you have to check it? Mesa, ethercat driver or any else?

Hi!

I have EtherCAT servos running with LinuxCNC and also a Mesa 6i25+7i77 combo and analog servos that I can hook up. But I don't have a machine to hook them to. For testing the current issue I need an actual axis including limit switches, which I'm putting together - I have linear rails, ball screws, switches etcetera. But I don't have access to a workshop (I live in an apartment) so it's a bit slow going. Can't make too much noise, weld or do heavy metal working etc.

Hi,
I just ran across some new research for Jerk limited trajectory generation.
arxiv.org/abs/2105.04830
The code is MIT licensed and available at:
github.com/pantor/ruckig
Looks like they are solving cubics and quartics in realtime ( and by the looks of it without iterative methods).
-automata

That's a great find automata! Thanks!

They do use the same iterative method to find roots that I do - Newton's method. However through further mathematical rigor they seem to have managed to "box it in" so that it guarantees a solution (they make sure to constrain each run to a section with one and only one solution, which ensures convergence).

Overall the algorithm is actually pretty close to mine, but having it formally analysed and described is super valuable - for squashing those last bugs but even more for maintainability! And also for peace of mind regarding robustness. This is great! *woohoo!*

In addition, they extend the algorithm to multiple synchronized axes which could be interesting for jerk-limited jogging of homed machines not using trivial kinematics!

One (hopefully minor) snag is that their algorithm seem not to solve the type of trajectory that you'd get if you start a move and then return to the starting point - say turning a jog wheel one click forward and then immediately back again, before the move has finished.

Anyway, I'll definitely look very very close at this once I've solved the homing/integration issues detected by TheRoslyak.

Hi,

I did a 6-DoFs implementation of the library into a hal component. And it seems to work.
github.com/grotius-cnc/hal_trajectory/blob/main/README.md