CODESYS Task Time: Measure ADD/AND/EQ Execution on COM600

The CODESYS-derived IEC 61131-3 logic engine inside an ABB COM600 gateway gives you operators such as ADD, AND and EQ, but no data sheet publishes how many microseconds each one costs. That is not an omission. Per-instruction time is a property of the generated code, the CPU, the memory path to the operands, and the other tasks competing for the processor — it is measured on the target, not looked up in a table. This note gives a repeatable differential-loop procedure that yields a defensible number on your own unit, plus the guardrails that keep the benchmark from tripping a watchdog or disturbing an in-service gateway.

Why No Instruction-Time Table Exists

Two identical ADD statements in the same project can differ by an order of magnitude in cost depending on operand type and where the operands live. The variables below all move the result, so any single published figure would be wrong for most projects.

Configure a Dedicated Benchmark Task

Never benchmark inside a production POU. Isolate the code under test so the reported cycle value contains only the benchmark body plus fixed task overhead, which the differential method then cancels.

1. Open Resources → Task configuration and add a new task used only for benchmarking.
2. Set the task type to freewheeling. A freewheeling task restarts as soon as the previous pass ends, so the monitored cycle value tracks real execution. A cyclic task with an interval longer than the execution time can mask the value you want.
3. Assign one program call: the benchmark POU. No other POUs in this task.
4. Give the task the lowest priority (highest priority number) in the configuration so the benchmark can never starve communication, protocol or visualization work.
5. Disable the task watchdog, or raise it well above the expected worst-case loop duration. A 10 000-iteration loop will exceed a typical watchdog setting.
6. Download, start, and switch the task configuration view to online monitoring to read the cycle values.

Differential Loop Method

A single measurement is useless because it contains task-switch overhead, monitoring overhead and the FOR-loop control cost. Take two measurements that differ in exactly one variable and subtract. Two independent forms:

Form A - scale the iteration count, fixed body:
  t_op = ( T(N2) - T(N1) ) / (N2 - N1)

Form B - scale the body, fixed iteration count (preferred):
  t_op = ( T(k+1 ops, N) - T(k ops, N) ) / N

Form B cancels loop-control overhead exactly, because both runs execute the same number of loop iterations. Form A cancels task and call overhead. Run both; they should agree within your measurement noise.

Choose N so the measured difference is at least 100 x the resolution of the cycle-time display. If the monitor shows milliseconds, N = 1000 is usually too small — go to N = 10000 or higher and raise the watchdog accordingly.

PROGRAM PRG_Bench
VAR
    i     : DINT;
    N     : DINT := 1000;   (* iterations - change online between runs *)
    ops   : INT  := 1;      (* 0 = control loop, 1 or 2 = ops in body *)
    a, b  : DINT;
    acc   : DINT;
END_VAR
VAR_GLOBAL (* declared in a GVL, read by another POU to defeat dead-code removal *)
    gAcc  : DINT;
END_VAR

a := a + 1;                 (* operands vary, so no constant folding *)
b := 3;
acc := 0;

CASE ops OF
0:  FOR i := 1 TO N DO
        acc := acc;                    (* control loop: loop overhead only *)
    END_FOR;
1:  FOR i := 1 TO N DO
        acc := acc + (a + b);          (* 1 x ADD under test *)
    END_FOR;
2:  FOR i := 1 TO N DO
        acc := acc + (a + b) + (a + b);(* 2 x ADD under test *)
    END_FOR;
END_CASE;

gAcc := acc;                (* sink: result must be consumed somewhere *)

Variants for the other operators — keep the same loop skeleton and only swap the body:

(* AND on BOOL *)      xAcc := xAcc AND (xA AND xB);
(* AND on DINT bits *) acc  := acc + (a AND b);
(* EQ comparison *)    xEq  := xEq XOR (a = b);
(* REAL add - expect a very different result *)
                       rAcc := rAcc + (rA + rB);

The XOR and accumulate patterns exist purely to force the compiler to keep the operation and to keep the result live all the way to gAcc.

Read, Verify and Interpret the Numbers

Log the monitored values for each run. Use the minimum cycle value as the cleanest estimate of uncontended execution, the maximum as the preempted worst case, and the average for cycle budgeting.

The figures above are placeholders that demonstrate the arithmetic only. Substitute your own readings; do not carry these numbers into a design.

Verification checklist before you trust a result:

1. Linearity: measure at N = 100, 1000, 10 000. Plotted time versus N must be a straight line. A knee indicates watchdog interference, memory effects or a task-scheduling artefact — investigate before using the slope.
2. Body scaling: going from 1 op to 2 ops must add the same increment as going from 2 to 3. If it does not, the compiler is optimizing part of the body away.
3. Field identity: double N and confirm the monitored value doubles, proving you are reading execution duration and not a configured interval.
4. Independent clock cross-check: on a freewheeling task, note the cycle counter and wall-clock time at two points. Average period = elapsed time / cycle delta. It should match the monitored average.
5. Loaded versus unloaded: repeat the whole set with representative communication traffic and visualization clients connected. The spread between min and max under load is the jitter your design must tolerate.

Convert the Result Into a Cycle-Time Budget

The per-operation number is only useful as a budget input. For a task that must complete within an interval T:

N_max = ( T * U - T_fixed ) / t_op

  T       = task interval or required response time
  U       = fraction of that interval you allow the logic task to consume
  T_fixed = measured overhead of the task with no logic in it
  t_op    = per-operation time from the differential measurement

Keep U conservatively below 1 so communication, protocol and visualization tasks retain headroom; the exact figure is an engineering decision, and the loaded max/min spread from the verification step tells you how much margin the platform actually needs. Size against the maximum observed value, not the average, whenever the logic feeds a time-critical output.

Re-measure whenever any of the following changes: device firmware, logic tool build, data types used in the hot path, task priorities or intervals, the number of connected visualization clients, or the protocol/communication load. A per-instruction time captured on one build is not portable to another.

FAQ