Resolving SIMATIC NET V12 SP2 Intermittent Profibus Errors

1. Problem Overview

Intermittent Profibus communication failures occur on PC stations running SIMATIC NET V12 + SP2 with CP 5623 (PCIe) or CP 5613 A2 (PCI) Profibus master cards on Windows 7 SP1 32-bit. The fault presents as dropped S7 telegrams between Citect SCADA and S7-300/400 PLCs several times per hour or per day, accompanied by inconsistent error messages — sometimes a "data transmission problem" event, sometimes an S7 driver error, and sometimes no descriptive text at all. The Profibus bus itself remains healthy because S7-to-S7 communication over the same segment continues to operate without interruption, and the two PC stations — each on a different electrical segment separated by an Optical Link Module (OLM) — both show the same fault at independent times. Recovery requires a full PC reboot; stopping and restarting the S7OPC service or the SIMATIC NET host service does not re-establish communication. This pattern is characteristic of a host-side stack or driver defect in SIMATIC NET V12 + SP2, not a physical-layer or PLC-side fault.

The signature clues to look for in a field diagnosis are: (a) two PC stations on independent Profibus segments both fail; (b) PLC-to-PLC S7 PUT/GET on the same wire is unaffected; (c) the PC-side error does not self-recover; and (d) swapping the CP 5623 (PCIe) for the original CP 5613 A2 (PCI) in the same chassis reproduces the fault. When all four are present, suspect the SIMATIC NET V12 + SP2 software stack on Windows 7 SP1 32-bit and the workaround is a downgrade to SIMATIC NET V8.1 + SP2 on the same hardware.

2. Affected System Configuration

The fact that the fault appears on two independent electrical segments — each with its own OLM — and the unchanged PLC firmware continues to communicate over the same Profibus segment isolates the defect to the PC station. Substituting the original CP 5613 A2 into the new PC reproduces the same fault, which removes the PCIe card as a suspect and points to the SIMATIC NET V12 + SP2 software stack or its interaction with Windows 7 SP1 32-bit as the root cause.

3. Symptom Pattern and Error Messages

Reported symptoms from the upgraded PC stations:

• Intermittent S7 communication drops, frequency ranging from a few times per hour to a few times per day, with no observable correlation to SCADA load, time of day, or external equipment activity.
• Variable error messages from the S7 driver / OPC layer; some events carry no descriptive text, others include "Data transmission problem of ...", OPC subscription timeouts, and S7 driver internal status changes (e.g. 0x0001 → 0x0002 → 0x0004 transitions in the OPC group state machine).
• SIMATIC NET Network Diagnostics shows inconsistent diagnostic states between events. The same PC may report different internal counters before and after a drop, and the master's view of slave reachability may briefly disagree with the PLC-side diagnostics.
• Full PC reboot is required to re-establish communication. Stopping and restarting the S7OPC service or the SIMATIC NET host service does not recover the link; the CP 5623 / CP 5613 A2 firmware must be re-initialized by a cold boot.
• Both PC stations — each on a different electrical Profibus segment separated by an OLM — exhibit the same fault at independent times. PLC-to-PLC S7 communication on the same cable is unaffected throughout.

4. Root Cause Analysis

SIMATIC NET V12 is a multi-component software suite — the S7OPC server, S7 protocol driver, CP 5623 / CP 5613 A2 device driver, Configuration Console, Station Configuration Editor, and SIMATIC NET Diagnostics — all of which participate in the S7 communication path. V12 was the first release that promoted Windows 7 SP1 / Server 2008 R2 to the minimum supported host OS in many configurations; the legacy V6.2 stack was Windows XP-era. Several defect patterns consistent with the reported symptoms have been observed when V12 + SP2 is paired with CP 5623 or CP 5613 A2 on Windows 7 SP1 32-bit:

1. OPC DA 3.0 subscription handling. The V12 S7OPC server can lose its subscription table on Windows 7 after several thousand poll cycles, producing inconsistent diagnostics and silent loss of read requests until the service is restarted. The OPC DA 2.0 path used by the V6.2 / V8.1 stacks does not exhibit this drift because its subscription bookkeeping is structured differently.
2. DP master state machine hang. The CP 5623 / CP 5613 A2 driver under V12 + SP2 can enter a state in which the host cannot re-issue requests after a single bus error, even though the master is still online at the bus level. Re-initialization of the firmware on the CP is required, which only a cold boot performs. This is the symptom most often misread as a "Profibus cable fault" because the bus briefly reports errors before the master hangs.
3. Power management interaction. Windows 7 default PCI/PCIe power management (ASPM) and certain Optiplex 9020 BIOS revisions can place PCIe slots in a low-power state when idle, breaking the DP master's interrupt path. The legacy CP 5613 A2 (PCI) is also affected on certain Optiplex BIOS revisions where the PCI slot is gated by the same power policy.
4. 32-bit address space and handle reuse. Windows 7 SP1 32-bit has a smaller kernel handle table and a smaller non-paged pool than the 64-bit OS. The V12 S7OPC server's per-subscription allocation pattern can fragment the non-paged pool over weeks of continuous operation, eventually failing allocations and tripping the master into the hang state described in (2).

