Matching S7-PLCSIM Advanced Cycle Time to S7-1500 CPU Scan

Overview: The Cycle-Time Gap Between PLCSIM Advanced and Real S7-1500 CPUs

S7-PLCSIM Advanced simulates a SIMATIC S7-1500 or ET 200SP CPU on a Windows host using the same engineering image and the same STEP 7 (TIA Portal) project. The simulation reproduces I/O behavior, communication, and program logic faithfully, but it does not reproduce the wall-clock execution time of the user program. A real S7-1500 CPU executing 30 kB of logic in OB1 will report a cycle time of ~6 ms; the identical logic in PLCSIM Advanced will typically scan in 0.8–2.0 ms because the instruction-execution path runs at host-PC speed with no backplane arbitration, no I/O update overhead, and no firmware scheduling jitter.

This gap is invisible until simulation results diverge from real-PLC results: PID loops integrate too aggressively, motion cam profiles over-slew, hardware-dependent OB1 logic (e.g., time-of-day filters) under-samples, and safety F-runtime group diagnostics report infeasibly short F-cycle times. Engineers who commission motion, closed-loop control, or fail-safe logic from a PLCSIM Advanced session must therefore apply a cycle-time compensation method before trusting simulation output.

This reference covers three engineering-grade methods to align PLCSIM Advanced cycle time with a real S7-1500 CPU: (1) the built-in Minimum cycle time parameter in the CPU properties, (2) an OB1 delay loop driven by a measured scan-time ratio, and (3) a self-calibrating SCL function block that adapts to whatever logic volume the project contains. It also documents the F-runtime group cycle-time constraints imposed when S7-PLCSIM Advanced is used to test a SIMATIC Safety program, per the TIA Portal V20 SIMATIC Safety manual.

Why PLCSIM Advanced Cycle Time Diverges from Real CPU

The cycle-time delta is structural, not a bug. The real S7-1500 CPU is a deterministic real-time target that performs, in fixed sequence, a backplane read of distributed I/O, an image-update, the OB1 priority class 1 scan, a write-back to the outputs, and a system slice that services PROFINET, PROFIBUS, and diagnostic OBs. PLCSIM Advanced executes the compiled user program on the Windows scheduler and substitutes virtual I/O for the field devices, so:

• No backplane latency. Real PROFINET IRT devices on an S7-1500 contribute a deterministic 0.5–1.5 ms of update time per cycle, depending on send-clock and reduction ratio. PLCSIM Advanced collapses this to nanoseconds.
• No instruction-fetch bottleneck. The S7-1500 executes STEP 7 instructions from work memory in microcoded sequences. PLCSIM Advanced executes the same compiled code on x86-64, which can be 3–8x faster per instruction.
• No firmware time-slice contention. The real CPU arbitrates between OB1, OB35 (cyclic interrupt), OB82 (diagnostic), OB121 (programming error), and the F-runtime group. PLCSIM Advanced runs OBs in sequence on the same thread, eliminating the preemption overhead.
• No physical I/O image copy. The real CPU performs a process-image update (PAE/PAA) at fixed points in the scan; PLCSIM Advanced's image is updated synchronously with the call.

The aggregate result is typically a 3–8x scan-time acceleration in PLCSIM Advanced, scaling with logic volume, I/O count, and number of cyclic OBs. For a 30 kB OB1 with 64 bytes of PROFINET I/O, the ratio is close to 6:1; for a 200 kB logic with 4 kB of I/O and four cyclic OBs, the ratio compresses to 2:1 because the real-CPU overhead becomes a smaller fraction of the total.

Method 1: Configure the Minimum Cycle Time

The simplest, code-free method is to set a fixed minimum cycle time in the CPU device configuration. This is supported on S7-1500 CPUs from firmware V2.0 onward and is exposed in TIA Portal under Device view > CPU > Properties > Cycle.

1. Open the project in TIA Portal.
2. Switch to the Device view and select the S7-1500 CPU.
3. Navigate to Properties > General > Cycle.
4. Enable Set minimum cycle time and enter the target value in milliseconds (e.g., 6 ms).
5. Compile (Hardware) and download to the simulation instance.

When enabled, the OB1 priority class waits in a fixed busy-loop after OB1 completes if the cycle ended earlier than the configured minimum. The cycle time reported in the online diagnostics matches the minimum (or the natural scan, whichever is greater).

Method 2: OB1 Delay Loop with a Measured Scan-Time Ratio

