Troubleshooting Spurious BAD Quality Values on Pcs7AnIn Channel Drivers Caused by MOD_D1

In SIMATIC PCS 7, when an analog input channel driver (Pcs7AnIn) outputs Bad = 1 and quality code 16#00 despite receiving a normal 4-20 mA physical signal, the fault is propagated from the upstream system-generated module driver block (MOD_D1 or MOD_HA). The module driver evaluates diagnostic interrupts for the entire physical I/O module. If any channel on the module experiences a wire break, missing 24V DC sensor supply, or parameter error, or if unused channels have active diagnostics enabled in HW Config, MOD_D1 flags the entire module as faulted, passing bad quality to all channel drivers. Resolving this requires correcting physical module diagnostics in HW Config rather than bypassing the driver.

The Architecture of PCS 7 Signal Conditioning and Module Drivers

A common and perplexing issue in SIMATIC PCS 7 occurs when an analog channel driver block (Pcs7AnIn, FB 1869) reports bad signal status:
* On the CFC chart, output Bad.Value = 1 and Bad.ST = 16#80.
* The processed process value output PV_Out.ST drops to 16#00 (Bad, non-specific).
* On WinCC faceplates, the analog transmitter shows a red wrench / diagnostic alarm.
* Yet, when the instrument technician measures the physical field wiring with a multimeter, the transmitter delivers a perfect 12.0 mA (50.0% span), and the raw peripheral input word (PIW) displays normal counts (e.g., 13824).

Faced with this behavior, engineers sometimes bypass the channel driver block altogether—connecting the raw peripheral address directly to technological blocks (such as C_MEASURE in CEMAT or custom logic).

Bypassing the driver block is an dangerous antipattern that breaks NAMUR NE43 limit monitoring, forfeits automatic wire break detection, and hides physical hardware faults.

How MOD_D1 Propagates Fault Status to Pcs7AnIn

To diagnose the root cause, engineers must understand the symbiotic relationship between channel drivers and module drivers:

1. The Role of `Pcs7AnIn` (Channel Driver)

Pcs7AnIn does not communicate directly with the I/O bus operating system. Its primary role is scaling raw integer values into engineering units and formatting output structures with IEEE floating-point values and NAMUR NE107 quality status codes.

2. The Role of `MOD_D1` / `MOD_HA` (Module Driver)

When you compile CFC with Generate module drivers, PCS 7 automatically generates diagnostic charts containing MOD_D1 (for standard ET 200M modules) or MOD_HA (for redundant ET 200M/HA modules).
* MOD_D1 connects to the channel driver via the internal communication structure DXchg / DataHEx.
* MOD_D1 processes asynchronous diagnostic interrupts (OB82) and module removal/insertion interrupts (OB83).

3. The Whole-Module Diagnostic Trap

If a single physical condition affects the module—such as:
* An unused channel on an 8-channel analog input card has Wire Break Check enabled in HW Config, but no terminating resistor is installed.
* External 24V DC sensor transducer power (L+) to the front connector is disconnected or drooping.
* Configuration mismatch between the physical DIP range keys on the side of the SM 331 module and the software range declared in HW Config.

The module triggers an OB82 diagnostic alarm. MOD_D1 immediately detects the hardware fault and asserts ModErr = 1. In response, MOD_D1 commands every channel driver attached to that module to assert Bad = 1, even if channels 1 through 7 are functioning perfectly.

Comparison Table - Diagnostic Status Propagation (MOD_D1 vs Pcs7AnIn)

The following table details the diagnostic interaction between hardware events, module drivers, and channel drivers in PCS 7.

Hardware EventPhysical Field StateMOD_D1 Output StatePcs7AnIn Output (Bad / PV_Out.ST)Proper Engineering RemedyWire Break on Active Channel0.0 mA (< 3.6 mA)ChanErr = 1Bad = 1, ST = 16#00Repair field wiring or replace transmitterWire Break on Unused ChannelOpen terminal screwModErr = 1Bad = 1 on ALL channels!Disable wire break or jumper unused channelsMissing 24V DC Sensor SupplyNo L+ voltage at terminalModErr = 1Bad = 1 on ALL channels!Restore auxiliary 24V DC to front connectorMeasuring Range Key MismatchHardware key B, software key CModErr = 1Bad = 1 on ALL channels!Align hardware range cubes with HW ConfigModule Removed from BackplaneNo communicationRackF = 1Bad = 1 on ALL channels!Reseat module in active backplane bus

Step-by-Step Diagnostic and Resolution Procedure

To clear spurious BAD quality values on Pcs7AnIn and restore healthy module driver operation, follow this procedure:

