Troubleshooting ET200 Module Failures on S7-400 PROFIBUS

Overview

On a Siemens SIMATIC S7-400 PLC with distributed I/O over PROFIBUS DP, a single physical station (node) may contain between 2 and 12 ET200 modules wired back to an IM 153 interface module. A bus fault reported by the CPU can originate at any of three layers: the physical bus (cable, connector, terminator, baud rate, repeater, segment length, shielding/grounding), the DP slave itself (IM 153, address conflict, configuration mismatch, watchdog), or a specific I/O module inside the rack (channel short, sensor wire break, module internal failure, auxiliary voltage loss). Identifying the node with an external analyzer such as ProfiTrace or a Softing BC-700-PB resolves the first two layers. Isolating the offending module inside the node requires DP diagnostic data — either the standard six bytes that every DP slave returns, or the extended identifier-related diagnostic that the ET200 modules produce channel-by-channel, processed by the CPU through SFC 51, OB 82, or the STEP 7 / TIA Portal online diagnostics.

This article describes the engineering-grade techniques available on the S7-400 platform: (1) cyclic evaluation in the user program via SFC 51 "RDSYSST" with SSL identifiers W#16#0094, W#16#0131, W#16#0132, and W#16#0F31; (2) event-driven handling in OB 82 (diagnostic interrupt) and OB 86 (loss of rack / DP slave failure); (3) online hardware diagnostics through the STEP 7 / TIA Portal "Diagnose Hardware" view; and (4) capture of sub-second transient faults with a ring buffer. The article also covers ET200M, ET200S, ET200pro, and ET200eco LED patterns, decoder tables for the OB 82 fault identifiers, and a verification procedure that produces a deterministic record of every event.

Affected Systems and PROFIBUS Topologies

The methods below apply to S7-400 CPUs (6ES7 4xx series, CPU 412-1 / CPU 414-2 / CPU 416-2 / CPU 416-3 / CPU 417-4) configured as DP master V0/V1 with one or more of the following distributed stations:

• ET200M — modular station, IM 153-1 (6ES7 153-1AA03-0XB0), IM 153-2 (6ES7 153-2BA02-0XB0) with redundancy support, IM 153-4 PN (6ES7 153-4AA01-0XB0). Backplane accepts any S7-300 signal module (SM 321 / SM 322 / SM 331 / SM 332 / SM 334 / SM 335), function module (FM 350, FM 351, FM 352, FM 355, FM 357-2), communication processor (CP 340, CP 341), and failsafe modules. Up to 8 modules per IM 153-1, up to 12 per IM 153-2.
• ET200S — bit-modular station, IM 151-1 (6ES7 151-1AA03-0AB0) and IM 151-3 PN (6ES7 151-3AA23-0AB0). Power modules (PM-E, PM-D), electronic modules (DI, DO, AI, AO, SSI, pulse, 1STEP, 2STEP), motor starters (DSS starters, FSB starters, soft starters), and failsafe modules (F-DI, F-DO, F-PM, F-AI).
• ET200pro — IP65/67 modular station, IM 154-4 PN (6ES7 154-4AB10-0AB0). Designed for cabinet-free installation outside the control room. Carries its own power module, electronic modules, and pneumatic interface.
• ET200eco — block I/O with integrated PROFIBUS interface, available as PN and DP variants (6ES7 142-xxx and 6ES7 143-xxx). 8 or 16 channels of DI, DO, or AI in a single IP65/67 block.
• ET200MP — newer modular station, primarily PROFINET (IM 155-5 PN, 6ES7 155-5AA00-0AB0). Included here for completeness when used behind an IE/PB Link as a PROFIBUS segment.

For each station the CPU maintains a logical base address map (input image start address / output image start address) per slot. The OB 82 and SFC 51 mechanisms rely on this logical address to identify which slot is reporting the fault. The PROFIBUS address (1..124 for standard masters, up to 244 with repeaters) is set on the IM with the address switch or via STEP 7 / TIA Portal "Assign PROFIBUS address" tool.

