LinuxCNC S-Curve Accelerations

PCW wrote:

I can not test that as it requires EtherCat hardware.

I think you could just create a normal pncconf config for your hardware and set the ini file tpmod etc to use the scurve planner.
Once configured Linuxcnc does not care if its Ethercat or mesa.

I looked at the sim config an edited a mesa config to add the new TP, but it does
show major acceleration spikes (~500K)  lasting 1 servo period. I needed to set
large  following error limits  to avoid the spike triggering a following error.

Note that this is not hardware related but may have a relation to scaling so I can try again
by modifying the sim config to make sure everything else remains the same.
 

it worked on my Delta B3 Ethercat servos using CIA402/CSP config (see attachment).
i used linuxcnc-scurve-compat  from codeberg.

OK it does work, my test configuration was missing the
default/max velocity and accel settings in the TRAJ section
of the .ini file. This (missing values) seems to work with the
standard TP (maybe it has some kind of working defaults)
but fails with  the S-Curve TP.

Note that I can still trigger following errors with actual
hardware as  the S-Curve TP does not seem to obey joint
acceleration constraints.

The TRAJ and joint accelerations are both set to 200 here:

 

But that acceleration is exceeded (and trips a following error when
it exceeds the hardware's accel limit of 240)

Pcw,

Thanks again for your effort.

What do you advise at this moment?
You can tune the planner with scurve jerk value in the hal section. This changes the accelation profile.
This jerk value is not integrated to the .ini file so far.

I assume you could tune your ini config to run without following error? Or is this not the case?

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

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

I will try this, note that this is a difference from LinuxCNCs standard TP where the
acceleration bound in the ini file is obeyed at all points.
(unless you have backlash compensation enabled)

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.