For predictable projects where the ratio between PLCSIM and real-CPU cycle time is stable, a single calculated delay at the end of OB1 produces a faithful cycle time without modifying hardware configuration. The approach is:

1. Measure the real-CPU cycle time of the current project on a target S7-1500 (e.g., CPU 1515-2 PN, 6ES7515-2AM02-0AB0, FW V2.9).
2. Measure the PLCSIM Advanced cycle time of the identical project on the same Windows host.
3. Compute the ratio: simRatio = realCpuTime / plcSimTime.
4. Add an SCL function block call at the end of OB1 that busy-waits for realCpuTime - currentScanTime every cycle.
5. Use a compile-time switch or a tag (IF bSimulating THEN ...) to disable the delay when running on the real CPU.

Example SCL implementation in OB1 (or called as the final network):

// SCL - end of OB1
IF "bSimulating" THEN
    // simRatio is loaded from a startup OB (OB100) data block
    // currentScan is measured from RUNTIME or system clock diff
    "tTargetCycle" := MULTIME("tThisScanTime", "simRatio");
    "tDelayNeeded" := "tTargetCycle" - "tThisScanTime";
    IF "tDelayNeeded" > T#0ms THEN
        // Busy-wait loop. Do NOT use SCL_HALT or time-of-day
        // functions here; they would consume scheduling budget.
        WHILE (("tLoopStart" + "tDelayNeeded") > "SYSTEM_CLOCK") DO
            ; // intentional no-op
        END_WHILE;
    END_IF;
END_IF;

The simRatio tag should be tuned per CPU model and per logic volume, then stored in a DB (DelayCalc_DB) so it survives downloads. A practical workflow is to maintain a baseline table:

Method 3: Self-Calibrating SCL Function Block

When the project logic changes frequently and a static ratio becomes stale, a self-calibrating FB averages the last N scan times in PLCSIM Advanced, applies a stored ratio, and emits the appropriate delay. The FB also records a rolling minimum and maximum so a HMI can plot the simulated cycle time envelope.

FUNCTION_BLOCK "FB_CycleTimeMatch"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
VAR_INPUT
    iEnable : BOOL;              // TRUE in PLCSIM, FALSE on real CPU
    rSimRatio : REAL := 6.0;     // baseline ratio; updated on real CPU
    iAvgWindow : INT := 50;      // number of scans to average
END_VAR
VAR_OUTPUT
    tActualScan : TIME;          // measured this-scan execution time
    tTargetScan : TIME;          // target cycle time
    tSimulatedScan : TIME;       // output for HMI trend
END_VAR
VAR
    iScanIndex : INT;
    arrScanTimes : ARRAY[0..255] OF TIME;
    tLastStart : TIME;
    tThisStart : TIME;
    tRunningSum : TIME;
    tAvgScan : TIME;
END_VAR
BEGIN
    tThisStart := RUNTIME(CLK := SYSTEM_CLOCK);
    IF iEnable AND (iScanIndex > 0) THEN
        tActualScan := tThisStart - tLastStart;
        tRunningSum := tRunningSum - arrScanTimes[iScanIndex MOD 256]
                     + tActualScan;
        arrScanTimes[iScanIndex MOD 256] := tActualScan;
        IF iScanIndex >= iAvgWindow THEN
            tAvgScan := tRunningSum / INT_TO_TIME(iAvgWindow);
            tTargetScan := MULTIME(tAvgScan, rSimRatio);
            // Busy-wait until tThisStart + tTargetScan
            WHILE (RUNTIME(CLK := SYSTEM_CLOCK) - tThisStart) < tTargetScan DO
                ; // no-op; do not call any FB here
            END_WHILE;
        END_IF;
    END_IF;
    tLastStart := tThisStart;
    tSimulatedScan := tThisStart - tLastStart + tTargetScan;
    iScanIndex := iScanIndex + 1;
END_FUNCTION_BLOCK

Key design points:

• Use RUNTIME, not TIME_TCK. RUNTIME returns the elapsed CPU execution time and is independent of time-of-day rollover; TIME_TCK returns the 1-Hz counter and is too coarse for sub-10 ms resolution.
• Keep the busy-wait loop free of FB calls. Any call inside the WHILE extends the cycle-time noise floor and defeats the calibration.
• Disable on the real CPU. Wire iEnable from the Simulation target compile flag, or from a CPU_DIAG tag that returns TRUE only when running under PLCSIM Advanced.
• Warm-up window. Do not delay until the averaging window is full, otherwise the first N cycles will run at natural PLCSIM speed and the HMI trend will show a step.

