Siemens S7-300 DO Output Q2.2 Causing PROFIBUS Slave Errors

Problem Overview

A Siemens SIMATIC S7-315 PN/DP (CPU 315-2 PN/DP, order number 6ES7315-2EH14-0AB0) running firmware V2.6.7 is controlling a new machine cabinet. The station contains digital input/output cards, analog input/output cards, a Pilz multiPNOZ safety relay, eight Lenze i500/i700-series servo drives on PROFIBUS DP, and two additional Siemens extension modules (ET 200S or ET 200M) on the same DP segment. An MP377 Touch Panel is connected to the PROFINET side of the CPU along with the engineering laptop used for STEP 7 V5.5 / SPx programming.

When the user activates digital output Q2.2 on the 32-channel digital output module, the user program calls SFC13 "DPNRM_DG" (read DP slave diagnostics) and receives a non-zero diagnostic frame for the last four Lenze servo drives on the bus. As soon as Q2.2 is reset, the diagnostics clear and the bus returns to a healthy state. The fault follows the address Q2.2 across physically different DO modules, and persists when the field wire is removed from the terminal block. A different bit inside the same output byte (Q2.0, Q2.1, Q2.3..Q2.7) operates normally. Re-writing the project to the CPU, recompiling the hardware and network configuration, and cross-referencing Q2.2 against the entire program does not surface any indirect addressing, overlap, or symbol mismatch.

Affected Hardware and Software Stack

Symptoms and Diagnostic Path

The reported symptoms form a tight pattern that any field engineer can reproduce in five minutes:

1. Set Q2.2 high in a VAT (Variable Table) using Modify with trigger: "Once and permanently" or via the user program. The SFC13 diagnostic block returns an error pattern (RET_VAL <> 0 or the RECORD buffer contains a non-zero status byte) for slaves at the high addresses of the DP segment (the last four Lenze drives in the user configuration).
2. Reset Q2.2. The diagnostic buffer clears and SFC13 returns BUSY = 0 with no error indication.
3. Disconnect the field wire from terminal Q2.2 on the SM 322 front connector. Repeat step 1. The fault still occurs, eliminating field wiring and load as contributors.
4. Move the user program reference from Q2.2 to Q2.3 in the same byte. The fault disappears. Re-excite Q2.2 (which is no longer used in the program but can still be written via VAT) and the fault returns.
5. Physically exchange the suspect SM 322 with a known-good module of the same order number. The fault follows Q2.2 to the new module. This rules out the DO module hardware.
6. Recompile HW Config and the network configuration in STEP 7, then download to the CPU. The fault persists with the new build.
7. Check Cross-references and Go to location for Q2.2 in the S7 program. No indirect addressing, no symbol aliasing, no second use. Only one assignment exists in the user program.

Root Cause: Output Address Range Overlaps the DP Diagnostic Area

In an S7-300 station, the CPU reserves two address areas inside the backplane I/O address space that are not assigned to physical modules but are consumed by the operating system:

• Process image of the inputs (PII) and process image of the outputs (PIQ), by default at IB 0..n and QB 0..n.
• Diagnostic address of the DP master system, always reserved by STEP 7 in the range starting at byte 0 of the I area. For an S7-300/400 CPU acting as DP master, the standard diagnostic address is IB 0 (diagnostic flag byte) and the assignment area extends upward by the configured number of DP slaves.

When the user places a 32-channel digital output module starting at QB 2 in HW Config, STEP 7 will, in some configurations, assign the module's process-image outputs to addresses Q2.0..Q5.3. If the DP diagnostic area is also mapped into the same range (which can happen when the user accepts automatic address assignment and the slot order is rearranged), then writing to Q2.2 writes a bit into the byte that the DP master uses for slave diagnostics. The master interprets the bit pattern as a slave status change, and SFC13 reports a diagnostic event for the slaves that map into that byte.

This is exactly what the user observes:

• The fault is address-bound, not module-bound → consistent with an address conflict rather than defective hardware.
• The fault survives wire removal → consistent with a backplane-level write conflict.
• The fault is bit-specific inside the byte → consistent with one bit of a status word being driven by the user output.
• The fault is limited to the last four slaves → consistent with the diagnostic byte carrying slave status bits that align with the last four nodes in the configured DP segment.

Step-by-Step Resolution

1. Open HW Config in the STEP 7 project. Double-click the CPU 315-2 PN/DP. On the Addresses tab, record the DP master diagnostic address. For an S7-300 PN/DP CPU, this is typically IB 0..IB 1 for a one-master system, or the next free block when multiple masters are configured.
2. Open the address overview (menu View → Address Overview or press F9). Sort by Input and Output addresses. Identify every byte in the Q area that is consumed by the system and not by a slot module.
3. Compare the Q address range of the 32-DO module with the DP diagnostic address range. If the module's Q addresses overlap the diagnostic bytes, the conflict is confirmed.
4. Reassign the SM 322 starting address to a free area that does not overlap the DP diagnostic area. In the DO module's Addresses properties, uncheck System selection and enter a starting address such as 4, 6, or 8 in the output area, depending on what is free in your station. Confirm that the resulting QB range does not collide with any DP diagnostic or slot-reserved area.
5. Recompile and download the hardware configuration to the CPU (CPU must be in STOP or the OB 1x hot-reload sequence must be used if supported). STEP 7 will warn if you introduce a new overlap.
6. Update the user program symbols so that any code referencing the old QB 2 location is repointed to the new starting address. Use Cross-references to confirm there are no stragglers.
7. Cycle the CPU to RUN and re-excite Q2.2 from the VAT. SFC13 should now return a clean diagnostic frame on every cycle.

