Resolving Siemens S7-400 Event ID 16#3842 on Profibus DP Encoders

When a Siemens SIMATIC S7-400 CPU (e.g. 6ES7416-2DP07) reports a flood of Event ID 16#3842 entries in the diagnostic buffer, each pointing to a single Profibus DP slave such as an absolute encoder, the symptom almost always points to a transient, repeatedly self-clearing module fault on that one slave. The difficulty is that only the outgoing "Module OK" event is recorded — never the incoming "Module Not OK" trigger that produced it. This reference decodes the event ID, instruments OB82 to capture the full diagnostic frame, and applies the physical-layer and EMC mitigations that eliminate the recurring interrupt in field service.

1. Problem Overview

On an S7-400 CPU 416-2DP, the diagnostic buffer is filled with a repeating event of the form:

Event 1 of 120: Event ID 16#3842
Module OK
Module type: Distributed I/O
Input address: 2011
User information available
Diagnostic interrupt from substitute
Requested OB: Diagnostic interrupt OB (OB82)
Priority class: 25
External error, Outgoing event
09:04:24.397 AM 05/01/2008

Key observations from a healthy-but-noisy Profibus DP network of 36 identical third-party absolute encoders:

• All 36 encoders share an identical STEP 7 hardware configuration (HW Config) and identical GSD file.
• Only the slave at diagnostic address 2011 produces the recurring 16#3842 event.
• The event is tagged "Outgoing" — the module is being reported as healthy again, not as having just failed.
• No corresponding "Module Not OK" or "Module Fault" entry for the same address is captured.
• The reported event continues to be appended while the line is in production, not only at startup.
• OB82 is being entered, but no application-side logic captures the OB82 local data, so the underlying cause is invisible to the control program.

The combination of these symptoms rules out a configuration error and strongly indicates a physical-layer or EMC defect that is local to a single Profibus node.

2. Decoding Event ID 16#3842

Siemens S7-400 diagnostic buffer event IDs follow a fixed hexadecimal scheme. For distributed I/O the high nibble 0x3_ identifies diagnostic events and the low two bytes describe the specific sub-event. The most common Profibus-related event IDs and their meanings are:

Event ID 16#3842 therefore decodes as:

• High nibble 0x38 = the event class is "diagnostic interrupt".
• Low byte 0x42 = the event is the "Module OK / outgoing" half of a diagnostic interrupt pair.
• Substitute = the source is a DP slave, not a central rack module. The CPU received the interrupt via the integrated DP master interface and forwarded it to OB82 with priority class 25.

The fact that 16#3842 is an outgoing diagnostic event means the slave has just transitioned from faulty back to healthy. The matching incoming event (typically 16#3841, 16#39F0, or another module-specific fault code) must have existed — but is not present in the buffer for the reason explained in the next section.

3. S7-400 Diagnostic Buffer Mechanics and Why Only Outgoing Events Appear

The S7-400 maintains a ring buffer of the most recent diagnostic events. The buffer is finite (typically the last 100 entries on a CPU 416 family); older entries are overwritten in FIFO order. Two important behavioral rules apply:

1. Every state transition generates both an incoming and an outgoing event, but if the slave is unable to hold the fault state long enough — for example, a one-cycle Profibus glitch — the incoming event may be overwritten by the outgoing event when the buffer is dominated by high-rate events from the same slave.
2. Some DP slave firmware versions collapse short-duration faults and emit only the outgoing 16#3842, treating the fault as a transient that the GSD file did not classify.

Combined, this explains why only 16#3842 is visible: the buffer is dominated by the 120+ entries from address 2011, and the brief incoming event is being pushed out of the ring before the engineer can view it. The "Event 1 of 120" header is the strongest indicator — the buffer is full of this single slave's outgoing transitions, and the incoming counterparts have already been rotated out.

4. Instrumenting OB82 to Capture Interrupt Context

Default OB82 in STEP 7 contains only a temporary placeholder that acknowledges the interrupt and returns. To log the actual fault code, channel information, and slave status, replace OB82 with an instance that reads the OB82 local data and calls SFC13 to dump the slave's diagnostic frame. The local variable layout of OB82 is defined in the STEP 7 Online Help under "OB82 — Diagnostic Interrupt":

Sample SCL body to deploy inside the project's OB82 instance (call SFC13 with the slave's diagnostic address to dump its current diagnostic frame):

DATA_BLOCK DB_OB82_Log
  STRUCT
    cnt       : DWORD;     // total entries captured
    lastEvID  : DWORD;     // e.g. 16#3842
    lastIO    : BOOL;      // 0 = in, 1 = out
    lastAddr  : WORD;      // DP slave diagnostic address
    lastFault : WORD;      // fault code from OB82 bytes 6-7
    diagData  : ARRAY[0..63] OF BYTE; // output of SFC13
  END_STRUCT
END_DATA_BLOCK

FUNCTION_BLOCK FB_OB82_Handle
VAR_TEMP
  retVal  : INT;
END_VAR
BEGIN
  // OB82 temp data (declarations must be added in OB82 itself):
  //   LB0..LB3   = Event ID
  //   LB4        = IO_FLAG (0=incoming, 1=outgoing)
  //   LB6..LB7   = Fault code (low/high)
  //   LB8..LB11  = Address of the slave (logical I/O base address)
  DB_OB82_Log.cnt := DB_OB82_Log.cnt + 1;
  // Copy event id and flags from OB82 temp area into DB
  // (use BLKMOV from the OB82 local temp area to the DB)

  // Read full diagnostic frame of the offending slave.
  // LADDR is the diagnostic address configured in HW Config
  // (here 2011) entered directly as a WORD.
  retVal := DPNRM_DG(
              LADDR   := W#16#7DB,   // 2011 decimal
              RET_VAL := MW 200,
              RECORD  := P#DB_OB82_Log.diagData DB 1000 BYTE 64,
              BUSY    := M 210.0);
