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.


 

Hi Pcw,

To inform you.

I just synchronized the codeberg lcnc to github's lcnc codebase.
I did messed up some hal source code when trying things out, wich resulted in a non starting simulation config for "run_axis_9".
This is now reverted.

Is there a different repository? Just did a git pull
and got: "already up to date"

Hi Pcw,

Its still this one : codeberg.org/skynet/linuxcnc_scurve_compact

I did a forced upload yesterday, resulting the git history is whiped out.
Otherwise maybe to be sure : git clone --recurse-submodules codeberg.org/skynet/linuxcnc_scurve_compact

If you see the new hal pins appearing, it's ok.

I really hope you can run a few motions.



 

hi all
i tried to install in 3 different computers with no sucess, all of then was working linuxcnc installed. in the last one it says it could not find tpmod_scurve.so. i was able to run the previous versions, so i copy this file from a previous installation and was able to start in simulation mode but those new hal pins didnt apear to me.


edit
solve the problem moving files from clothoid_3d and scurve to their lib directories.

edit 2
cant run ethercat

when installing  linuxcnc-ethercat this error apears

/home/cnc/scurve2/linuxcnc_scurve_compact/linuxcnc-ethercat/lcec_rtapi.h:22:10: fatal error: rtapi.h: Arquivo ou diretório inexistente
   22 | #include <rtapi.h>
      |          ^~~~~~~~~
edit3
it runs on ethercat now but i cant start a gcode, it says

task: main loop took 0.023097 seconds
tpAbort.
tpAbort.
task: main loop took 0.070196 seconds
tpAbort.
tpAbort.
task: main loop took 0.044852 seconds
task: main loop took 0.011368 seconds

Then the above pins must stay below ~50000 nanosec at runtime.
they all stayed below 50000 nanosec