Practical Application: Using Trace Time To Measure CPU Load

To determine the overall controller CPU usage, look at the HW Status tab on the Diagnostics page of the controller's web server. If the CPU usage is less than 90% then the CPU load (both Real Time and Non-Real Time) is okay. If the CPU usage is 90% or higher then the CPU is too heavily loaded and should be reduced by simplifying the application or reducing the CycleTime update rate.

This page assumes that a single-core controller is being used. The technique to measure the CPU load with dual-cores is the same, but the load limits change. Please refer to The Control Panel for more information about the trace times.

See CPU Load Reduction Techniques for additional tips.

The IDE "Integrated development environment" An integrated development environment is a type of computer software that assists computer programmers in developing software. IDEs normally consist of a source code editor, a compiler and/or interpreter, build-automation tools, and a debugger Oscilloscope trace times can be used to analyze the application performance on a controller or programmable drive. This section describes some techniques you can use to interpret the trace times to examine the real-time performance.

There are two major parts to consider when evaluating total performance:

Real Time

EtherCAT

***EtherCAT is an open, high-performance Ethernet-based fieldbus system. The development goal of EtherCAT was to apply Ethernet to automation applications which require short data update times (also called cycle times) with low communication jitter (for synchronization purposes) and low hardware costs + Motion Engine + PLC

"Programmable Logic Controller" A Programmable Logic Controller, PLC, or Programmable Controller is a digital computer used for automation of industrial processes, such as control of machinery on factory assembly lines. Used to synchronize the flow of inputs from (physical) sensors and events with the flow of outputs to actuators and events program

Non-Real Time

everything else (the background tasks)

The Oscilloscope trace times provide a very good tool to examine the Real Time response. Although it doesn’t provide the complete system picture, it is a good place to start. It can provide some indication about the Non-Real Time load, but the best indicator is the overall CPU usage and the Controller Log messages.

First, you will want to know the Cycle Time for your system. From the Project View, select the EtherCAT view and the EtherCAT Master Settings Tab tab. The update period for the system in this example is set to 250 microseconds.

The "Trace Times" traces are enabled by pressing the Plug Trace Times channels button in the Oscilloscope view when your application program is running. This button automatically configures the Channels, as seen here.

Collect some data by pressing the “Start” button

The first thing to do is to collect data during the normal application operation, particularly once the system has reached a steady state. Press Start and let the data collect for a few seconds and then press the Stop button.

The first traces to examine are the “MotionExecTime The measured execution time for the Motion Engine (either PipesNetwork or PLCOpen) in each cycle period. Units in microseconds.” and “PLCProgExecTime The measured execution time for the PLC application program (either PipesNetwork or PLCOpen) in each cycle period. Units in microseconds.”. Configure the Amplitude and Zero offset so you can see both traces easily. Below are some recommended values based on several Cycle Time values.

Cycle Time	Amplitude	Zero Offset
250ms	20	80
500ms	40	160
1000ms	80	320

Unchecking the "CycleJitter" and "RealTimeMargin The measured available execution time (equals the Cycle Time Period – EtherCAT network execution time – MotionExecTime – PLCProgExecTime) in each cycle period. Units in microseconds." traces is useful so they don't clutter the view.

The following example has a Cycle Time of 250 microseconds. The "MotionExecTime" average is about 27 microseconds and the "PLCProgExecTime" average is about 68 microseconds.

The average time for the MotionExecTime + PLCProgExecTime is 95 (27 + 68 = 95), which is about 38% of the cycle (95 / 250). This is a good value.

For multi-core controllers, we want to investigate the percentage of cycle time for each MotionExecTime and PLCProgExecTime. In the above example, MotionExecTime is about 11% of the cycle, and PLCProgExecTime is about 27% of the cycle. These are both good values.

Check the peak times

The next step is to examine the spikes. We will examine the "MotionExecTime", "PLCProgExecTime", "RealTimeMargin" and "CycleJitter" traces.

Reduce the Time base and move the traces left or right with the mouse while holding the left mouse button.
Position the cursor to measure the peak.

In this example the "MotionExecTime" peak is 44 and the "PLCProgExecTime" peak is 89. This is reasonable.

For the "RealTimeMargin" peaks configure the Amplitude and Zero offset so you can see the trace near zero. In this example the minimum peak (closest to zero) is 69 microseconds. This provides a 28% (69 / 250) Real Time margin which is good.

For the "CycleJitter" trace configure the Amplitude and Zero offset so you can see the trace centered at zero. This trace is not too interesting unless a system is misbehaving. A jitter of +/-15 microseconds is acceptable.