Alternative Root Causes to Rule Out

Address overlap is the most likely cause for the described pattern, but the following conditions produce similar symptoms and should be eliminated before declaring a software bug:

Verification Procedure

After applying the address reassignment, run the following checks to confirm the fix and capture a clean baseline:

1. Open a VAT, set Q2.2 ON, monitor SFC13 RET_VAL and the RECORD buffer for at least 20 PROFIBUS cycles. Expect RET_VAL = 0 (W#16#0000) and a buffer whose bytes 0..5 (standard DP diagnostic header) all read 0x00.
2. Toggle Q2.2 at 1 Hz for 60 seconds using a clock flag or a cyclic OB35 block. SFC13 should report zero diagnostic events.
3. Open the CPU diagnostic buffer (CPU → Module Information → Diagnostic Buffer) and confirm no new DP station fault entries appear during the toggle test.
4. With the field wire still disconnected, measure voltage at the Q2.2 terminal relative to 24 V common. Expect 24 V nominal when the output is driven (Sinking or sourcing, depending on the SM 322 variant). Reconnect the field wire and re-test.
5. Save the corrected HW Config as a new revision of the project. Document the new starting address of the 32-DO module in the cabinet schematic so future modifications do not re-introduce the conflict.

Related PROFIBUS Diagnostic Concepts

Understanding why a single output bit can corrupt DP diagnostics requires familiarity with three concepts:

• DP master diagnostic address. Each DP master reserves a contiguous block of the input area for slave status. The first byte is the system diagnostics flag; subsequent bytes carry per-slave station status (OK / fault / return). The CPU uses these to trigger OB 82 (diagnostic interrupt) and to back the buffer read by SFC13.
• Process image of outputs (PIQ). Outputs are written into a backplane-internal image, and the OB1 cycle propagates that image to the physical modules. The PIQ occupies real byte addresses, and STEP 7 treats it as a normal PQB/QB range for tooling purposes — even though no physical slot module owns it.
• SFC13 "DPNRM_DG". Reads the standard diagnostic data (up to 240 bytes) from a DP slave whose address is given by the LADDR input. The RET_VAL and RECORD output are the canonical way a STEP 7 program surfaces slave faults. Any non-zero byte in the standard diagnostic header (bytes 0..5) is interpreted as an active fault by the master.

Prevention and Best Practices for S7-300 Stations

1. Use manual address assignment for the DP master diagnostic area. Set the master diagnostic address to a high, dedicated block (for example IB 200) so that no slot module can accidentally overlap it. This is the single most effective change to prevent the Q2.2-style fault.
2. Establish a non-overlapping I/O layout convention: input area from 0 upward, output area from 0 upward, with the first 16 bytes of each area reserved for system use. Document the convention in the project header comments.
3. After every HW Config change, run the Address Overview (F9) and scan for gaps or overlaps before downloading. STEP 7 will compile, but it will not always warn on I/O ↔ diagnostic overlaps.
4. Keep the CPU firmware current. V2.6.7 is a maintenance release for the 6ES7315-2EH14-0AB0; the latest production firmware is V3.3, which contains the cumulative bug fixes for STEP 7 project load issues and OB behavior on this CPU class. The latest firmware is available from the Siemens Online Support portal under entry ID 109751826 (CPU 315-2 PN/DP firmware download).
5. Use SFC13 sparingly. A high-frequency DPNRM_DG call on every cycle stresses the DP stack. If the application only needs a station-level OK/Fault summary, evaluate the master diagnostic byte in the input area directly — this avoids per-slave buffer parsing and reduces DP load.
6. Tag PROFIBUS diagnostic bytes as reserved in the symbol table with a comment such as "DP master system diagnostics — do not write". This makes accidental Q-area collisions visible to the next engineer who opens the project.

Commissioning Checklist for New S7-300 + DP Cabinet

1. Verify PROFIBUS topology: terminating resistors ON at the two physical ends only, all shields bonded to PE on both sides, baud rate ≤ 1.5 Mbps for cables > 50 m to limit reflection issues.
2. Confirm the DP master diagnostic address does not overlap any local or distributed I/O addresses.
3. Bring the CPU to RUN with all outputs forced OFF. Read SFC13 for every configured slave and confirm RET_VAL = 0 and a zero-filled standard diagnostic buffer.
4. Toggle each DO bit in the VAT for 10 cycles and re-run SFC13 after each toggle. Any DP diagnostic event during a single-bit toggle is a smoking gun for the overlap fault described in this article.
5. Save a backup of the working HW Config and the project archive on the engineering laptop before any field service visit.