S7-1500 CPU Instruction Execution Times: Reference Manual

S7-1500 CPU Instruction Execution Times: Reference Manual

Execution time on a Siemens S7-1500 CPU is the wall-clock duration a single statement or block of statements consumes inside the OB/FC/FB call stack. Unlike S7-300/400, where every instruction has a published microsecond figure in the Instruction List manual, the S7-1500 family documents timing in categories: bit operations, word operations, fixed-point arithmetic, floating-point arithmetic, and transfer/comparison operations. Per-instruction nanosecond figures are obtained by combining the category baseline with measured RUNTIME samples, or by reading the device-specific data from the Siemens Function Manual.

This reference consolidates the official Siemens cycle and response times manual, the S7-300 Instruction List as a historical baseline, and the RUNTIME instruction to give engineers a complete methodology for estimating and measuring S7-1500 instruction execution time.

1. Reference Documentation

Three primary Siemens documents govern S7-1500 instruction timing. Always cite the exact manual edition used for the calculation.

Open the cycle and response times manual at SIMATIC S7-1500, ET 200SP, ET 200pro Cycle and response times and the S7-300 list at S7-300 Instruction List (A5E00105517-10) for the canonical figures.

2. Why S7-1500 Documents Timing in Categories

The S7-1500 instruction set runs on a different execution engine than the S7-300/400 accumulator-based architecture. Three architectural shifts make per-instruction µs tables impractical:

1. Optimized compiled code — TIA Portal compiles the entire OB/FC/FB before download. A single STL line may map to multiple micro-operations in the firmware's intermediate language.
2. Cache effects — the first execution of an instruction may be slower than subsequent executions because the microcode cache is cold.
3. Data type width is variable — LREAL, LWORD, and LINT operations are typically slower than REAL or DINT, but the ratio is firmware-dependent.

Siemens therefore publishes category execution times in Table 3-2 of the cycle and response times manual. The engineer sums the category figures for the code path to estimate cycle time, then validates with RUNTIME in TIA Portal.

3. Instruction Categories and Default Timing Ranges

The cycle and response times manual groups instructions into the following categories. Values below are typical ranges for a standard CPU 1515-2 PN at firmware V2.9; refer to the manual for the exact CPU in the project.

4. Bit Operation Timing

Bit operations are the fastest class on S7-1500 because they map directly to single-cycle boolean ALU operations. The cycle and response times manual lists the baseline for one logical AND, OR, or assignment at roughly 10 ns on a CPU 1515-2 PN at 100 MHz equivalent throughput.

Edge-detection instructions (FP, FN, R_TRIG, F_TRIG) carry an additional implicit load of the previous bit state. Expect 20–40 ns per edge operation instead of the bare 10 ns baseline. Use R_TRIG/F_TRIG function blocks (single-instance DBs) for clarity; avoid in-line edge logic on hot loops.

Set/reset operations (S, R, RS, SR flip-flops) on individual bit tags cost the same as AND/OR because the underlying microcode is a conditional write. The cost appears in the data access path, not the ALU.

4.1 Bit operation timing example

// Network 1 (STL equivalent of a typical machine interlock)
A   %I0.0         // 10 ns
A   %I0.1         // 10 ns
=   %Q0.0         // 10 ns
A   %I0.2         // 10 ns
FP  %M100.0       // 30 ns (FP loads previous M100.0)
=   %Q0.1         // 10 ns
// Subtotal: ~80 ns excluding I/O image update

5. Word, Timer, and Counter Timing

The S7-1500 timer and counter instructions are IEC 61131-3 system blocks (TON, TOF, TP, TONR, CTU, CTD, CTUD). Internally they maintain an instance DB, so the cost is the function call (~200 ns) plus a few word operations on the time/count tag.

Approximate per-call figures for a CPU 1515-2 PN:

For TON, TOF, TP, the value range is 0–9999999 ms with a time base of 1 ms by default. This time-base tick is internal to the IEC timer; it does not consume a separate hardware timer slot on the CPU.

6. Fixed-Point and Floating-Point Arithmetic

Fixed-point arithmetic operates on INT, DINT, WORD, DWORD, and BCD. Floating-point operates on REAL and LREAL. Typical CPU 1515-2 PN costs:

Conversion operations have their own cost band:

• INT_TO_REAL / REAL_TO_DINT: 40–100 ns
• BYTE_TO_WORD / WORD_TO_DWORD: 30–60 ns
• BCD_TO_INT / INT_TO_BCD: 60–120 ns
• CHAR_TO_STRING / STRING_TO_CHAR: 200–500 ns (string header manipulation)

The S7-1500 hardware floating-point unit is IEEE 754 compliant. NaN propagation, denormal handling, and overflow traps follow the IEEE default, so the cost of an exception path can be 2–3× the normal case. Guard division inputs to avoid divide-by-zero NaN results.

7. The RUNTIME Measurement Instruction

The S7-1500 RUNTIME instruction is the canonical way to measure instruction execution time on the target hardware. It captures the CPU's internal high-resolution counter at start and end of a code region, returning elapsed time in nanoseconds.

7.1 Interface

// SCL signature
RUNTIME(MODE := 0, MEM := <instance_DB>);
// MODE = 0: write start timestamp to MEM
// MODE = 1: write end timestamp and compute elapsed time into MEM

7.2 Usage pattern

// FB "PerfProbe" body (SCL)
// At scan start
RUNTIME(MODE := 0, MEM := DB_Perf.runtime);   // 30 ns overhead

// Code to measure
// ...

