LinuxCNC S-Curve Accelerations

juliankoenig87 wrote:

I had the same things happining a while ago when I tested Michels s curve. In the end theese (exactly like your situations) were just "calculation errors" and he solved it by adding allowed dwviations. Pos_out got a allowed deviation of 1e-4 I think.

Like you see in my pictures he had imperfections too. Michels s curve code tested outside linuxcnc when I implemend s curve backlash compensation as a proof of concept.
 

G-code? config folder?

endian wrote:

grandixximo wrote:

@endian I discussed this with YangYang who attends the EtherCAT consortium meetings. AitalMAC is part of the consortium and we design I/O for EtherCAT, so we're not guessing here.
The standard already solves this problem. You don't need pos(t+1).
The 1 cycle delay is real, but it's identical for all axes. With Distributed Clocks everything executes on the same SYNC edge, synchronized to ~100ns. Every axis is "late" by the same amount, so the path shape is correct. Calculate it last week, execute it this week, the part is the same.
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.
If you're seeing ferror correlate with velocity in halscope, that's likely a display artifact. The ferror compares "commanded from 1 cycle ago" with "actual now", so it shows an offset proportional to velocity. It's not a real machining error.
What does your actual part surface look like? Any real deviation you can measure?
 
I think not every hardware has 0x60B1:01 in the accessible PDOs and not everyone can use unsynchronized SDO to change during OP ... therefore I am high-lighing it before job is done ... I have working with 16 different brands of servodrivers based on ethercat and just one it has(nidec control techniques) ... What I know from TC3 this is solved by NC stuff computing for the each single axis ... 

I do not want to talk about ethercat here .. we have separate space, but in reality it is lagging 2cycles because at hardare layer it writes command first and then it reads the slave status... then next cycle it write command by last status and then cycle it reach real status datas ... (Martin Rostan (Chairman ETG group) - when I was with him at last time at conference in Bratislava)

SDO 0x60C2 is configuring the timing of internal stuff of interpolationn of synchronized movement by subindex 01 and 02 .. most drivers it has to have it at same time of master command tick but we knows some which do not as Beckhoff AX5 series 

I am at second computer and I will update picture later this weel but during movement in 15m/s it can produce lag of 0.2mm with timing 250us ... which sound terrible 0

I did compensation component which add posCmd = position command + compensation during vcommand != 0 and every lag was gone ... it was purely for testing but solution is clear

positionOutputCompensated = positionOutput;
            
            if(fabs(vel_cmd) > 0.001)
            {
                double leadCycleLocal = lead_cycles;
                
                const double Ts = periodTime;
                const int    L  = (leadCycleLocal < 1) ? 1 : leadCycleLocal;
                const double LTs = (double)L * Ts;
                

                
                double lead = (vel_cmd * LTs) + (0.5 * acc_cmd * LTs * LTs);
                
                double ferr;
                ferr = (positionOutput - pos_fb_from_incremental);
                
                double comp = (kff * lead) + (k_err * ferr);
                posCompensation = comp;
            
                if(fabs(ferr) > fabs(fErrorOld) || fTopError == 0.0)
                {
                    fErrorOld = ferr;
                    fTopError = fErrorOld;
                }
            }
            else
            {
                posCompensation = 0;
            }
        
        positionOutputCompensated = positionOutput + posCompensation;
        
        if(ui_delayFinal > 0)
        {
            positionOutputCompensated = positionOutput;
            ui_delayFinal--;
        }
        
        //drv_target_position_incremental = (int32_t)(positionOutput * pos_scale * incremental_pos_scale);

        drv_target_position_incremental = (int32_t)(positionOutputCompensated * pos_scale * incremental_pos_scale);

 

 I think I understand better now, good to know this issue exists. When I get to Phase 5 testing at 250µs, I might see this show up as following error that isn't the planner's fault.I will bookmark this for later, is you compensation component available to test with?

ruediger123 wrote:

@grandixximo

During further testing, I noticed the following:

