Simulating Channel Diagnostics with MOD_D8 in SIMATIC PCS 7

When attempting to simulate a digital module channel failure using the PCS 7 diagnostic block MOD_D8 (FB105) in S7-PLCSIM, setting the instance data block parameter DIAG_INF.CHDIAG to 16#FF will not generate process alarms on the WinCC OS. In Siemens driver architecture, 16#FF represents an unconfigured, default signal status rather than an active fault. Channel diagnostic byte codes require valid NAMUR NE107 / IEEE quality codes, such as 16#00 (Bad, device related) or 16#28 (Bad, process related). Furthermore, MOD_D8 generates system alarms via ALARM_8P when triggered by diagnostic interrupt organization block OB82; to simulate faults in CFC/PLCSIM, force input Mode to 16#40000000 or trigger a simulated OB82 hardware interrupt.

The Role of MOD_D8 in Module Diagnostic Processing

In SIMATIC PCS 7, hardware diagnostics follow a multi-tier driver hierarchy. When an 8-channel digital input or output module (e.g., SM 321 / SM 322 in ET 200M) is configured in HW Config, the compiler's Generate Module Drivers function automatically instantiates driver block MOD_D8 (FB105) in the AS program.

MOD_D8 serves as the intermediary between the CPU operating system's diagnostic interrupt mechanism (OB82) and the technological channel driver blocks (Pcs7DiIn). When a wire break, short circuit, or internal module fault occurs on a field channel, the module triggers OB82. MOD_D8 extracts the channel diagnostic record, asserts output Bad = 1, updates quality codes, and calls ALARM_8P to annunciate the failure on the Operator Station.

Why Setting CHDIAG to 16#FF Does Not Generate Alarms

When engineers test diagnostic logic inside S7-PLCSIM by manually writing hexadecimal values into the MOD_D8 instance Data Block, setting DIAG_INF.CHDIAG = 16#FF fails to produce alarms:

16#FF Meaning: In PCS 7 signal processing, 16#FF indicates an unconnected or uninitialized channel. The block treats 16#FF as an inactive spare channel and ignores it during alarm processing.
Event-Driven Execution: MOD_D8 does not poll CHDIAG cyclically to generate alarms. Its internal ALARM_8P message logic is triggered by the arrival of an OB82 diagnostic interrupt telegram. Simply editing a static DB byte while the CPU runs in OB35 does not invoke the message generation state machine.

Siemens Quality Codes and Diagnostic Status Byte Values

The table below details standardized Siemens quality status byte codes conforming to NAMUR NE107 and IEEE floating-point standards.

Status Byte (Hex)Quality StateDiagnostic MeaningController & Faceplate Impact16#00Bad (Device related)Channel failure, wire break, hardware faultTriggers diagnostic alarm; asserts Bad = 116#28Bad (Process related)Process limit failure, short circuitTriggers process alarm; asserts Bad = 116#68Uncertain (Device)Operating in degraded stateTriggers maintenance warning; sets Uncert = 116#78Uncertain (Process)Process dynamic approaching limitSets Uncert = 116#A4Maintenance RequestChannel requires calibration / serviceTriggers maintenance wrench badge on faceplate16#FFNot ConnectedChannel unconfigured or not evaluatedZero Alarm Impact (Ignored by alarm engine)

Comparison of Simulation Methods for Module Diagnostics

The table below contrasts methods for simulating channel faults during FAT and testing.

Simulation MethodTested Software LayerOS Alarm Generated?Feasibility in PLCSIMRecommended UseDriver Block Simulation (SimOn = 1)Technological block (Pcs7DiIn)Yes (Process alarm)Excellent (Native CFC inputs)Testing technological interlocksForcing Invalid Mode on MOD_D8Hardware diagnostic driverYes (Hardware fault alarm)High (Disconnect Mode pin)Testing diagnostic alarm bannerEditing CHDIAG = 16#FF in DBStatic data registerNO (Fails to trigger)Zero valueInvalid approachS7-PLCSIM OB82 Frame InjectionOperating system interrupt stackYes (Full system alarm)Requires SIMIT or PLCSIM ProTesting complete OB82 processing

Step-by-Step Procedure to Simulate Channel Faults in PLCSIM

Follow this procedure to successfully simulate channel failures and verify alarm annunciation:

Method A: Testing Channel Failure via Pcs7DiIn Simulation (Recommended)

Open the CFC chart containing the channel driver block Pcs7DiIn.
Set parameter SimOn = 1 to enable simulation mode.
Set parameter SimST = 16#00 (Bad, device related).
Observe downstream block (MotL): the motor trips on bad quality, output Bad = 1 asserts, and a fault badge appears in WinCC.

Method B: Testing Hardware Alarms via MOD_D8 Mode Manipulation

In the CFC chart containing MOD_D8, locate parameter Mode.
Temporarily delete the interconnection to MOD_D8.Mode (or disable Generate module drivers during test compile).
In online test mode, enter an invalid mode value: DW#16#40000000 (Module Fault).
Observe WinCC Alarm Logging: MOD_D8 calls ALARM_8P and generates the hardware diagnostic alarm in the alarm banner.

Verification

Verify diagnostic simulation through the following checks:
1. In CFC online test mode, verify that Pcs7DiIn.Bad = 1 and Pcs7DiIn.Out.ST = 16#00.
2. Open WinCC Runtime: verify that the process screen block icon displays the communication/channel error cross.
3. Check the WinCC Alarm Logging list: confirm that a system alarm (e.g., 'Channel error' or 'Rack failure') is actively annunciated.
4. Return SimOn = 0 or restore Mode: verify that the error clears and the alarm acknowledges properly.

Limitations and Operational Precautions

Before deploying software to a physical controller, remember to restore all deleted driver interconnections! Recompile the AS program with Generate module drivers explicitly enabled. If Generate module drivers is omitted, the compiler will not reconnect diagnostic addresses to physical modules, leaving the running automation plant completely blind to real-world field wire breaks.

Engineer FAQ

Can standard S7-PLCSIM trigger physical OB82 hardware interrupts?

Standard S7-PLCSIM does not natively generate simulated hardware wire breaks from the virtual rack. Testing true OB82 diagnostic sequences requires SIMIT Simulation Platform or manipulating driver inputs in CFC.

What block replaces MOD_D8 in newer ET 200SP configurations?

In modern PROFINET ET 200SP configurations in PCS 7 V9.0, module diagnostics are handled by MOD_PAL or MOD_D16_PN blocks.

Why did deleting QMODE_00 not generate an alarm?

QMODE_00 is an output pin reflecting the channel mode status to downstream blocks; deleting an output link does not inject a fault into MOD_D8's internal detection engine.