Determining the Ratio When the Real CPU Is Not Available

For early-stage development, the real CPU hardware is often not yet on the bench. The ratio can be estimated from the following formula, derived from the dominant cost terms in an S7-1500 OB1 scan:

t_real ≈ t_logic + t_io + t_comm + t_overhead

t_sim  ≈ t_logic * k_host + t_io_sim + t_overhead_sim

k_host  ≈ 0.15 to 0.30  (host-vs-CPU instruction ratio for typical STL/SCL)
ratio  ≈ 1 / k_host  for logic-dominated scans, falling toward 1.0
        as t_io, t_comm dominate.

For a logic-dominated scan of 30 kB on a mid-range host (Intel Core i5/i7, 16 GB RAM, SSD), k_host ≈ 0.18, giving a ratio of ~5.5. This agrees with the empirical 6:1 figure in the field report. As soon as the real CPU is available, replace the estimate with a measured value: place a one-shot RUNTIME capture in OB100, store the first 100 cycle times in a DB, and compute the geometric mean.

Safety Program Considerations with S7-PLCSIM Advanced

When a STEP 7 Safety (F-CPU) program is simulated, additional constraints apply to the F-runtime group. Per the TIA Portal V20 SIMATIC Safety manual, when testing the safety program with S7-PLCSIM / S7-PLCSIM Advanced, monitoring of the maximum cycle time of the F-runtime group and the cycle time warning limit of the F-runtime group (F-CPU parameter Max. F-cycle time / F-cycle time warning limit) is enabled. The safety program is compiled and executed by the F-runtime group scheduler, which has its own internal watchdog independent of OB1.

Implications for the methods above:

• Method 1 (minimum cycle time) applies to the standard OB1 only. The F-runtime group has its own timing path; if the F-cycle time in PLCSIM Advanced is shorter than the F-cycle time of the real F-CPU, the F-watchdog diagnostic will fire only on the real PLC. The simulation will appear to pass even when the F-program is over-budget.
• Method 2 and 3 (OB1 delay loops) do not extend the F-runtime group. To match the F-cycle time, the F-program must be wrapped in a similar busy-wait block, or the F-cycle time warning limit must be temporarily raised in the simulation CPU properties. Never raise the F-cycle time warning limit on the real F-CPU to compensate for a simulation mismatch.
• F-CPU signature check. PLCSIM Advanced uses a different F-signature than the real F-CPU. Build the simulation with the dedicated Compile as simulation F-program option, available under Safety > Settings in TIA Portal V18+, to avoid a false collective signature mismatch.

Verification: Confirming the Matched Cycle Time

After applying any of the three methods, verify the result in four ways:

1. Online > Diagnostics > Cycle time in TIA Portal. The reported OB1 cycle time should equal the configured target within ±0.5 ms.
2. PLCSIM Advanced console trace. Enable the verbose scan trace (--scan-trace=full) and confirm the per-cycle timestamp delta matches the target.
3. Tag-trace comparison. Add a one-second RT_INFO trigger in OB35 that captures the cycle time to a trace buffer. Compare the histogram of cycle times in PLCSIM Advanced against the real-CPU histogram captured on the same logic.
4. F-cycle time check. If a safety program is present, open Safety > Diagnostics > F-cycle time and confirm the F-cycle time in PLCSIM Advanced matches the real F-CPU within the F-cycle time warning limit.

Method Comparison

Engineering Caveats from Field Use

• Anti-virus interference. Windows Defender real-time scan on the PLCSIM Advanced process can add 2–10 ms of jitter to a busy-wait loop. Exclude the PLCSIM Advanced executable directory from real-time scanning during commissioning.
• Power-management states. Laptop CPUs throttling under thermal limits cause the PLCSIM host factor k_host to drift by 20–30% over a 30-minute session. Use a desktop or disable CPU throttling in the Windows power plan during extended simulation runs.
• PROFINET simulation. If the project includes a PROFINET IO controller with IRT devices, PLCSIM Advanced emulates the device but the cycle-time overhead is much smaller than on a real S7-1500. The minimum cycle time method tends to over-correct in this case; the ratio method is more accurate.
• Multi-core scheduling. PLCSIM Advanced V5+ pins itself to a single CPU core. The bSimulating tag should reflect the instance, not the project, if multiple PLCSIM Advanced instances are running concurrently on the same host.
• Online delta download. A delta download to PLCSIM Advanced resets the averaging window in Method 3. The first 50 cycles after a download will run at natural PLCSIM speed; budget for this in the test plan.

Frequently Asked Questions