Check Module Diagnostic Buffer in HW Config:
* Open SIMATIC Manager and launch HW Config.
* Go online (Target System -> Open Online).
* Double-click the faulted analog input module.
* Navigate to the Diagnostic Buffer tab.
* Read the explicit fault description (e.g., Wire break, Channel 7, External auxiliary voltage missing, or Parameter assignment error).
Disable Diagnostics on Unused Channels in HW Config:
* Switch HW Config to offline mode.
* Double-click the analog input module to open its properties.
* Navigate to the Inputs tab.
* For any unused channels:
- Uncheck Diagnostic Interrupt.
- Uncheck Wire Break Check.
- Set measuring type to Deactivated (or jumper input terminals M+ to M- if required by the hardware manual).
Verify Auxiliary Power and Range Keys (SM 331):
* Verify that 24V DC power is solidly wired to terminals 20 and 40 (or designated power pins).
* If using SM 331 (e.g., 6ES7331-7KF02-0AB0), remove the module and check the side-mounted range keys (A, B, C, or D). Ensure they match the software configuration (Key C for 4-wire current, Key D for 2-wire current).
Recompile Hardware and CFC Drivers:
* Save and compile HW Config. Download HW Config to the AS.
* Open CFC. Compile charts with Scope: Changes only and ensure Generate module drivers is checked.
* Download CFC changes to the CPU in RUN mode.
Verify Driver Reset:
* In CFC, open the diagnostic chart @... and inspect MOD_D1. Confirm ModErr = 0.
* Return to the process CFC chart. Confirm that Pcs7AnIn resets Bad = 0 and PV_Out.ST updates to 16#80 (Good).

Verification

Confirm that the channel driver and module driver have restored healthy signal propagation:

Verify CFC Driver Pins:
* Open the CFC chart containing Pcs7AnIn in Test Mode.
* Verify that Bad.Value = 0 and Bad.ST = 16#80.
* Confirm that PV_Out.Value equals the scaled engineering value (e.g., 50.0 PSI), and PV_Out.ST = 16#80.
Verify WinCC Faceplate Status:
* Open the associated transmitter faceplate (@PG_MonAnL_Standard.pdl or @PG_C_MEASURE.pdl).
* Confirm that all maintenance request / diagnostic icons disappear and the value displays in normal white/black font without error stripes.
Inspect Hardware LEDs:
* Inspect the physical analog input module in the control cabinet.
* Confirm that the red SF (System Fault) LED on the module face is extinguished.

Limitations and Operational Precautions

Never Bypass Channel Drivers Permanently: Connecting peripheral I/O addresses directly to technological blocks bypasses PCS 7 signal processing, quality codes, simulation modes, and flutter suppression, violating plant functional safety guidelines.
Redundant I/O Considerations (MOD_HA): In redundant I/O architectures using ET 200M / ET 200HA, if one module of a redundant pair faults, MOD_HA automatically switches signal acquisition to the healthy partner without asserting Bad = 1 on the channel driver, logging a maintenance event instead.
NAMUR NE43 Out-of-Range Trapping: If the transmitter current drops below 3.6 mA (undershoot) or exceeds 21.0 mA (overshoot), Pcs7AnIn legitimately declares Bad = 1 due to transmitter failure, even if MOD_D1 reports no hardware defect.

Engineer FAQ

Why did removing Pcs7AnIn and connecting directly to C_MEASURE make the value work?

Technological blocks like C_MEASURE only read raw integer counts from peripheral memory and perform linear arithmetic. They ignore module diagnostic interrupts. Connecting directly displays the number, but masks underlying hardware defects, wire breaks, and power supply failures.

Can I force Pcs7AnIn to ignore MOD_D1 faults?

You can configure Feature.Bit settings on some APL blocks or decouple driver links, but doing so compromises diagnostic integrity. The compliant engineering remedy is always to resolve the hardware fault causing MOD_D1 to alarm.

How do I determine which specific channel is causing MOD_D1 to trip?

Open the hardware diagnostic buffer in HW Config online (Ctrl+D on the module) or inspect output parameter O_MS on the MOD_D1 block in CFC, which provides a bitmask of channel-specific errors.

What does quality code 16#00 mean on PV_Out.ST?

In the PCS 7 Advanced Process Library, 16#00 represents 'Bad, non-specific'. It indicates that the channel driver has detected a severe failure (hardware fault, out-of-bounds current, or module error) and the value cannot be trusted for closed-loop control.

Technical References

Related Tags

Pcs7AnIn
MOD_D1
Channel-Drivers
Signal-Quality
APL
Diagnostics

6 respuestas

Troubleshooting Spurious BAD Quality Values on Pcs7AnIn Channel Drivers Caused by MOD_D1