Siemens S7-300 Scan Cycle Time Too Slow: Causes and Fixes

Overview

An S7-300 PLC reporting a 150 ms scan cycle time is operating well outside its expected envelope. A correctly configured S7-300 with a typical automation program, 15 Profibus slaves, and standard communication load should complete a full cyclic scan in 10-30 ms. Values above the configured scan monitoring time (default 100-150 ms depending on CPU class) place the CPU at the edge of a watchdog trip and produce process-visible jitter on the Profibus and optical-fiber uplinks to the master S7-400.

This article walks through field-proven diagnostic steps for the S7-300 cycle-time problem, the OB priority architecture that controls execution order, and program-level optimizations that bring a sluggish CPU back into the 10-30 ms band without changing hardware. All parameter paths reference the standard STEP 7 V5.x / TIA Portal V16+ project layout used with S7-300 stations.

S7-300 CPU Scan Cycle Baselines

Before treating a 150 ms scan time as abnormal, baseline the expected value for the specific CPU in the slot. S7-300 bit-operation times range from 0.01 µs to 0.2 µs depending on the CPU generation. A fully loaded CPU 315-2 DP with a 32 KB MC7 program, 8 Profibus slaves, and HMI communication still typically scans in 10-20 ms.

If the installed CPU is not in this list, look up the specific order number on Siemens Industry Online Support. A 150 ms scan time on a CPU 315-2 DP with a moderate program is a 6x-10x anomaly. Documented 108-drive Profibus systems on S7-400 routinely run with 11 ms scan time; an S7-300 with 15 slaves has no justification for a 150 ms scan.

Root Causes of Excessive Scan Time

From field experience, the contributors to a 100+ ms S7-300 scan time fall into six categories, ranked by frequency:

1. Error OB execution from Profibus slave flapping. OB 86 (rack/slave failure) fires on every slave drop or recovery. If the OB body is non-trivial, each event costs 5-50 ms.
2. SFC 47 "WAIT" call in production code. A test artifact that was never removed. SFC 47 with WT = 100 blocks the cyclic OB for 100 ms per call.
3. Single-OB architecture (everything in OB 1). Slow tasks such as HMI data preparation, log writing, and Profibus diagnostics run on every cycle and add fixed cost.
4. Excessive communication load configured. A 50% communication share halves the time available for the user program, and frequent PUT/GET to peer PLCs adds per-cycle overhead.
5. Work memory exhaustion. When the MC7 program is larger than the work memory, the CPU is forced to compress and decompress code, multiplying execution time.
6. I/O access errors (OB 122) on missing modules. Each access to a non-existent or failed module triggers OB 122; mass-trigger from a stub program can stall the cyclic.

Prerequisites

Before running diagnostics, verify the following:

• STEP 7 V5.5+ or TIA Portal V16+ with the project matching the target CPU's firmware.
• Online Ethernet or MPI/Profibus connection to the S7-300 CPU.
• The S7-300 project's offline archive, including the hardware configuration (.hw or .hw_0) and the program source files.
• Read access to the CPU's diagnostic buffer and the online program blocks.
• List of all configured Profibus slaves with their expected Profibus addresses and physical locations.
• Optical-fiber link budget documentation if an OLM (Optical Link Module) is in the path between the S7-400 and S7-300.

Step-by-Step Diagnostic Procedure

Follow this sequence in order; do not skip ahead. Each step isolates one variable.