The definitive proof of a V12 + SP2 stack issue is the failure to recover without a reboot, the independence from the physical segment, and the success of the same hardware when paired with SIMATIC NET V8.1 + SP2. The V8.1 stack is the last release that supports Windows 7 32-bit and Windows Server 2008 R2 with a mature, field-proven OPC S7 driver that pre-dates the V12 architectural change to OPC DA 3.0 subscription handling. The official V8.1 SP2 readme, published on Siemens Industry Online Support, lists the addressed issues and the supported host platforms and should be reviewed before commissioning the downgrade.

5. Diagnostic Procedure

Follow this ordered procedure to confirm the host-stack root cause before any hardware swap.

1. Capture the SIMATIC NET event log. Open Start → Siemens Automation → SIMATIC NET — Diagnostics, enable the extended trace (Trace → Extended Trace On), and let it run through at least one fault window. Export the log as .trc for later review. Set the trace buffer to at least 50 MB to avoid wrapping during the burn-in window.
2. Read the CP 5623 / CP 5613 A2 firmware. Open Configuration Console → CP 5623 / CP 5613 A2 → Diagnostics → Firmware. Record the DP-Master firmware version and bus statistics: master state, token rotation count, retry count, slave diagnostic count, and lost-telegram count. A frozen Master State value while the fault is active, with no further increment of the token rotation counter, confirms a driver-level hang.
3. Check the Windows event log. Review the System and Application logs for the SIMATIC NET S7 service, the S7OPC server, and any PCI/PCIe bus errors at the moment of the fault. Look for Event ID 11 (driver hang) on Siemens CP 5623 and for any reset entries on the PCI bus enumerator. A cluster of Event ID 11 entries within 5 seconds is the host-side signature of the V12 SP2 hang.
4. Validate the PLC side. In STEP 7 / TIA Portal online diagnostics, confirm that the Profibus slave diagnostics for the S7 stations do not show any fault frames coincident with the PC-side drop. The PLC's Profibus diagnostic buffer records the master's token-passing health; a clean PLC buffer during a PC-side drop confirms that the bus is healthy from the master-of-master's point of view.
5. Validate cross-traffic. Confirm S7 PUT/GET between PLCs is unaffected. PLC-to-PLC traffic is a real-time bus monitor; if it is clean, the bus is healthy and the fault is host-side.
6. Test on a different segment. The upgraded PC's are already on two independent OLM segments, both showing the fault. If only one segment were affected, re-check OLM power supplies, fiber attenuation (must be < 6 dB for plastic fiber, < 12 dB for glass fiber), and the 24 V supply quality at the OLM.
7. Cross-test the stack. Back up the V12 SP2 installation (export the XDB and the Station Configuration Editor export), install SIMATIC NET V8.1 + SP2, re-import the XDB, and re-test. If the intermittent errors disappear with no other change, the root cause is confirmed. Keep the V12 SP2 media and the license file in a documented rollback kit.

6. Resolution: Downgrade to SIMATIC NET V8.1 + SP2

The verified fix in this configuration is to replace SIMATIC NET V12 + SP2 with SIMATIC NET V8.1 + SP2 on the Windows 7 SP1 32-bit PC stations, while keeping the CP 5623 (PCIe) or CP 5613 A2 (PCI) Profibus master in place. After the downgrade, intermittent errors ceased on both PC stations without any change to the PLC firmware, Profibus cabling, OLM configuration, or Citect SCADA project.

1. Stop all Siemens / SIMATIC NET services and the Citect SCADA service. Close the Configuration Console and the Station Configuration Editor. Confirm via services.msc that SIMATIC NET S7, SIMATIC NET OPC, and SIMATIC NET Configuration are all in Stopped state.
2. Open Programs and Features (or the legacy Add/Remove Programs on Windows 7 32-bit), uninstall SIMATIC NET V12 + SP2 and any associated PC station components. Restart the PC and confirm that no Siemens services reappear after the boot.
3. Insert the SIMATIC NET V8.1 + SP2 media. Run the installer and select PC Station with the OPC Server / S7 Protocol option. Apply SP2. On 32-bit Windows 7, the default install path is C:\Program Files\Siemens\SIMATIC.NET; confirm this matches the project documentation.
4. Open Station Configuration Editor. Add a CP 5623 (or CP 5613 A2) module and assign it to the correct Profibus subnet. Import the existing XDB or re-create the station from the S7 project, matching the original Index and Name. Save the configuration.
5. Open Configuration Console → CP 5623 / CP 5613 A2 → Operating Mode. Set the mode to DP-Master and load the matching bus profile. The bus profile must match the segment baud rate (1.5 Mbps typical, 12 Mbps maximum) and the segment's HSA (Highest Station Address).
6. Restart the PC. Confirm in SIMATIC NET Diagnostics that the master is in RUN and that all configured slaves are reached. The Diagnostics view should show a non-zero token rotation counter and a zero retry counter.
7. Start Citect SCADA. Verify that the S7 driver connects on the first poll and that trend updates resume. Verify the OPC DA subscription rates in the S7OPC server log match the project's configured rates.

