LinuxCNC S-Curve Accelerations

Indeed if you set acceleration to 200, the scurve max acceleration will be 400 at inflection point.
Exceeding your max acc off 240.

I get the same error even if all accelerations are set to 100 in the ini file

@Pcw,

Thanks for reporting this.  For now i will keep this in mind, and will test this later on.

The [TRAJ] section is responsible for setting the planners max-acceleration values.
The planner doesn't look at the individual joint max acceleration values. Maybe that is causing trouble.

@All,

Ok, for the cia-402 component i made a home sequence intrusion in the homemod.so component.
It basicly enables external homing, and not triggering following error etc during this procedure.
All is done with a few hal pins.

When using the servo's internal home sequence the lcnc home sequence can now be done by a connecting a few hal pins.

For each joint, you can activate the cia-402 home sequence.
In this way, a non cia-axis, can be homed by lcnc's original method as usual.
 

1. You can set pin for enabling the cia-402 internal servo drive home sequence.
Set this flag "setp" in the .hal file after you load the cia component for example.

2. The cia-402 recieves a home command from homemod.so
Connect the cia-402 home command pin (input) -> homemod home-drive (output)

3. The cia-402 servo pos feebback is passed to the homemod.so when the servo is homing and changing position.
Connect the cia-402 pos-feedbak (output) -> homemod.so pos-fb

4. When the cia-402 drive is homed, it updates a flag in homemod.so wich set homed = 1.
Connect the cia-402 is homed flag (output) -> homemod.so drive-is-homed.

libhome

source code intrusion

Sinds i have no cia hardware, i tested this ok in a linuxcnc simulation config.

I did set the acceleration in the TRAJ section, it does affect the acceleration
but the scaling seems not to be correct. The Acceleration/Velocity bounds are important
since they are per joint physical limitations.

(sorry if I am getting out the sandpaper when construction is at the chainsaw stage)

It is great so see  a jerk limited profile working with LinuxCNC as it fixes the inevitable
following error at the start/end of motion due to the impossibility of having instant force
application in any real drive system.

Hi Pcw,

Can you try once more with Mesa?

In the repository :
git pull
cd cmake
./build_cmake

Added pins to monitor at runtime:
tpmod.hal_component_max_cycle_time_ns
tpmod.hal_component_max_cycle_time_scurve_ns

Param to start with, also influences max acc :
tpmod.hal_max_jerk = 5

Then the above pins must stay below ~50000 nanosec at runtime.
Everything above 1000000 ns is bad.

We have now 3 configs wich run scurve. 1 is in Slowakia and runs like a rocket on delta servo's.
My ethercat steppers run, but not optimal as my desktop pc has bad latency. Base thread & ethercat apptime = 80000
Another machine is in Italy and had bad .hal config wich broke the scurve at runtime. Now that is fixed, it run's.

Will test today or tomorrow.

Hi Pcw,

Thanks for your fast responce.

We have an issue on codeberg. I invested today to find why the scurve some times breaks. We then see a
vertical line in the plot of tpmod.curvel.
The curve kind of starting from vel=0 again. Jumping etc.

It seems if my base thread is set to 50000 (too fast),
the scurve lib is not able to finish the algo anymore. Resulting in strange behaviour.
Like a sqrt() function taking about 1 ms to complete, wich is absolulutely madness.

Now if i set the base thread to 80000. Everything goes fine.
So i thought, better you know this also.

The guy in italy had 6 axis ethercat running, very difficult .hal setup, constantly breaking the scurve every move,
even without clothoids.

So now i helped him with remote desktop for hours. And now with a simple config he runs ok. We don't know
his cause exactly. But we are happy the problem is gone now.