Limit4 hal component used to limit the jerk

Hi,

I am using Linuxcnc to control some motors. Linuxcnc send position commands to their drivers through an ethercat loop. I was wondering if their is a Limit4 hal function that I could applied to the position command. This way I would be able to add an additional jerk limitation, ie a limitation of the time derivative of acceleration, which does not exist yet in the trajectory planner.

I want to do this in order to reduce the following error during acceleration and decelleration phase because the LinuxCNC trajectory planner uses a step signal for the acceleration going from 0 to amax in one thread step to compute the planned commanded position. This creates a really high jerk, which cannot be followed by the physical system at the begining of the motion. So far my motors have been tuned with their drivers to reduce the following error during the cruising phase (following error equal to 0) and during the acceleration fairly good but still significant for the accuracy trajectory I want to get.

Thank you for your answer.

Nicolas

Do your drives have built in jerk limiting?
Unfortunately even if Linuxcnc had I am afraid it might not work quite as well as you are hoping. It would only be functionally equivalent to having jerk limiting enabled in the drive.
Either way it is going to cause an uncompensated following error, until the drive can catch up with the commanded position.

The only real work around is to lower the performance envelop, by reducing accelerations in Linuxcnc enough to minimize errors caused by jerk (keeping accelerations high in the drive).

Unfortunately until jerk-limiting is added to the motion planner. Linuxcnc isn't a really great option for an extremely high performance (read this as very fast) high precision machine.

Hi,

my drives have built in jerk limitation. Though it would have been an improvemenet to put the linuxcnc jerk limitation at least at the same level or lower than the drivers. For jog motion I think it would in this case reduce the acceleration/decceleration following error. For motion achieved over the trajectory planner (running a Gcode file) as you explained it might not work as I would hoped.

I just need a clarification. Does the trajectory planner takes into account the feed back position, especially when it is ordering a new move on a corner for example?
-If yes it means that a limit4 function added on the command position can have a following error reducing effect. The trajectory planner would wait the system to reach the different position planned which would be jerk limited.
-If no it means that the following error would probably get worst as it will generate an uncompensated following error, the commanded position being jerk limited but the trajectory planner moves ordered being not.

For now I will keep the acceleration at the same level accepting the following error and reducing the acceleration if I need high precision application.

Thanks again for your answer.

Nicolas

To the best of my knowledge the answer is no. If it did then the jerk limiting in your drives would not be causing any problem.

As it is I think the best solution is similar to how a stepgen is usually configured, by programming the max acceleration in Linuxcnc to be about 25-50% lower than the max acceleration in your drives. That way any following error caused by the drives jerk limiting is quickly taken up by the drives higher acceleration. (Also keeping the jerk limiting to a minimum.)

Another possibility, would be trying to use the old trajectory planner's parabolic blending scheme. By it's own nature "is" jerk limiting, to an extent. The problem is depending on your g-code the old planner's one line look ahead planning limit, could be more of a speed restriction than just lowering acceleration so jerk isn't as significant with the new planner.

Check if your ethercat drives differ between Trapezoidal and S-curve Motion Profile.

S-curve profiling limits jerk or “smooths” the motion.

EtherCAt move interpolation time can be also of importance.