Resolving S7-1500 1515F-2PN Cycle Time Spikes Every 100ms

1. Problem Statement and Observed Behavior

A field installation centered on a Siemens SIMATIC S7-1500 CPU 1515F-2 PN (catalog 6ES7515-2FM02-0AB0 or later -2AM/-2FM revisions) is showing deterministic-looking cycle time spikes every 100 ms that break motion and positioning performance. The reported symptom is reproducible and unambiguous:

• OB1 free cycle baseline: 1 ms on the configured hardware.
• Periodic spike: 8 to 9 ms every 100 ms.
• Spike amplitude: +7 to +8 ms over baseline.
• Pattern persists even with OB1 fully empty (no FB/FC calls, no direct logic).
• Spike remains after communication load is varied between 15 % and 50 %.

The combination of "empty OB1 spikes" and "independent of comm load setting" is a strong indicator that the spike is not generated by user program execution and not generated by the configured PG/HMI/OPC UA traffic slice. It points instead at the CPU firmware's background scheduling, the PROFINET/PROFIBUS IO update scheduler, or external traffic ingress.

2. Hardware Configuration Analysis

Before chasing firmware or network causes, map the actual installed topology. The reported configuration is:

Several of these components contribute predictable background load on the CPU:

• ET 200 Eco is a PROFINET IO device with fixed 1 ms update granularity on most digital modules. Ten devices on the same PN subnet, even when fully idle, each generate a small per-cycle process-image refresh task in the controller's PN stack.
• IM 155-6 PN is the ET 200 SP head module. Multiple IM 155s each create a separate PN AR (Application Relationship) and a separate scheduler slot.
• CP 1542-5 hosts the PROFIBUS master. It exchanges data with the CPU via a backplane mechanism (separate from the PN scheduler). Even at low configured comm load, the backplane handshake has a base cost.
• Danfoss drives on PROFIBUS poll their PPOs (Parameter Process Object) at the configured DP cycle. Ten drives synchronized on the same PROFIBUS line can produce a 100 ms or sub-100 ms master poll that, on the backplane, may surface as an OB1 spike.

3. Root Cause Matrix for 100 ms Cycle Spikes

Use the table below to triage by frequency of occurrence in field reports. Each row gives the diagnostic that confirms or eliminates the cause.

For the reported "empty OB1 spikes every 100 ms" symptom, R1, R2, R3, R4, R6, R8, R9 are the highest probability candidates. R7 is typically not exactly 100 ms periodic and is usually a one-shot or triggered response, so the rigid 100 ms period is a strong argument against it.

4. OB1 Free-Cycle Model vs. OB3x Cyclic Interrupt

The S7-1500 task model is part of TIA Portal's Program resources. The default architecture on a fresh project is:

1. OB 1 - free-cyclic (or "main") task. Runs to completion, then restarts after a configurable minimum cycle time if one is set, or immediately if not set.
2. OB 3x - cyclic interrupt tasks, x = 1..9. Hardware-timed via the CPU's internal tick generator. Phases are independently configurable from 500 us to 60 s.
3. OB 6x - event-driven OBs (e.g., OB 82 - diagnostic, OB 83 - plug, OB 86 - rack fault, OB 121 - programming error).

The 100 ms spike pattern does not match a single OB3x tick. It does match a PN or DP cycle of 100 ms, which is the default PROFINET update time for many lower-cost IO devices. ET 200 Eco modules, when their "Update time" is left at "Automatic" in TIA, will often negotiate to 1 ms minimum, but the controller's Application Relationship keep-alive and certain re-sync behaviors fire at 100 ms multiples. The spike is the CPU's PN stack re-synchronizing with the IO device scheduler.

4.1 Minimum cycle time and OB1 watchdog

Two parameters under CPU properties > Cycle control the spike shape:

• Minimum cycle time - pads OB1 to a minimum. Default = not set. Setting to 1 ms smooths out sub-ms variance but does NOT remove 100 ms spikes, only stretches OB1.
• Watchdog time - 100 to 6000 ms. If OB1 takes longer than this, the CPU goes STOP. Watchdog is unrelated to spikes but is a hard upper bound on motion design.

For motion, set Minimum cycle time to 1 ms as a baseline. This is independent of the 100 ms spike issue.

5. Isochronous Mode for PROFIBUS CP 1542-5

