LinuxCNC S-Curve Accelerations

My apologize ...
sorry I can not show same speed test because I am currently weeks out of office but we can just multiply or devide values ... because it is linear dependecy during constant speed movemet ... 

I can just customize current images to show exact difference ...  compensation off ferror = 0.125mm at 15m/min ...  compensation on ferror = 0.00009028mm at 1m/min and multiply it by 15 we get 0,0013542mm which is significantly less then 0.125 ..

What I remember from testing by my short eyes it whas something near 0.001mm during that 15m/min testing was done with bentch top setup without any load presented... just AX5106 with AM8xxx motor 

but I can go home for testing this weekend to create exact speed difference testing if it is neccessary

No apologies needed [img]/media/kunena/emoticons/wink.png[/img]

 

grandixximo wrote:

The CiA 402 standard provides feedforward objects exactly for this: 0x60B1 (velocity offset) and 0x60B2 (torque offset). The master can send position plus velocity feedforward so the drive can anticipate acceleration. This is the standard's solution, it just needs to be mapped in lcec.
Also, good drives interpolate internally. The servo loop runs faster than the bus cycle (Maxon runs 0.4ms internal vs 1ms bus). The drive doesn't jump between positions, it interpolates. That's what 0x60C2 configures.
 

grandixximo wrote:

The pins already exist:

joint.N.vel-cmd - velocity command per joint
joint.N.acc-cmd - acceleration command per joint
joint.N.jerk-cmd - jerk command (useful for S-curve)

These are updated every servo cycle after cubic interpolation, so they represent instantaneous commanded values suitable for feedforward.
For your cia402 component rewrite:

0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly
0x60B2 (torque feedforward) needs joint.N.acc-cmd × inertia, you can do this with a mult2 in HAL or inside your component

No TP changes needed. Just wire the existing pins to your component and map them to the PDOs.

At the moment only joint 0-1-2 jerk-cmd is calculated proper I think, later on we will do all.
 

endian wrote:

0x60B1 (velocity feedforward) can use joint.N.vel-cmd directly - is equal of FF1 of PID which already exist and its widely used to compensaty cycle delay ... this stuff is from my point of view useless for now

but I am still taking just about pin which allready read position from allredy presented 50ms buffer .. you are providing us from sTP posCmd(t), velCmd(t) (command speed is compensated cycle with PID FF1 and we do no use 60B1 for now), accCmd(t) and jerkCmd(t) and we need for ethercat posExtraCmd(t+2) for ethercat devices which is running in Constant Synchronized Position mode because of absention PID and therefore FF1 absention too (2 cycle lag present of ethercat) - this is just array position value which allready exist in buffer because of time(you notice 50ms) precalculation ... 

and I know this is topic connected with ethercat but it is directly connected to trajectory planner ... Beckhoff, Codesys, Deltaww it has implemented as I said because their native bus is ethercat ... 

vel_cmd * dt + 0.5 * acc_cmd * dt²

rodw wrote:

Very good stuff! I made a start today forum.linuxcnc.org/ethercat/58260-lichua...r-need-help?start=20
is dt = Delta time = servo period?
I'll have to follow you guys a bit more closely!