A sudden drop in jerkiness during acceleration build-up and deceleration, and a jerk greater than zero where there should be no jerkiness (red circles).
Cause?
tp.c
line 2836
"int need_decel = (margin <= TP_POS_EPSILON) || (dx - moveL <= dlen2);"

A brief exceedance of the maximum jerk value when acceleration ends (blue circles).
Cause?
sp_curve.c
lines 490 to 499
"if ((deltaV < 0 && targetV < v && v + deltaV < targetV) ||
      (0 < deltaV && v < targetV && targetV < v + deltaV)) {
    //nextA = (targetV - v) / t;
    nextA = 2.0 * (targetV - v) / t - a;
    if(nextA >= maxA){
      nextA = maxA;
      targetV = (a + nextA) * t / 2.0;
    }
    //printf("############################  FIXED nextA to be:  %.14f \n", nextA);
    v = targetV;"


I cannot say what is incorrect in the previous calculations.

gruß
Rüdiger
 

Did you test this? you have a patch we can look at? YangYang said those are both necessary, did you see what happens if you remove/fix the code you referencing as the causes?

 

I still get this at 100% feed override:

 

The ini file

 

(I set ini.traj_planner_type =1 by hand before starting)
 

PCW wrote:

I still get this at 100% feed override:

 

The ini file

 

File Attachment:

File Name: 7i96s-1kio.ini
File Size:7 KB

(I set ini.traj_planner_type =1 by hand before starting)

 

please see this, I have fixed the INI, we will fix code a bit so that we can support your original configuration as well, the issue was/is max_jerk in traj was set to 0, which is the default, but actually should not be allowed.

Yes, setting those ini variables fixed the issue.

Even at 10000 feed override (which showed on the screen as 0000)
 

grandixximo wrote:

@endian I discussed this with YangYang who attends the EtherCAT consortium meetings. AitalMAC is part of the consortium and we design I/O for EtherCAT, so we're not guessing here.
The standard already solves this problem. You don't need pos(t+1).
The 1 cycle delay is real, but it's identical for all axes. With Distributed Clocks everything executes on the same SYNC edge, synchronized to ~100ns. Every axis is "late" by the same amount, so the path shape is correct. Calculate it last week, execute it this week, the part is the same.
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.
If you're seeing ferror correlate with velocity in halscope, that's likely a display artifact. The ferror compares "commanded from 1 cycle ago" with "actual now", so it shows an offset proportional to velocity. It's not a real machining error.
What does your actual part surface look like? Any real deviation you can measure?
 
I think not every hardware has 0x60B1:01 in the accessible PDOs and not everyone can use unsynchronized SDO to change during OP ... therefore I am high-lighing it before job is done ... I have working with 16 different brands of servodrivers based on ethercat and just one it has(nidec control techniques) ... What I know from TC3 this is solved by NC stuff computing for the each single axis ... 

I do not want to talk about ethercat here .. we have separate space, but in reality it is lagging 2cycles because at hardare layer it writes command first and then it reads the slave status... then next cycle it write command by last status and then cycle it reach real status datas ... (Martin Rostan (Chairman ETG group) - when I was with him at last time at conference in Bratislava)

SDO 0x60C2 is configuring the timing of internal stuff of interpolationn of synchronized movement by subindex 01 and 02 .. most drivers it has to have it at same time of master command tick but we knows some which do not as Beckhoff AX5 series 

I am at second computer and I will update picture later this weel but during movement in 15m/s it can produce lag of 0.2mm with timing 250us ... which sound terrible 0

I did compensation component which add posCmd = position command + compensation during vcommand != 0 and every lag was gone ... it was purely for testing but solution is clear

positionOutputCompensated = positionOutput;
            
            if(fabs(vel_cmd) > 0.001)
            {
                double leadCycleLocal = lead_cycles;
                
                const double Ts = periodTime;
                const int    L  = (leadCycleLocal < 1) ? 1 : leadCycleLocal;
                const double LTs = (double)L * Ts;
                

                
                double lead = (vel_cmd * LTs) + (0.5 * acc_cmd * LTs * LTs);
                
                double ferr;
                ferr = (positionOutput - pos_fb_from_incremental);
                
                double comp = (kff * lead) + (k_err * ferr);
                posCompensation = comp;
            
                if(fabs(ferr) > fabs(fErrorOld) || fTopError == 0.0)
                {
                    fErrorOld = ferr;
                    fTopError = fErrorOld;
                }
            }
            else
            {
                posCompensation = 0;
            }
        
        positionOutputCompensated = positionOutput + posCompensation;
        
        if(ui_delayFinal > 0)
        {
            positionOutputCompensated = positionOutput;
            ui_delayFinal--;
        }
        
        //drv_target_position_incremental = (int32_t)(positionOutput * pos_scale * incremental_pos_scale);

        drv_target_position_incremental = (int32_t)(positionOutputCompensated * pos_scale * incremental_pos_scale);
 

 I think I understand better now, good to know this issue exists. When I get to Phase 5 testing at 250µs, I might see this show up as following error that isn't the planner's fault.I will bookmark this for later, is you compensation component available to test with?

 

 

I tested it with Nidec N753(it has 0x60B1 avaible - but i did not implement the offset yet), Kollmorgen S343, Kollmorgen S7xx, Pilz pmcTendo, Beckhoff AX5106 hw2(codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver - here is working driver for AX5YZZ drivers with sercos.comp which is very similar to dominik cia's but only for AX with external trapeziodal homing based of high speed probing hw-input outside of master[lower cycle time at fpga]), Beckhoff el7221 and I will test it with @zmrdko's Delta ASDA drivers too ...

pictures shows like that solution synchronize of timing lag of position mode of ethercat

endian wrote:

I tested it with Nidec N753(it has 0x60B1 avaible - but i did not implement the offset yet), Kollmorgen S343, Kollmorgen S7xx, Pilz pmcTendo, Beckhoff AX5106 hw2(https://codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver - here is working driver for AX5YZZ drivers with sercos.comp which is very similar to dominik cia's but only for AX with external trapeziodal homing based of high speed probing hw-input outside of master[lower cycle time at fpga]), Beckhoff el7221 and I will test it with @zmrdko's Delta ASDA drivers too ...

pictures shows like that solution synchronize of timing lag of position mode of ethercat

Can you show the same test at same velocity with compensation on and off? The two pictures are at very different speeds so it's hard to see what the compensation is actually doing.

I tested it with Nidec N753(it has 0x60B1 avaible - but i did not implement the offset yet), Kollmorgen S343, Kollmorgen S7xx, Pilz pmcTendo, Beckhoff AX5106 hw2(https://codeberg.org/endian/Beckhoff_AX5ZYZZ_lcec_driver - here is working driver for AX5YZZ drivers with sercos.comp which is very similar to dominik cia's but only for AX with external trapeziodal homing based of high speed probing hw-input outside of master[lower cycle time at fpga]), Beckhoff el7221 and I will test it with @zmrdko's Delta ASDA drivers too ...

pictures shows like that solution synchronize of timing lag of position mode of ethercat

Can you show the same test at same velocity with compensation on and off? The two pictures are at very different speeds so it's hard to see what the compensation is actually doing.
 

 

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

endian wrote:

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 , I discussed this with YangYang. We agree this is a real issue on some hardware, but it should not be in the TP.The TP's job is to generate a geometrically correct path with proper dynamics. It does that. The path is correct.Transport delay compensation is a communication/hardware layer problem. Different drives, different bus cycles, different delays. Some drives have 0x60B1, some don't. Some run 250µs, some run 1ms. This varies per setup.Your HAL component is the right approach. It sits between TP output and drive input, users can tune lead_cycles and kff for their specific hardware. People who need it use it, people whose drives handle it properly don't.Keep the TP clean, keep hardware compensation in HAL. Well defined purposes.