Diagnostic Architecture: Node-Level vs. Module-Level

PROFIBUS DP defines two levels of diagnostics that both travel inside the same DPV0/DPV1 telegram and are processed by the CPU as different OBs:

A PROFIBUS node analyzer such as ProfiTrace or a Softing PROFINET/PROFIBUS sniffer records the station diagnostic telegrams but does not decode the per-channel module-level diagnostic data unless the analyzer is also subscribed to DPV1 read/write traffic. For module-level isolation, the CPU itself is the most reliable source, because the standard diagnostic data is delivered inside the same Get-Diag telegram that the CPU already receives every cycle.

Reading DP Slave Diagnostics with SFC 51 "RDSYSST"

SFC 51 ("RDSYSST" / "Read SSL" / "Read System Status List") is the standard STEP 7 block that exposes the partial system status lists relevant to PROFIBUS diagnostics. For DP slave diagnostics, the relevant partial lists and their SSL identifiers are:

SSL identifiers 0x0131, 0x0132, and 0x0F31 are documented in the S7-400 system and standard functions reference manual; the bit mapping of the standard diagnostic bytes is defined by EN 50170 (PROFIBUS) and IEC 61784-1. The SFC 51 call may be placed inside OB 1 (cyclic), OB 82 (event-driven), OB 86 (event-driven), or OB 100 (startup). The official Siemens Industry Online Support entry for SFC 51 is at Siemens Industry Online Support, search term "SFC 51 RDSYSST".

STL implementation — cyclic DP slave health polling

// FB 100 — Cyclic DP slave health monitoring (call in OB 1)
// Input : i_slaveAddr : PROFIBUS address (1..244)
// Output: o_diagOK    : TRUE = slave responding and healthy
//         o_diagData  : 244-byte buffer of the per-slave status

CALL "RDSYSST"               // SFC 51
  REQ        := TRUE
  SSL_ID     := W#16#0094
  INDEX      := 1
  RET_VAL    := #retVal
  BUSY       := #busy
  SSL_RECORD := P#DB100.DBX0.0 BYTE 244    // 244 bytes, 1 per slave

// Evaluate byte[i_slaveAddr - 1]:
//   0x00 = OK, 0x01 = fault

STL implementation — single-slave diagnostic read

// FB 101 — Read extended diagnostic of one slave (call in OB 82 or OB 1)

CALL "RDSYSST"
  REQ        := TRUE
  SSL_ID     := W#16#0131
  INDEX      := #i_slaveAddr
  RET_VAL    := #retVal
  BUSY       := #busy
  SSL_RECORD := P#DB101.DBX0.0 BYTE 32

// Standard diagnostic byte 0..5 per EN 50170 / IEC 61784-1:
// Byte 0  : Station status 1
//           bit 0  = 1  slave cannot be addressed (NOK)
//           bit 1  = 1  slave not ready for data transfer
//           bit 2  = 1  configuration mismatch
//           bit 3  = 1  extended diagnostic available (most ET200 modules set this)
//           bit 4  = 1  request parameterization
//           bit 5  = 1  invalid slave response
//           bit 6  = 1  parameterization fault
//           bit 7  = 1  slave in station status NOK
// Byte 1  : Station status 2 (bit 0..7 reserved / slave-specific)
// Byte 2  : Station status 3 (bit 0..7 reserved / slave-specific)
// Byte 3..5 : Master address, identifier-related header
// Byte 6+ : Identifier-related diagnostic (channel-by-channel fault)

The identifier-related diagnostic bytes (positions 6 .. 31 in the response) are the highest-value portion because each bit maps 1:1 to a channel of the ET200 module, and the standard defines a fixed encoding for "wire break", "short to ground", "overload", and "module internal fault". Decoding them requires the module's GSD file or the STEP 7 / TIA Portal module catalog entry, because the bit layout is module-specific (e.g. the DIAG table for SM 322 DO 16x24V differs from the SM 331 AI 8x12bit).