Isochronous mode ties the application (an OB, typically OB 61..OB 64) to a fixed tick of the PROFIBUS / PROFINET bus cycle. When isochronous mode is enabled, the OB runs exactly when the bus has new process data ready, and the drive's setpoints are released on the bus at deterministic instants.

For Danfoss VFDs on PROFIBUS, isochronous mode requires:

1. Drive supports isochronous mode on PROFIBUS. Many FC-302 / VLT drives support DP-V2 with clock synchronisation (SUPI/SUPY protocols). Verify in the drive parameter list: parameter group 9-6x (PROFIdrive-related). The drive must have a clock-slave capable option.
2. CP 1542-5 must be set as isochronous. In TIA: CP 1542-5 > Properties > PROFIBUS > Isochronous mode. Tick the box and assign a DP cycle (e.g., 1 ms, 2 ms, 4 ms).
3. A constant bus cycle time is required. All nodes on the PROFIBUS segment must be configured for the same constant cycle. The TIA constant bus cycle wizard enforces this.
4. Motion OB - typically OB 61 (servo), OB 62, OB 63, or OB 64 is added and bound to the isochronous tick. Move the drive setpoint / actual handling code into this OB. OB1 should not handle the fast drive setpoints.

When isochronous mode is correctly configured, the DP cycle replaces the OB1 free-cycle for drive communication. The 100 ms spike, if it originated from a DP poll aggregation, is absorbed into the isochronous tick.

6. Communication Load Parameter Tuning

The communication load parameter in the CPU properties defines the fraction of the OB1 cycle reserved for non-deterministic communication (PG, HMI, OPC UA, S7 routing, web server). The relationship is:

t_cycle_actual = t_OB1 / (1 - f_comm)

where f_comm is the communication load fraction (e.g. 0.20 for 20 %). So at 20 %, 20 % of the OB1 budget is sliced out for comm and 80 % is OB1 user code. The CPU's PN stack uses part of that comm slice continuously, regardless of OB1 emptiness.

Test points reported in the field:

Because the spike persists at low comm load, it is not the comm slice that is being scheduled in the OB1 budget. The slice is the time the comm tasks steal from the user code; if the spike were from comm stealing, lowering comm load would lower the spike. The fact that it does not tells us the spike is the comm task itself running, not the comm load weighting.

For motion systems, a typical safe comm load is 15-20 %. Below 10 % the HMI tags and OPC UA subscriptions can starve. Above 30 %, OB1 becomes a small fraction of the cycle and motion jitter rises.

7. Network Forensics with Wireshark

