What is the maximum allowable jitter on a CPU controller for motion control? In our testing on an IPC with Codesys runtime, we cammed 31 virtual slave axes to a virtual master and noticed peak jitter of approximately 200µs – a concerning figure. The motion instructions operate on a cycle time of 2ms, with minimal controller code to ensure smooth camming operation. This preliminary setup uses virtual axes, with plans to eventually connect physical drives on Ethercat.
You are correct in noting that a 200-microsecond delay is far too excessive, making it impractical to employ derivative gain and resulting in non-smooth target trajectories. I personally prefer no delay at all. Utilizing a FPGA allows for the use of virtual axes to access the cam using cubic splines. It seems that the slave axes are also virtual for testing purposes. A 2-millisecond update time may be considered slow, but coordinating the next cam to begin where the previous one ends should be straightforward. Are the cams set to cyclic motion? Do you continuously execute the same cam or are they each unique? In saw mill operations, each cam is usually unique, while in typical machine control, the same cams are repeated. Performing these tasks on a PC may present challenges. Can you provide more information about the application? With decades of experience in this field, I have tackled numerous projects over the years.
We utilize an Advantech UTC-216F, which is not your typical home PC but rather an industrial IPC commonly used in various applications. However, it has not been previously used in motion control applications. The program we tested is purely for testing purposes, as we do not yet have the actual cam profiles for the final packaging machine. The test scenario includes acceleration, constant velocity, deceleration, and dwell phases. To reduce load intensity, we plan to continuously switch cams using the MC_Camin instruction. Currently, we are experiencing jitter peaks ranging from 200 to 300 µs, with the execution of MC_Camin peaking at over 500 µs. This system runs on a Codesys runtime on Linux. We have provided a trace of jitter and cycle time, along with a monitor displaying maximum and minimum values in µs. It would be beneficial to establish reasonable values for smooth motion execution.
Could you provide me with the CPU usage data from the task configuration page?
I wish more people could create high-quality trends like that. User aand74 mentioned using an Advantech UTC-216F, which is not a typical home PC but more of an industrial IPC. While this IPC has been used in various applications before, it has not been tested with motion control applications yet. Despite having some industrial-grade electronic components, it still consists of regular PC hardware. The test scenario involves different cam profiles for an upcoming packaging machine, with phases like acceleration, constant velocity, deceleration, and dwell. The goal was to attach multiple cams continuously to reduce the load on the MC_Camin instruction. There seems to be some jitter issues between 200 and 300 µs, with an execution peak of over 500 µs for MC_Camin on a Codesys runtime Linux system. The solution proposed involves using a Real-Time Linux or a military-grade RTOS like the one from Green Hills. By implementing a FPGA for synchronous and deterministic I/O for all axes simultaneously, delays caused by interrupts or high priority tasks can be minimized. Additionally, an older video showcases the seamless transition between different cams or splines using an 80186 CPU, demonstrating the potential for modern CPUs with multicore capabilities. The video also highlights a system where a scanner optimizes cuts on logs by following their natural sweep, with the ability to download and execute cam profiles in advance. The question remains regarding the necessity of acceleration and constant velocity sections over a normal move command.
If you're looking for a real-time solution, consider using CoDeSys RTE for Windows instead of CoDeSys for Linux. CoDeSys RTE offers real-time deterministic performance with minimal jitter (less than 200 microseconds). Many of their tools can be accessed for free, allowing you to test them before committing to a license purchase. Take advantage of this trial period to see if CoDeSys RTE can enhance your application's performance.
Jitter in a control system indeed becomes a concern when it starts to impact the performance and precision of the operation. In this particular case, I'd say a 200µs jitter on a 2ms cycle time, while not ideal, it may not significantly harm the motion control, especially when you're operating with virtual axes. However, physical drives might react differently due to inherent mechanical latencies. The "maximum allowable" jitter varies upon the system requirement, type of machining process, and several other factors. To put it short, if this jitter doesn't affect your system performance or the output quality, it could be tolerable. Otherwise, investigation and optimization are needed. Perhaps, increasing the CPU processing power or modifying the motion control algorithm could help reduce it.
In theory, the jitter tolerance on a CPU controller for motion control is largely dependent on the specific application and the performance of the system as a whole. While a figure of 200µs might seem concerning, it is crucial to keep in mind that in an actual environment leveraging physical drives on Ethercat, some degree of jitter is inevitable and usually even manageable. That being said, one approach to mitigate the impact of jitter could include utilizing interpolation within your EtherCAT drives that can smooth out the motion profile. These drives are capable of receiving higher level motion commands and interpolating between them within their control loop, which typically operates at a faster rate than your PLC. Exploration of faster cycle times and dedicated motion controllers could also come into play in minimizing jitter influence, depending on the exact performance requirements of your system. I suggest investigating those routes and running extensive tests with various setups before settling on a single solution. Always remember, the real-world application ultimately dictates the acceptable jitter.
From my experience, you're typically looking at an acceptable range of jitter in the ballpark of 10-20µs for motion control applications. The value of 200µs, by most standards, is indeed a bit on the high side. Two key factors could be contributing to this. First, could be the power of your IPC - deeper IPC capabilities might reduce jitter. Second, bear in mind that camming a large number of virtual axes simultaneously can contribute to higher jitter. You might want to reconsider the number of slave axes or consider partitioning the control over multiple CPU cores, if possible. Keep us updated so we can refine suggestions.
Great insights on your testing! A peak jitter of 200µs does seem quite high, especially for a cycle time of 2ms. In motion control applications, typically, keeping jitter under 10% of your cycle time is advisable, which would translate to about 200µs in this case, but ideally, you want to approach closer to 10µs for smooth performance. Since you're working with virtual axes, this gives you a good opportunity to optimize your system before moving to physical drives. Have you considered profiling the system for bottlenecks or looking into alternative scheduling methods? That might help reduce the jitter as you transition to real hardware.
That 200µs peak jitter does seem significant, especially when you're aiming for precision in motion control applications. Ideally, for most industrial motion control systems, you want to keep jitter well below 1ms to ensure smooth operation, but it sounds like you're already on the right track with minimal controller code and virtual axes as a starting point. Have you considered adjusting your network settings or optimizing the EtherCAT configuration for reduced latency? Once you move to the physical drives, fine-tuning the setup will be crucial to minimize that jitter even further.
It's interesting to see your findings with the virtual slave axes! A peak jitter of 200µs on a 2ms cycle does seem high, especially for motion control applications where precision is crucial. Have you considered analyzing the overall system load and any background processes running on the IPC during your tests? Sometimes optimizing the runtime environment or prioritizing threads can help reduce jitter significantly. Additionally, once you transition to physical drives, keep an eye on real-time performance metrics and the impact of network latency since EtherCAT can introduce its own challenges. Good luck with your setup!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: 1. What is the maximum allowable jitter for motion control on a CPU controller? - The maximum allowable jitter for motion control on a CPU controller is typically dependent on the specific application requirements and the precision needed for smooth operation. In general, lower jitter values are preferred for precise motion control applications.
Answer: - Common causes of jitter in motion control systems can include processing delays in the controller, communication latency between components, fluctuations in system load, and inadequate tuning of control parameters. Identifying and addressing these factors is crucial for minimizing jitter in motion control applications.
Answer: - A peak jitter of approximately 200µs can have a noticeable impact on the precision and smoothness of motion control operations, especially in applications that require high accuracy and repeatability. It is important to evaluate whether this level of jitter meets the requirements of the specific motion control application.
Answer: - To reduce jitter in motion control systems, consider optimizing controller performance, tuning control parameters for improved stability, minimizing communication delays, and implementing real-time monitoring and feedback mechanisms. Additionally, using hardware with higher processing capabilities and lower latency can help improve overall system performance and reduce jitter.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.