END_FUNCTION_BLOCK

After loading this FB and wiring it into OB82, the engineer gets a timestamped record of the exact module fault code that caused each 16#3842 transition. If the OB82 local fault byte is zero on every entry, the slave issued only the "OK" half of the pair — which confirms the firmware-collapsing-transients theory and points the diagnosis toward the physical layer.

5. Profibus DP Physical Layer Inspection

Profibus DP uses RS-485 signalling. The most frequent cause of a single-node repeating interrupt on an otherwise healthy bus is poor signal integrity at the affected node. Inspect the following items in order, with the affected encoder (diagnostic address 2011) as the focus.

5.1 Connectors and Shield Termination

Use only Profibus-certified connectors (e.g. Siemens 6GK1500-0FC10 or equivalent IP20 D-sub, or 6GK1905-0AA00 IP67 M12) with integral terminating resistors that switch in only at the two physical ends of the segment. Verify the braided shield of the Profibus cable is bonded 360° to the connector backshell — pigtail shield terminations are the most common root cause of EMC-driven 16#3842 floods on encoder nodes.

5.2 Cable Specification

Use Profibus DP cable type A (characteristic impedance 135–165 Ω, capacitance < 30 pF/m, loop resistance 110 Ω/km, 0.64 mm² conductor). The maximum stub length per node is 0.3 m. Total bus length for type A cable at each standard baud rate is:

Every repeater resets the segment length budget. If the offending encoder is at the end of a daisy chain that approaches the segment length limit at the configured baud rate, signal reflections on that node are highly probable and the slave firmware will report a watchdog or parameterization fault.

5.3 Termination and Topology

Each segment must have exactly two terminations (one at each end, ON). Three or more terminations overload the RS-485 drivers and present as intermittent faults that the DP master reports as diagnostic interrupts from the affected slaves. A 36-node network also exceeds the 32-node limit per segment and requires at least one repeater — verify that 2011's segment is properly sized and that termination is enabled only at the two physical endpoints of each segment.

6. EMC Mitigation Strategy

When a single Profibus slave repeatedly self-reports faults in a noisy industrial environment, the most cost-effective diagnostic path is a four-step EMC sweep:

1. Measure waveform integrity. Connect a Profibus diagnostic tool (e.g. Softing Profibus Tester BC-700-PB, Indu-Sol PROFINET/Profibus diagnostics, or a Tektronix TDS3000 with Profibus triggering) to the segment containing the affected encoder. Look for amplitude asymmetry, edge ringing, and signal-to-noise ratio. Healthy signal must exceed 2.5 V peak-to-peak with rise time < 0.5 µs at 1.5 Mbit/s.
2. Re-verify shield bonding. Strip 30–40 mm of the Profibus cable jacket, lay the braided shield flat on the backshell clamp, and re-tighten the clamp to manufacturer torque. Avoid shield pigtails longer than 25 mm. If a conductive EMC gland is in use, verify it makes full 360° contact with the cable jacket.
3. Separate Profibus from power. Maintain at least 200 mm clearance between the Profibus cable and any VFD output cables or 480 V feeders. If crossings are unavoidable, cross at 90°. Do not run the Profibus cable and the encoder 24 V supply in the same bundle as motor power.
4. Add a Profibus repeater or diagnostic repeater immediately upstream of the affected node. Diagnostic repeaters (e.g. Indu-Sol DB 9 / DB 9-LWL) isolate the segment and report per-segment statistics. They also act as galvanic isolation barriers that block common-mode noise coupling between the master and the affected slave.

7. Capturing and Decoding the Matching Incoming Event

After instrumenting OB82 as described in Section 4, the OB82 local fault bytes and SFC13 response will reveal the source. Typical decoded values seen in field service of third-party Profibus encoders are:

If the SFC13 result on a single instance shows 0x08 (watchdog) appearing repeatedly on address 2011 and nowhere else, the slave's Profibus ASIC is timing out — almost always signal integrity. If 0x20 (cable break) appears, the encoder itself is faulty or its internal sensor cable has been damaged. If 0x10 (overcurrent) appears, the 24 V supply is sagging or the encoder is drawing excessive inrush on power-up.

8. Verification and Long-Term Monitoring

After applying the corrective actions, perform the following verification sequence:

1. Clear the diagnostic buffer in STEP 7 via "PLC > Clear/Reset Diagnostic Buffer".
2. Run the line under normal load for a minimum of 8 hours (or one full production shift).
3. Re-open the diagnostic buffer. The 16#3842 entries for address 2011 must be absent. A handful of other entries (e.g. startup events at cold start) is acceptable; a continuing flood is not.
4. Check the OB82 instance DB counter — it should remain at zero during the test period.
5. Pull the Profibus connector of the affected encoder to deliberately trigger a 16#3841/16#3842 pair. Confirm the new code now captures both incoming and outgoing events with non-zero fault bytes, proving OB82 is functioning correctly.
6. Reconnect the encoder and confirm the bus recovers without residual entries.

For long-term health, deploy a Profibus diagnostic repeater with segment statistics (e.g. Indu-Sol DB 9) and record signal quality, bus errors, and retries in the SCADA. A rising bus-error count on a single segment is the early warning that another 16#3842 storm is forming — and gives maintenance a chance to act before the diagnostic buffer fills again.

9. Common Field-Confirmed Causes of Recurring 16#3842 on a Single Node

10. FAQ