LinuxCNC S-Curve Accelerations

@grandixximo

After commenting out " || (dx - moveL <= dlen2)", the scope looks like this.

 

test with this, this is dlen2 code

 

this is without

    

we know is not ideal, but at the moment, best we can do

Code:

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]

 

I can understand You and YangYang, its added job, but I openly disagree ... its the best time to improve lcnc and solve it at native level for ever, no other proforma hobby solution as now my is...

it should be solution for everyone who not understand it soo well as you guys... my solution of compensation will be even more inaccurate when scurve will be done and implemented ... 

I can not say you what to do, your job, your rules, your output ... thanks for your upgrade to curving
 

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.
 

Can we explore this on another topic when I get to it? I wanted to rewrite dominic's cia402 component to make it easier to maintain and properly deal with homing so it comes into line with the custom homing that wasn't around when it was written. So it would be perfect for inclusion. Could the new TP have output pins that could be taken as input to calculate these?   Or how would we do it? Any conversion/massaging would be done in the revised component.

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.

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.
 

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 ...