A non-Siemens device on the same Ethernet segment that periodically contacts the CPU (an SNMP poller, an NMS agent, a PC browser service scanning, a security camera, a printer's management card) is a well-known cause of 100 ms-cadence spikes. To prove or eliminate it:

1. Insert a managed switch with port mirroring between the CPU and the PN network. Mirroring the CPU's port to a laptop port is preferred.
2. On the laptop, run Wireshark on that port. Capture for 20-30 seconds. The CPU will be the source/destination of many frames; the uninvited frames are the candidates.
3. Apply a display filter to find non-PROFINET traffic to/from the CPU:

   ip.addr == <CPU_IP> and not pn_io and not pn_dcp and not arp

4. Look for:
   • ICMP pings at <=100 ms cadence from a single source.
   • TCP SYN bursts from a single device (S7, ISO-on-TCP, OPC UA) at 100 ms.
   • UDP/TCP traffic from printers, cameras, building management.
5. Eliminate by isolating the CPU on a separate VLAN / subnet. The CPU's PROFINET port should not be the same broadcast domain as the office network.

8. ET 200 Eco and IM 155 Update Rate Configuration

The PROFINET update time is a per-device value negotiated between the controller and the IO device. Leaving it on "Automatic" is convenient but lets the controller's scheduler pick whatever fits. To control jitter:

1. For each ET 200 Eco: Properties > PROFINET interface > Update time > "Fixed" and set a value (e.g. 1 ms, 2 ms, 4 ms). 2 ms is typical for Eco digital modules.
2. For each IM 155-6 PN: same. ET 200 SP modules can go to 250 us. For Eco + IM 155 head, 1 ms is the practical floor.
3. Reduce Number of submodules per AR by splitting the Eco daisy chain into two ARs at the switch, so the PN stack is not regenerating one AR for ten devices.
4. If Eco modules do not need 1 ms IO, push them to 4 ms or 8 ms. The 100 ms spike pattern emerges from scheduler interaction when a few devices are on fast update and others are on slow update. All-same-update-time removes the spike.

8.1 Reduction of IO device count per controller

Ten Eco + 2 IM 155s = 12 PROFINET ARs. The 1515F-2 PN supports up to 128 IO devices / 256 ARs, but the per-AR scheduler cost is real. A spike of 7 ms every 100 ms is consistent with a stack walk of 12 ARs that all line up on the same 100 ms system tick. Stagger the Eco devices' update times by 1 ms each (1, 2, 3, ..., 10 ms) to flatten the spike pattern.

9. Step-by-Step Diagnostic Procedure

Run this sequence top-down; each step is non-destructive and reversible. Do not skip ahead.

1. Capture the spike shape with TIA trace. In the project online: CPU > Online & Diagnostics > Traces > Cycle time. Record 10 seconds. Confirm the spike is at exactly 100 ms and not at 10 ms / 50 ms / 1 s.
2. Disconnect TIA Portal from the CPU. Close the project. Re-measure. If spike disappears, R5 is implicated.
3. Disconnect HMI Ethernet cable. Re-measure. If spike disappears, R4 is implicated.
4. Disable the OPC UA server on the CPU: CPU properties > OPC UA > Server > Off. Re-measure.
5. Disable the Web server: CPU properties > Web > Off. Re-measure.
6. Mirror the PN port with a managed switch. Run Wireshark. Apply the filter from section 7.
7. Disconnect the Eco daisy chain at the first Eco. Re-measure. If spike disappears, R1.
8. Power off Danfoss drives on the PROFIBUS segment one at a time. If spike disappears at N drives removed, R2 is implicated.
9. Read CPU diagnostic buffer: Online & Diagnostics > Diagnostic buffer. Look for OB82/OB83/OB86 entries clustered at 100 ms. If yes, IO events are the source.
10. Set Minimum cycle time to 1 ms: CPU properties > Cycle. Re-measure. The spike is reduced by approximately the original 1 ms baseline - 1 ms.
11. Pin all PN update times: walk through every Eco and IM 155, set a fixed update time. Re-measure.
12. Enable isochronous mode on the CP 1542-5 if drives support it. Move drive exchange code to OB 61/62/63/64. Re-measure.

At the end of these steps, the spike is either gone or attributed to a specific cause with a specific mitigation. Don't accept "spike is part of the system" - in motion design it is not acceptable.

10. Verification and Acceptance Test

After applying a fix, run an acceptance test before signing off the system:

Record the TIA trace, the Wireshark capture, and the diagnostic buffer at sign-off. These artifacts are the engineering evidence of compliance with the motion specification.

10.1 Quick field test (no tools)

If a laptop with TIA is not available, use a manual trace:

// In OB1, write to a global DB:
"cycle_log".last_cycle_ms := "RT_INFO".OB1_cycle_time;
IF "cycle_log".last_cycle_ms > 5000 THEN
    "cycle_log".spike_count := "cycle_log".spike_count + 1;
    "cycle_log".last_spike_time := "RT_INFO".clock_read;
END_IF;

Watch the spike count over 5 minutes. If it rises by 5 x 60 / 0.1 = 3000, the 100 ms spike is confirmed; if it does not rise, OB1 is fine and the perceived motion issue is elsewhere (drive-side, encoder-side, or application code).

11. Field-Proven Recommendations and Caveats

1. For motion-critical work, do not host drive setpoint exchanges in OB1. Use isochronous mode + OB 61-64, or, if isochronous is not available, use OB 35 / OB 30 with phase offset to the bus cycle.
2. Never leave PROFINET update time on Automatic. Always set a fixed value. The 100 ms spike is a signature of mixed update times being negotiated.
3. Isolate the IO network from the office network. A 1515F-2 PN with X1 (IO) and X2 (management) on the same subnet is a field failure waiting to happen.
4. Default comm load of 20 % is good for HMI, bad for motion. Reduce to 5-10 % if no heavy OPC UA / S7-comm.
5. Verify drive isochronous capability with the drive vendor before specifying a 1 ms drive bus cycle. Most FC-302 / iC2 / iC7 support it with the right firmware option.
6. Document the spike, do not hide it. If a residual 1-2 ms spike remains, the motion designer needs to know so that axis servo parameter tuning accounts for it.

12. Frequently Asked Questions