Event-Driven Diagnostics with OB 82 and OB 86

OB 82 (Diagnostic Interrupt) is the most efficient way to identify the failing module without polling. The CPU calls OB 82 as soon as the operating system receives a diagnostic interrupt frame from the DP slave. The local data of OB 82 carries the information needed to address the module directly:

OB 86 (Loss of Rack / DP Slave Failure) is called when the entire station drops off the bus. It is the relevant OB for the "node fail for one second and then reset" symptom described in the original incident: the operating system logs OB 86 start (slave lost) and OB 86 return (slave back) events back-to-back in the diagnostic buffer, and any incoming OB 82 during the same time window identifies the per-channel cause. OB 86 variables include OB86_FLT_ID (16#31 = slave lost, 16#32 = slave returned, 16#33 = slave not reachable, 16#34 = slave OK, 16#35 = slave faulty, 16#36 = OK, with redundancy variants), OB86_MDL_ADDR (logical address of the station's first slot), and OB86_RACK_NUM (station number / PROFIBUS address).

STL capture pattern in OB 82

// OB 82 — Diagnostic Interrupt
// Local data layout (S7-400, 20 bytes of OB 82 start info)

      L     #OB82_MDL_ADDR
      T     "diag".lastMdlAddr        // store last logical base address

      L     #OB82_IO_FLAG
      T     "diag".lastIOFlag

      L     #OB82_FLT_ID
      T     "diag".lastFltId

      L     #OB82_SLOT
      T     "diag".lastSlot

      L     #OB82_RACK_NUM
      T     "diag".lastRack

      CALL  SFC 1                      // SFC 1 "READ_CLK" — system date/time
      RET_VAL := #retVal
      CD     := "diag".lastDateTime

      CALL  SFC 64                     // SFC 64 "TIME_TCK" — high-resolution tick
      RET_VAL := "diag".lastTick

// Append to ring buffer DB 200 (32 entries, 20 bytes each)
      L     "diag".ringPtr
      +     1
      L     32
      MOD
      T     "diag".ringPtr
      SLD   5
      LAR1
      L     DBB [AR1,P#0.0]
      ... copy 20 bytes of OB 82 start info + timestamp ...

Capturing the timestamp is the key to correlating a one-second OB 86 event with the OB 82 event that the field engineer sees on the HMI. The combination of OB 86, OB 82, SFC 1 (system time), and SFC 64 (high-resolution tick, 10 ms typical on S7-400 CPU 412/414/416) provides a deterministic record of every event, even if the fault self-clears before the engineer can connect a programming device.

Online Hardware Diagnostics in STEP 7 and TIA Portal

For non-transient faults, the fastest path is the online "Diagnose Hardware" view in STEP 7 V5.x (component "Station Configuration Editor" or "HW Config → Online → Diagnose Hardware") or TIA Portal (project tree → Devices & Networks → online view). Connect online to the CPU, open the project, and on the DP master system double-click the affected station. Modules with active diagnostics show a red fault icon and a textual description in the lower pane. Double-clicking the faulty module opens its "Module Information" dialog with the following tabs:

• General — module order number (MLFB), firmware version, slot, input/output start address.
• Diagnostic Buffer — entries from the module's local buffer; the latest event is at the top.
• IO Status / Channel Diagnostics — channel-by-channel state; "wire break" or "short circuit" appears next to the affected channel number.
• Quality Information — for analog modules, shows wire break, overflow, underflow, range violation.

For ET200M, the most common diagnostic entries in this view are:

• "Channel x wire break" — sensor cable open circuit (DI 24 V with diagnostic enable, AI 4..20 mA).
• "Channel x short circuit to ground" — actuator cable short (DO 24 V 0.5 A or 2 A).
• "Module internal fault" — module itself has failed; usually combined with the SF LED steady-on.
• "External auxiliary voltage missing" — load voltage 24 V not present at the module's L+ terminal.

The "Diagnose Hardware" view refreshes on connect, which is why it cannot capture a one-second transient. The ring buffer described above is the only way to capture those events. In TIA Portal (V15 and later), the equivalent is the "Online & diagnostics" view on the CPU and on each device. The diagnostic status is also exposed through OPC UA server (S7-1500) but is not directly available on S7-400 — the CPU's diagnostic buffer is read via the same PG/OP connection.

External PROFIBUS Analyzers and Physical Layer Tools

When the field engineer suspects a physical layer problem (intermittent bus, EMC, cable damage, terminator missing, segment too long), an external PROFIBUS analyzer is the correct first tool. The two industry-standard products are:

• Procentec ProfiTrace 2 (with ProfiHub or ProfiCaps) — captures the live bus traffic, decodes DP master / slave telegrams, and records the bus health over time. Includes a "Bar graph" of signal quality per slave, an automatic topology scan, and a statistics window showing retries, fall-through, illegals, and diagnostics frames per second.
• Softing PROFIBUS Tester BC-700-PB — handheld tester with oscilloscope view, signal quality indicator, topology scan, and live slave scan. Useful for commissioning trips when a laptop is not available.
• HMS Anybus PROFIBUS diagnostics — eBook and PC-based tools covering line diagnostics, signal integrity, and slave health. The HMS Anybus PROFIBUS Diagnostics whitepaper (PDF) covers the most common PROFIBUS faults and their identification.

These tools do not replace SFC 51 or OB 82 for module-level identification, because the DP standard telegram structure does not include channel-level data unless the slave is configured in DPV1 mode. Use the analyzer to confirm the bus is healthy (signal level > 2.5 V, retries < 5 per minute, no illegals), then move to the CPU-side mechanisms to identify the slot.

Capturing Sub-Second Transient Faults

The symptom "node fail for one second and then reset" is the worst case for the field engineer because the diagnostic screen refreshes only on the next online connect, and a transient that lasts under one second is gone by then. The reliable capture path is:

1. Create a global DB (for example DB 200) configured as a 32-entry ring buffer, 20 bytes per entry. Use a separate 32-bit event counter at the head so events can be ordered if the SFC 1 read is interrupted by a higher-priority OB.
2. Inside OB 82, store the OB 82 start info plus a timestamp from SFC 1 (system date/time, 1-second resolution) and a tick from SFC 64 (10 ms or 1 ms tick depending on CPU).
3. Inside OB 86, store the start info (slave lost / slave returned) plus a timestamp and a tick. The combination of OB 82 and OB 86 in the same ring buffer is essential because a slave-level event usually generates both, and only the time-ordering reveals the cause.
4. Provide a user-controlled FB that copies the ring buffer to a watchable area (e.g. another DB) and clears the buffer on operator action. Tie the operator action to a WinCC / TIA HMI button.
5. For very large plants, replicate the ring buffer per DP master system and tag each entry with the DP master ID (the second byte of the rack number from OB82_RACK_NUM).

This pattern preserves a deterministic record of every diagnostic event. After the next transient, the operator simply connects via STEP 7, opens the buffer DB online, and reads the last 32 events with timestamps. The combination of OB 82 (slot, channel) and OB 86 (slave lost) usually identifies the module within one fault cycle.

ET200 Module LEDs, Status Codes, and Failsafe Behavior

Even without a programming device connected, the LED pattern on the IM and on the modules narrows the search. The following table summarizes the most common LED behavior on the major ET200 families. Always cross-check with the module's own operating instructions, as the LED naming varies by module family.

If the IM is reporting SF, walk the modules in order from slot 1 onwards. The first module with its own SF or DIAG LED on is the culprit. This manual check is the fastest field method and does not require any software tool beyond a flashlight.

Failsafe modules (F-DI, F-DO, F-AI) — passivation behavior. When a diagnostic event is raised on a failsafe module, the module is "passivated": all outputs are de-energized (F-DO) or the input values are marked as "substitute safe value 0" (F-DI). The F-CPU records the passivation event in its F-runtime group diagnostics and, depending on the configuration, raises OB 82 with FLT_ID 16#1A and additional data. A passivated F-module must be reintegrated by the F-CPU after the cause is cleared, either automatically (if the F-block is configured for automatic reintegration) or manually (operator confirmation). The F-status word (e.g. F_DI_STATUS / F_DO_STATUS) carries the passivation bit and is the user-side read-back.

Troubleshooting Matrix and Verification Procedure

Verification and commissioning procedure

1. Compile and download the SFC 51 / OB 82 / OB 86 logic to the S7-400. Verify the new OBs and FBs are loaded (check the CPU's "Block" list online — the new OB 82 and OB 86 must show in the online block list with the latest timestamp).
2. Force a known diagnostic by unplugging one wire of an AI 4..20 mA channel on an ET200M SM 331 (with diagnostic enabled for that channel in HW Config).
3. Confirm that OB 82 is called. Check the buffer DB online — the slot, fault ID, and timestamp should match the SM 331 slot. The SFC 51 SSL W#16#0131 read should return non-zero identifier-related diagnostic bytes pointing to the same channel.
4. Reconnect the wire. Confirm that OB 82 is called again with FLT_ID = 16#1A and a "channel OK" event (status bit cleared, OB 82 start info indicates an event coming and going).
5. Disconnect the PROFIBUS connector on the IM 153-1 for two seconds. Confirm that OB 86 is called (slave lost, FLT_ID 16#31), then again on reconnect (slave returned, FLT_ID 16#32). The ring buffer should show the OB 86 event in between the two OB 82 events if there was a transitional fault.
6. Check the diagnostic buffer of the CPU (online → CPU → Diagnostic Buffer) for matching entries. The buffer should show "Slave faulted" and "Module fault" entries with the same time stamp as the SFC 51 / OB 82 records.
7. Mark all entries as "verified" and document the slot address, order number (MLFB), and firmware version of the verified modules for future reference. Save the HW Config screenshot in the project documentation.

Best Practices for Field Deployment

• Always implement OB 82 and OB 86. A CPU without OB 82 and OB 86 stops in STOP on the first diagnostic interrupt. For production lines this is unacceptable; the OBs can have a body as simple as "set a flag; do not return" but they must exist.
• Use a ring buffer, not a single DB slot. A single slot is overwritten by the next event and loses the history. A 32-entry ring buffer at 10 ms resolution covers approximately 5 minutes of transient events, which is sufficient for most intermittent fault investigations.
• Store the IM's PROFIBUS address as a constant per station in the SFC 51 INDEX parameter — never derive it from the diagnostic buffer, because the CPU's internal numbering may differ from the bus address.
• Wire the load voltage (L+) of the ET200 station with a dedicated circuit breaker. A load voltage dip is the single most common cause of a self-clearing OB 82 event on a DO module. Use an L+ monitoring relay (e.g. 6EP1 9xx) and route the trip to a DI on the ET200 station so the event is timestamped.
• For ET200M with SM 331 analog modules, enable the "wire break" diagnostic for each channel in STEP 7 HW Config (Properties → Inputs → Diagnostics enabled). Without this flag, wire break does not generate OB 82 and the event is invisible to the user program.
• Document the module order numbers and firmware versions in the HMI diagnostic screen. When a spare module is swapped in, mismatched firmware can cause a configuration-mismatch diagnostic (OB 82 FLT_ID 16#1E). The version is printed on the module's barcode label.
• For fault logs that need to survive a power cycle, use SFC 22 (CREATE_DB) and SFC 84 (WRIT_DBL) to flush the ring buffer to a flash card. The S7-400's load memory (MMC) is persistent across power cycles. Alternatively, send the entries to a WinCC archive tag that writes to the historian.
• For plants with mixed DP and PN segments, unify the diagnostics capture in the S7-400 by recording both PROFINET alarms and PROFIBUS interrupts in the same ring buffer. PROFINET alarms reach the CPU through OB 82 / OB 83 with the slot number 0..63 and a similar logical base address convention.

FAQ