Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
CK3E performance
#1
Hi,

I am looking into moving from the 465 to the CK3E cpu card primary reason is the etherCAT functionality.

Worryingly the execution time of my RTI and Servo has drastically increased on the CK3E so much so I have had to drop from 2.2kHz servo frequency to 1kHz.

I understand the read and write of etherCAT information now occurs in the Servo which may explain the increase from 20 to 300 microseconds execution time.

What I was not expecting was an increase from 20 to 500 microseconds in the RTI. Which as far as I can tell is running very similar code.

Should I be expecting this sort of performance drop between the two cards?
Reply
#2
Can you give some information about what this system is doing? What ethercat slaves does it have? Are you doing anything in foreground or C plcs? Are you using lookahead? Do you have a low segmentation time? Are you using kinematics?
Reply
#3
(01-11-2018, 11:37 AM)Eric Hotchkiss Wrote: Can you give some information about what this system is doing? What ethercat slaves does it have? Are you doing anything in foreground or C plcs? Are you using lookahead? Do you have a low segmentation time? Are you using kinematics?

Setup 465

UMAC Hardware

19axis of motion
32 encoder channels
48 analogue channels
macro ring
3 x 65e dig IO cards

CK3E Hardware

19Axis of motion
4 x AKD-P etherCAT servo drives
2 x AKD-C etherCAT distributed power units
15 x AKD-N etherCAT distributed servo drives
4 x 8 axis etherCAT quadrature encoder boards our own design
1 x Beckhoff PLC master/slave device with chain of IO on it's own etherCAT master network

In both cases we are not using segmentation mode, we do not use look ahead, we are not running foreground PLC programs and we do not use the inbuilt kinematics.

We have an rtiCPLC which we have figured out is scheduled to run in the RTI interrupt but runs on the background Core. We have an execution timer in this code we would expect this code to take approx 100microseconds to execute on a 465cpu it seems to be taking approx 180microseconds to run on the CK3E.

Assuming this 180microseconds is part of the overall 500microseconds for the RTI execution.

This suggests 320 is split between move planning, motor safety and status checks and coordinate system updates.
Reply
#4
Where did you get these execution times? From the task manager? From Sys.RtIntTime and Sys.ServoTime?

Sys.RtIntTime is time from the start of servo tasks to the end of real time tasks. It needs to have the servo time removed to be accurate. I want to make sure you're getting both sets of numbers from the same place.
Reply
#5
I believe your reported RTI time is including your Servo time. While this is properly subtracted out on 465 CPUs, there is a bug in the task manager for ARM.

For a more accurate RTI time, use one of these equations in a plc. The difference is whether the values on the right side of the equal sign have already been filtered.
Code:
GLOBAL RtIntTaskTime, FltrRtIntTaskTime;
RtIntTaskTime=Sys.RtIntTime-(int(Sys.RtIntTime/Sys.ServoDeltaTime)+1)*Sys.ServoTime
FltrRtIntTaskTime=Sys.FltrRtIntTime-(int(Sys.FltrRtIntTime/Sys.ServoDeltaTime)+1)*Sys.FltrServoTime
Reply
#6
(01-11-2018, 11:22 AM)MDustan Wrote: Hi,

I am looking into moving from the 465 to the CK3E cpu card primary reason is the etherCAT functionality.

Worryingly the execution time of my RTI and Servo has drastically increased on the CK3E so much so I have had to drop from 2.2kHz servo frequency to 1kHz.

I understand the read and write of etherCAT information now occurs in the Servo which may explain the increase from 20 to 300 microseconds execution time.

What I was not expecting was an increase from 20 to 500 microseconds in the RTI. Which as far as I can tell is running very similar code.

Should I be expecting this sort of performance drop between the two cards?

It is my understanding that there are two different vendors used by DT for EtherCat stack implementation, Acontis & EtherLab. The 465 uses EtherLab and the CK3E uses Acontis.
You indirectly noted this difference in your original post when you referred to the EtherCat functionality being better in the CK3E - unfortunately, it comes at a cost.
The EtherLab implementation is fast(er) but requires more involvement to configure network communications.
Acontis is a more 'user friendly' implementation, but has more run-time overhead.
Perhaps this might explain the thruput difference you are seeing?
Also, are you operating your amplifiers in Synchronous Position, Velocity, or Torque?
Position will work best with slower updates, Torque mode allows all tuning, etc to be controlled within PPMAC (but requires faster updates)
Attached is a document that I have found very helpful.

Disclaimer: I've done a fair amount of homework into using EtherCat as a drive interface, but have not yet crossed that line.


Attached Files
.pdf   EtherCAT_Mode_Summary.pdf (Size: 422.93 KB / Downloads: 79)
Reply
#7
To clarify, we are working to fix the arm task manager bug for our next IDE release.
Reply
#8
Sorry for the delayed response.

Over the past few weeks we have uncovered much of what has been suggested above.

The Task Manager bug added to the confusion which led me to miss the fact that Sys.RtiIntTime included the servo execution time.

There are several issues with the CK3E which I have yet to figure out answers too these are:

POSIX mode has broken the way some of our background CPLC's execute, running the same code in the RTI CPLC fixes the issue. We only have one script PLC so according to the manual the 465 and POSIX flow charts should reduce to the same thing. However I have been informed the POSIX flow chart does not reveal the whole picture.

There is about a 0.75Hz beating to the RX and TX times this trickles through to the Servo and RtiInt times. This seems to be linked to ecat[0].DCClockdiff interestingly the DC Clock on the boards we have running the Etherlab stack is very solid and does not exhibit this beating. This is not the case when running the Acontis stack.
Reply
#9
(01-11-2018, 11:22 AM)MDustan Wrote: I am looking into moving from the 465 to the CK3E cpu card primary reason is the etherCAT functionality.
Should I be expecting this sort of performance drop between the two cards?

I haven't done a performance test, but remember that the CK3E is a lower cost ARM processor, and is meant for less demanding applications. The Etherlab stack at this point is much faster than the Acontis stack in our systems - one of the higher development priorities right now is to improve the performance of the Acontis stack to try and get it to to the same levels as the Etherlab stack performance.

You can get EtherCAT on the UMAC 465 as an option.
Davis Gentry
Advanced Motion Applications Engineer
Omron Automation and Safety
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)