1. Read the diagnostic buffer. In STEP 7, right-click the CPU in the project tree and select Online > Diagnostic Buffer. Filter for events in the last 24 hours. Look for entries of class OB 80 Time Error, OB 86 Rack Failure, OB 122 I/O Access Error, and Cycle Time Exceeded. Each is a direct pointer to the next step.
2. Read the online scan time. Open the online block view of OB 1 and observe the system clock values OB1_PREV_CYCLE and OB1_MIN_CYCLE. The wall-clock scan is OB1_PREV_CYCLE in milliseconds. Confirm the 150 ms value is consistent over a 60-second sample window.
3. Audit Profibus slave health. In HW Config, right-click the Profibus subnet and select Profibus Diagnostics. Every slave that is configured but not reachable raises OB 86. The cycle-time cost per event is the body of OB 86.
4. Search for SFC 47 calls. In the offline program, use Find in the LAD/FBD/STL editor and search for SFC 47 or the string "WAIT". Any hit is suspicious. Comment out the call (do not delete during diagnostics) and recompile. Re-measure scan time online.
5. Measure OB execution time individually. Add a start and end timestamp to each OB. The simplest method is to call SFC 64 "TIME_TCK" at OB start and OB end and store the difference in a marker word:

   CALL  SFC 64                // at OB start
   RET_VAL := MD 100
   
   // ... OB body ...
   
   CALL  SFC 64                // at OB end
   RET_VAL := MD 104
   L     MD 104
   L     MD 100
   -D
   T     MD 108                // delta in ticks

   Note: SFC 64 returns a 1 ms (or 10 ms on older CPUs) tick. Subtract the two values to get the OB execution time. Use the diagnostic buffer to time-error timestamps as a cross-check.
6. Check the configured scan monitoring time. In HW Config > CPU properties > Cycle/Clock Memory, the Scan Cycle Monitoring Time is the watchdog. The default depends on the CPU class; many S7-300 CPUs ship with 150 ms. If the configured value is 150 ms, the observed scan of 150 ms is at the trip point. Increase to 200 ms temporarily as a diagnostic, not a fix, to give room to instrument.
7. Check work memory utilization. In Online > Module Information > Memory, read Work memory used vs Work memory total. If used > 80%, the CPU is memory-pressured and MC7 paging is inflating the cycle.
8. Check program size vs CPU class. The MC7 code size is reported in the module info Performance tab. A 250 KB MC7 program on a CPU 312 (32 KB work memory) is physically impossible; the CPU is paging. Match the CPU class to the program size or split the program.

OB Priority Class Architecture

The S7-300 executes organization blocks by fixed priority. Understanding the priority classes is the key to separating fast processes from slow ones; a single OB 1 containing all logic serializes everything.

Error OBs (80, 82, 83, 85, 86, 121, 122) all run at the same priority as the OB that was active when the error fired. If the active OB is OB 1 (priority 1), the error OBs run at priority 1, further extending the cycle. Splitting critical logic into a higher-priority OB 35 (priority 12) keeps the fast path from being delayed by error OB execution.

Watchdog and Communication Load Configuration

Two CPU-level parameters control the headroom available for the user program: the scan cycle monitoring time and the maximum communication load share.

Open HW Config > CPU properties > Cycle/Clock Memory and set:

• Scan cycle monitoring time: 200 ms (diagnostic value; restore to 100-150 ms once scan time is reliably below 50 ms).
• Communication load > Maximum load by communication: 20% (the default is 50%; reducing it increases OB 1 priority share).
• Clock memory: enable and select an unused byte (commonly MB 0) if the program uses clock flags for scheduled logic.

The communication load parameter is the most commonly missed. When set to 50%, the S7-300 splits its time 50/50 between the user program and PG/OP/S7 communication. Heavy HMI polling, partner PLC PUT/GET, and Profibus DP-V1 acyclic services all consume from that 50% pool. If the HMI is polling 50 tags every 100 ms, the cyclic OB never gets a fair share. Set the share to 20% to starve the communication and force batch behavior, then optimize the HMI poll rate as a follow-on.

Program-Level Optimizations

After eliminating the system-level causes, the remaining scan-time load is in the user program. Apply these in order of ROI.

Optimization 1 - Remove SFC 47 "WAIT" Calls

SFC 47 with the parameter WT (wait time in milliseconds, range 1-32767) is a hard delay inserted by the programmer. It is a legacy debugging tool. In production code it is always wrong.

