Hello all

I am using an AxisGroup with the Gantry2 Kinematics to move a 2D-Gantry system. When creating the AxisGroup, the SoftMotion_PlanningTask is created automatically with a cycle time of 2 ms in my case. I realized that the maximum cycle time of this task can spike to very high values (up to 60 ms) at lower speeds of the motion, leading to synchronization issues and errors on the axes. The same behaviour - though not as drastic - can be observed with virtual axes too.

Is this behaviour intended or to be expected? Can the cycle time or type of the SoftMotion_PlanningTask be changed to prevent these errors? Or is there another fix for this issue?

I tried changing the cycle type to Freewheeling, which solved the synchronization issues, but caused an error on the AxisGroup after a while, reading SMC_CP_QUEUE_UNDERRUN.

Thanks in advance and best regards
Manuel

Hi,
which (kind of) PLC do you use?

Hi

These issues occured using a Raspberry Pi 4.

I also repeated the experiment with codesys control for Windows, which results in much lower cycle times. With up to 3 ms, I still think they are fairly high given they should run at 2 ms and don't require complicated kinematics. The effect of higher cycle times for slower movements also prevails.

Hi,

you need a realtime capable plc. Codesys Control WinV3 is not realtime capable.
https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_performance_optimization_linux.html

The last chapter of https://content.helpme-codesys.com/en/CODESYS%20SoftMotion/_sm_robotics_diagnosis_movement_problems.html deals with how to configure the planning task.

Hi,

we did install the real-time kernel patch on the RPI and also performed the additional optimizations including isolating the cores.

Changing the configuration of the planning task e.g. running it on a separate core, changing the cycle times and mode from cyclic to freewheeling did not show any improvements.

Hi,

under this circumstances the performance of a Raspberry Pi 4 should be sufficient to run a Softmotion robotics application.

A closer look at the project would be required. Maybe you could contact the codesys support?

Usually it is recommended to run the planning task cyclically every 2ms with task priority of 0 on a dedicated core.
In the task configuration you can have a look at the average and maximum execution time of the planning task. You could use the function block SMC_TuneCPKernel (https://content.helpme-codesys.com/en/libs/SM3_Robotics/Current/SM3_Robotics/POUs/AdministrativeConfiguration/Computation/SMC_TuneCPKernel.html) to define suitable values for the parameters 'fSyncBufferDuration' and 'fPlanningInterval'. However, as previously mentioned, the performance of a Raspberry Pi 4 with realtime patch should be sufficient.

The 'fPlanningInterval' parameter specifies the maximum planning step width in seconds. The cycle time of the planning task should not permanently exceed this value. A higher value reduces the computational effort, but can lead to a violation or no full utilization of the set limit values for velocity, acceleration and jerk. From a starting value of 0.016 seconds, the value should be increased gradually until the performance is acceptable.

The parameter 'fSyncBufferDuration' specifies the size (in seconds) of the buffer between the planning and fieldbus task. The cycle time of the planning task must not exceed this value at peak times (this will lead to the error SMC_CP_QUEUE_UNDERRUN). A higher value can compensate for peaks in the cycle time of the planning task. At the same time, however, this also increases the latency for executing interrupts and aborting movements.

Hi, thanks a lot for the response. I did check all these parameters, but if the PlanningTask takes up to 60 ms, I can't increase the Buffer to such values. I contacted the Codesys support with a projectarchive. Let's see if they can help.

Thanks again for your great support!