// At scan end
RUNTIME(MODE := 1, MEM := DB_Perf.runtime);   // 60 ns overhead
// DB_Perf.runtime now holds elapsed nanoseconds as LREAL

The result tag is a LREAL holding the elapsed time. RUNTIME itself consumes 30–90 ns depending on MODE, so subtract the overhead from the measurement when comparing to category baselines.

7.3 Caveats

• RUNTIME must be called with a valid MEM pointer (instance DB or global DB). Passing a NIL pointer raises OB 121 (programming error).
• The counter is the CPU's monotonic timestamp counter; it does not roll over within the cycle.
• RUNTIME is available in all S7-1500 CPUs and the S7-1500R/H redundant CPUs as of firmware V1.8.

8. S7-300 Cross-Reference for Timing Ratios

The S7-300 Instruction List at S7-300 Instruction List (A5E00105517-10) still publishes per-instruction µs figures, e.g. POP 0.03 µs and TAK 0.06 µs on CPU 317. Use it as a ratio baseline when porting an S7-300 program and assessing whether the S7-1500 will hit its cycle budget.

The S7-1500 typically runs 1.5× to 6× faster than the S7-317, with the largest gain on floating-point because the S7-1500 has a dedicated hardware FPU. Integer logic gains are smaller because the S7-317 was already bit-optimized.

9. Cycle Time Calculation

The cycle time of an OB1 is the sum of:

T_cycle = T_image + T_OB1_user + T_comm + T_interrupt + T_diag + T_reserve

Where:

• T_image: process image update, ~50 µs for 1 KB of I/O at 100 µs PI update rate
• T_OB1_user: sum of all user-code execution times (the focus of this reference)
• T_comm: PG/OP/HMI communication, scaled with the configured PG/OP connection count
• T_interrupt: hardware and time-delay OB execution, weighted by frequency
• T_diag: system diagnostics and module status reads
• T_reserve: 5–10% reserve for transient interrupts

The cycle and response times manual provides the exact formulas and coefficient tables per CPU model. Use the manual's cycle time configurator worksheet rather than hand-calculating for production programs.

10. Estimating User-Code Execution Time

Use the following four-step procedure to estimate T_OB1_user before downloading to the CPU:

1. Inventory the code — count each instruction in the OB1 call tree (OB1 + every FC/FB it invokes).
2. Classify each instruction — map to a category from Section 3 above.
3. Sum by category — use the typical range midpoint as the per-instruction figure; multiply by call-site count for reused FBs.
4. Add block call overhead — every CALL consumes 200–1500 ns for stack frame setup; add 100–300 ns for multi-instance DBs.

10.1 Worked example

Suppose OB1 of a packaging line contains 200 bit ops, 50 word ops, 30 fixed-point math ops, 20 floating-point math ops, and 10 timer calls, plus 5 FC calls.

This is the user-code slice only. Add T_image, T_comm, and the diagnostic reserve per the cycle manual. On a CPU 1515-2 PN the total cycle is typically 1–3 ms for a packaging OB of this size.

11. Measuring Cycle Time Online

Two on-CPU tools measure cycle time directly:

1. Online → Diagnostic → Cycle time in TIA Portal — shows the last 10 cycle times including min, max, and current.
2. RD_SYS_T and RD_LOC_T for time-stamping OB1 runs externally; useful for high-precision cycle analysis.

For program-section timing inside the OB, use RUNTIME. For OB-level timing, use the diagnostic buffer or the TIA Portal cycle statistic.

11.1 Verification checklist

• [ ] Cycle max < 80% of the configured OB1 scan watchdog
• [ ] RUNTIME peaks documented and within the calculated T_OB1_user ± 15%
• [ ] Floating-point hot path not in OB35/time-critical OB if cycle > 5 ms
• [ ] No divide-by-zero possible in floating-point paths (NaN check present)
• [ ] All TIMERs use the same time base (avoid mixing 1 ms and 10 ms in one loop)

12. Performance Optimization Best Practices

Before optimizing, profile. The S7-1500 spends the majority of its cycle on a small number of hot paths. Use the RUNTIME probe in each suspected hot path before changing code.

1. Replace DIV with MUL by reciprocal — precompute 1.0/x and multiply. A real divide at 150 ns becomes a real multiply at 60 ns.
2. Use IEC timer edge-flag alternatives — the S7-1500 system TON is >300 ns; for fast single-shot delays, derive a time flag from a 1 ms cyclic interrupt instead of using TON in the hot path.
3. Cache real constants — a LREAL constant load is faster than converting from INT at every scan.
4. Avoid multi-instance DBs for short FBs called millions of times — the DB write-back overhead is real; single-instance DBs in a known hot region can be faster for legacy code.
5. Use BLKMOV with typed arrays instead of structured field-by-field copy when the layout matches.
6. Run floating-point math in a slower OB (e.g., OB35 at 100 ms) and use latched results in OB1.

13. Common Errors When Using RUNTIME

14. Field Commissioning Procedure

1. Pre-load estimate — use Section 10 to compute T_OB1_user.
2. Download and go online with the project.
3. Open TIA Portal → Online → Diagnostics → Cycle time and run the machine through a worst-case sequence.
4. Insert RUNTIME probes in the three suspected hot paths identified by the estimate.
5. Document cycle min/max/avg in the commissioning report.
6. Compare with estimate; if delta > 20%, classify the discrepancy (cache effect, interrupt, or estimate error) before re-optimizing.
7. Lock the firmware version on the CPU (TIA Portal: CPU properties → Protection → disable automatic update) to prevent silent timing changes after commissioning.

15. Frequently Asked Questions