CALL  SFC 47
WT    := 100            // WAIT 100 ms - REMOVE THIS
BE

Search every FB, FC, and OB for SFC 47. Replace with no operation or a conditional flag if a deliberate stall is required. One WT=100 call in OB 1 alone adds 100 ms to every cycle.

Optimization 2 - Convert SCL and Graph Hot Paths to STL or LAD

SCL (Structured Control Language) and Graph-compiled FBs run 30-100% slower than equivalent LAD or STL in MC7. The STEP 7 compiler for SCL generates a more verbose MC7 sequence with additional stack operations. Where scan time is critical, rewrite hot-path SCL blocks in LAD or STL. S7-Graph state machines add similar overhead; if a state machine runs every 10 ms, it can dominate the cycle.

Optimization 3 - Segregate by OB Priority

Move slow tasks (HMI data preparation, log file writes, batch reports) out of OB 1 and into OB 35 (100 ms) or OB 32 (1 s). Keep OB 1 to the critical-path control logic only. The result is a sharp drop in OB 1 execution time and a stable, predictable response on the fast control loops.

Reference architecture for a 15-slave Profibus plant:

Optimization 4 - Audit OB 85 and OB 122 Bodies

OB 85 fires for "OB not loaded" and for I/O update errors. OB 122 fires on every access to a failed I/O point. A common anti-pattern is to put logic inside OB 122 that reads the failed I/O again, causing an infinite loop. Keep OB 85 and OB 122 to three operations: read the start info, set a diagnostic flag, return. Do not perform I/O inside them.

Optimization 5 - Program Size and Work Memory

If work memory used is above 80%, the CPU compresses MC7 segments to fit. Decompression on each cycle is expensive. The fix is either to split the program into modular FBs and remove unused code, or to upgrade the CPU. For an S7-300 with a 32 KB CPU 312, anything over 24 KB user program is risky; target 16 KB or less for stable 10-20 ms scans.

Profibus Network Health and OB 86 Behavior

For a system with 15 configured Profibus slaves, OB 86 is the most likely contributor to a 150 ms scan. Every time a slave drops off the bus, OB 86 fires; if the bus is flapping (connector issue, EMI, terminator, or failing slave), the OB 86 rate can dominate.

The Profibus optical-fiber link between the S7-400 and S7-300 is another candidate. An OLM (Optical Link Module) with a weak receiver or dirty connector regenerates the bus but adds latency. A failing OLM can cause retries that show up as OB 86 on the S7-300 side. Measure the optical-fiber power budget with an OLM-specific tool or substitute a known-good fiber pair to isolate.

Troubleshooting Matrix

Use this matrix as a quick triage once the diagnostic buffer is read.

Verification Procedure

After applying changes, verify the fix in this order:

1. Confirm scan time online. In STEP 7, open the online Monitor/Modify view of OB 1. Watch OB1_PREV_CYCLE over 5 minutes of normal operation (no faults). The expected value is 10-30 ms for a 15-slave Profibus plant. The maximum should be below 50 ms under peak load.
2. Confirm diagnostic buffer is clean. After 1 hour of operation, no OB 80, OB 86, OB 85, or OB 122 events should be present in normal steady state. Transient events during startup or slave replacement are expected.
3. Confirm watchdog headroom. The actual scan time should be at most 70% of the configured scan monitoring time. For a 100 ms watchdog, target a maximum scan of 70 ms. For a 150 ms watchdog, target a maximum of 100 ms. The buffer absorbs the rare error OB execution.
4. Confirm process stability. From the S7-400 operator HMI, monitor the optical-fiber link quality and the Profibus slave diagnostic counters. Slaves that were flapping should show zero retries in the diagnostic buffer.
5. Confirm communication load. In Online > Module Information > Performance, observe the communication load percentage. If the HMI is configured for 50% and the actual is below 30%, you can keep the setting; if it is consistently above 30%, the application is over-polling and the HMI should be retuned.

FAQ