CK3E RTI Performance

Hello,

We recently have random Coordinate RunTimeError happens on our system when using CK3E as main controller and 5 ethercat axis. We did some observation on the realTime performance and compared with a CK3M module, below are some result.

When use CK3E1210, the Sys.RtIntTime is about 50 on average without ethercat activated, once the ethercat is activated, it increases to a 100. Peak RT can log (Sys.MaxRTIntTime) up to 350.

When use CK3MCPU121, the Sys.RtIntTime is about 20 on average without ethercat activated, once the ethercat is activated, it stay about 22-23. Peak RT now only reach up to 75.

The firmware version for CK3E is 2.6.0.1 and the version for CK3M is 2.6.0.0. Both system runs very similar PLCs.

I start to wondering if the RunTimeError can be related to the low performance from CK3E.

Few things we have tried to tackle the RunTimeError on the coordinate system:

Change Sys.PreCal to 5 , 10 , 15, no luck, coordinate system still fault out after few hours

Change Sys.RtIntPeriod, increase this number cause a huge delay between command J/ and read ampEnabled status from motor. When this number set to 15 or more, the watchdog is triggered.

Change Sys.MaxMotorsPerCycle will also cause a huge delay between command J/ and ampEnabled Status. Have to leave at 0 to have reasonable response time.

The test is conducted through a repeat coordinate move, which only contains 2 ethercat axis in the coordinate system 1. The Servo Frequency is 2Khz and RTI frequency is 1khz.

Any insights on the issue would be much appreciated. Thanks!

Warren

My educated guess would be something in the project is placing a greater burden on the RTI process in the CK3E project. Check the CK3E project for this.

Contact ODT Technical support for further troubleshooting: ODT-Support@Omron.com.

You mention the projects are “similar”. What are the project differences?

@Warren

Was this was caused by HMI sending "&1ABORT&1BEGIN&1START" without proper logic or delays?

Hello,

Thanks for all the support. It indeed caused by the &1Abort&1Begin&1Start without proper logic delays. After we break this into different part the issue is no longer repeatable.

Changda