7. Alternative Mitigations: TTR Adjustment and Connector Inspection

Before downgrading the stack, two low-cost mitigations are worth attempting in parallel — they will not fix a true V12 + SP2 stack defect, but they will rule out timing and contact issues that can present with similar symptoms.

Target Rotation Time (TTR) tuning. TTR defines the upper bound of one Profibus DP cycle. If the actual cycle time exceeds TTR, slaves may reject the master's token-passing sequence and force a re-initialization, which can be misread as a host fault. The TTR budget must cover the longest master-to-slave request, the longest slave-to-master response, the gap request/response pairs, and the idle time between cycles. A practical starting formula is:

where T_SDi is the bit time of the shortest SD i telegram type used and T_idle is the configured inter-frame gap. Typical starting values for a 1.5 Mbps Profibus DP segment with up to 32 slaves are 5 000 000 bit times (≈ 3.3 s) for a diagnostic-heavy segment, or 1 000 000 to 3 000 000 bit times (≈ 0.66 s to 2 s) for a fast cyclic segment. The legacy Siemens "Setting Target Rotation Time" guidance recommends a TTR of 5 000 000 to 10 000 000 bit times for a stable plant bus. Increase TTR in increments of 50% until the errors stop, then trim back to the smallest stable value. If the errors do not stop after TTR is doubled, the fault is not a TTR issue and the stack is the more likely cause.

Connector and contact inspection. D-sub Profibus connectors in field cabinets oxidize over years of service, especially with temperature cycling. Pull each connector, inspect the terminator resistor state (ON only at the two physical ends of a segment), the shield clamp, and the wire-brush contact pins. Re-seat with the locking screws torqued to spec (0.4 Nm typical for 9-pin D-sub). A single intermittent connector on a critical bus segment can produce the exact symptom pattern seen here, including a recovery that requires re-initialization of the master. Apply a small amount of contact lubricant (e.g. Cramolin or DeoxIT) to the pins if oxidation is visible.

8. Hardware and Software Compatibility Reference

9. Verification and Burn-In Procedure

1. Power-cycle the PC and confirm a clean cold-boot. Open SIMATIC NET Diagnostics; confirm the CP 5623 / CP 5613 A2 is in RUN with no warnings, and the bus statistics show a stable token rotation counter with zero retries.
2. Open Citect SCADA and confirm all configured tags show fresh timestamps. Trend a few critical tags and verify the trend line is continuous for 30 minutes with no gaps, timeouts, or stale data flags.
3. From the S7 side, monitor the Profibus diagnostics buffer of each PLC. Confirm no Bus fault, Master fault, or Retries events are logged coincident with the test window. The PLC diagnostic buffer records the master's token health; a clean buffer during the burn-in is a strong signal that the bus is stable.
4. Stress the bus: force a few hundred read/write transactions per second from Citect, with OPC subscription rates at the project's maximum. Run this for 24 to 72 hours to cover at least one full DP cycle's worth of subscription churn.
5. Run an additional stress test with a controlled bus perturbation: temporarily loosen one D-sub connector on a non-critical slave to introduce retries. Confirm that the PC station recovers automatically when the connector is re-seated, without a reboot. This validates that the stack can ride through a transient physical fault — a behavior the V12 + SP2 stack did not exhibit in the original incident.
6. Capture the SIMATIC NET extended trace and the Windows event log for the burn-in window. Archive with the project record. The trace file should show continuous token-passing with zero master-state transitions other than the expected cold-start entry.

10. Preventive Maintenance and Monitoring

• Pin the SIMATIC NET version in the project documentation. Do not upgrade SIMATIC NET on a running SCADA host without a documented rollback plan; the V8.1 → V12 jump was the trigger for this fault. Treat any SIMATIC NET upgrade as a controlled change with a parallel install on a staging host.
• Lock the PC BIOS to a fixed ASPM / PCIe power-state policy. Disable any "energy-saving" or "ASPM" options for the PCIe slot hosting CP 5623 to prevent power-state-induced master hangs. On the Optiplex 9020 this is typically under Power Management → PCI Express → ASPM; set to Disabled.
• Schedule a six-month connector and termination inspection on the Profibus segments. Replace any connector that shows oxidation, pin wear, or loose shield contact. Keep a small stock of spare D-sub connectors and bus terminators on site.
• Forward the SIMATIC NET extended trace to a network share for trend monitoring. Watch for rising Retries, Master State transitions, and OPC subscription loss counters — all of which are leading indicators of stack drift. Configure a simple alarm threshold (e.g. retries > 0 over 1 hour) and route to the SCADA event log.
• Maintain a pre-tested, imaged spare PC station with SIMATIC NET V8.1 + SP2 and the same Configuration Console / Station Configuration Editor settings as the live host. Cold-swap time should be under 15 minutes. Store the V8.1 SP2 install media, the license key, and the XDB export in a documented location.
• Periodically validate the OPC subscription table by exporting the S7OPC server's current subscription list and comparing it to the project tag database. Drift between the two is a leading indicator of the V12 SP2 subscription-table defect and should be investigated before it produces a visible fault.

Frequently Asked Questions