LinuxCNC S-Curve Accelerations

arvidb wrote: But making interpolation the responsibility of kinematics and keeping the feature seems like a better idea!

Of course this assumes that I've drawn correct conclusions about the purpose of the cubic interpolator; that coord_tp produces a trajectory that is suitable for use without being filtered by the interpolator. That remains to be seen I guess.

Anyway, first step is to get jerk-limited joint jogging to work, and that doesn't require touching kinematics or interpolation at all. I think I have enough understanding of the code at the moment to get on with that.

arvidb wrote: We are at a lower level than line or arc segments here, in emc/motion/control.c. Look at the code starting at line 1309, case EMCMOT_MOTION_COORD. If the cubic interpolator needs a new point, tpRunCycle() and tpGetPos() are run on coord_tp to get a new cartesian position command (carte_pos_cmd). This is run through inverse kinematics. The results are assigned to the respective joint's coarse_pos member, and are also fed into the cubic interpolator.

Then as a final step the actual "fine" joint position (joint->pos_cmd) as well as velocity and acceleration commands are gotten from the cubic interpolator.

I haven't looked into the cubic interpolator, but maybe this significantly reduces the cpu load by running the inverse kinematics much more seldom than otherwise needed? It looks like it isn't run at the servo rate after all (unless the interpolator requests a new point every cycle).

After some more code reading: The "traj period" is a parameter to motmod.so. It is set to the servo period if not specified .

This ends up in the interpolator via github.com/LinuxCNC/linuxcnc/blob/master...otion/motion.c#L1019 resp. github.com/LinuxCNC/linuxcnc/blob/master...otion/motion.c#L1050

Ok, so this explains why the output from teleop_tp is run through the interpolator: it allows to run inverse kinematics at a lower rate than the servo thread, during axis jogs, by specifying traj_period_nsec to be larger than servo_period_nsec.

Then a new question arises: is this feature still meaningful today? The only reason to use it that I can see is if inverse kinematics is too slow to fit in a servo period, and then you'd get a realtime delay in the servo thread each time the traj period is reached anyway.

I think in this design, inverse kinematics should always be able fo finish within a servo period. Maybe on a single-core machine with "non-trivial" kinematics you wouldn't have enough CPU time left to update GUI or do other userspace-stuff. I don't think that is of any concern even on older multicore CPUs.

Something off-topic: is it just me or do quotes in the forum really look strange?

rmu wrote: Something off-topic: is it just me or do quotes in the forum really look strange?

Yea, the lettering gets bigger.

tommylight wrote:

rmu wrote: Something off-topic: is it just me or do quotes in the forum really look strange?

Yea, the lettering gets bigger.

And that keeps happening ....

Hi, Tommy,

Did you clicked twice?

I think in this design, inverse kinematics should always be able fo finish within a servo period.

That can be done for (simple) interpolation algoritmes, like xyz.
For robot's (more complicated kinematics) there are ca 120 iterations preferred each cycle. The approach of designing it for a single servo period would result in a slower to set servo-period.

Then as a argument, the "look ahead" integration stay's important. And the s-curve algoritme must be added to the above mentioned itterations.

Coming day's i hope to finish a s-curve position control with a look ahead buffer in ms.

I hope to construct some kind of dynamic code that can fill up the buffer when the kinematics are easy to solve.
When the buffer is full and kinematics are complex,
the machine is at full load, then it will do a auto slow down to get optimized results if the programmed speed can't be reached.

It's quite a hard job to modify the lcnc code. Respect & Good luck !

Grotius wrote: Did you clicked twice?

Nope ... but i did reply twice as sometimes that causes the letters to go even bigger!