Configuring PCS 7 V8.2 Boolean Tag Event Texts in CFC

Operating PCS 7 V8.2 with default Boolean tag messaging produces generic "Coming" (C) and "Going" (G) status indicators in WinCC Alarm Control. Plant operators need domain-specific status text such as "Normal" and "Failure" for digital channels. This guide shows how to configure custom event texts for Boolean tag status changes using MonDiS, Pcs7Din, and Alarm_8P blocks entirely from the Continuous Function Chart (CFC) and the OS text library, without manually editing each WinCC graphic. The procedure applies to SIMATIC PCS 7 V8.2 with the Advanced Process Library (APL) installed and follows the official configuration model described in the Siemens Industry Online Support documentation set for PCS 7 process automation and the PCS 7 APL library manual.

1. PCS 7 V8.2 Boolean Messaging Architecture

Every Boolean tag in a PCS 7 plant follows a fixed signal chain from the I/O card to the operator alarm log. Understanding the path clarifies where custom text must be inserted.

The default behavior of Alarm_8P raises an event whenever a SIG input transitions. If SIG=1 the message moves to the "Coming" state (C indicator). If SIG=0 the message moves to the "Going" state (G indicator). The text that the operator sees inside the descriptive column is hard-coded as "Coming"/"Going" unless an external OS text reference is supplied through the TEXT_n parameter on MonDiS.

For a 24 V DC supply monitor, the operator needs "Normal" or "Failure", not "C"/"G". The configuration below replaces the status indicator text with custom strings while preserving the alarm acknowledgment logic and allowing the engineer to suppress unwanted events at the alarm view.

1.1 Why the Default C/G Indicator Is Problematic

The "C" and "G" indicators are generated by the WinCC alarm view from the message state bits. Operators in continuous process plants rely on compact two-word descriptions such as Normal / Failure, Open / Closed, or Run / Stop. Replacing the literal characters with plant terminology speeds up triage, especially when several hundred alarms appear simultaneously on a fault train.

2. Prerequisites

The following items must be available on the engineering station before starting the configuration.

3. Configuring TEXT_0 and TEXT_1 References in MonDiS

The first configuration pass sets the text references associated with the MonDiS block. Each MonDiS instance carries up to 24 TEXT_n parameters. TEXT_0 and TEXT_1 are the two values referenced by binary states in the runtime.

3.1 Locate the TEXT_0 and TEXT_1 I/O

1. Open the CFC chart that contains the MonDiS block.
2. Right-click the block and select "Open Object".
3. Switch the I/O view to "Inputs" and scroll to the TEXT_0 and TEXT_1 parameter rows.
4. Inspect the default values. PCS 7 V8.2 typically initialises the fields with library placeholders such as OS_TEXT_10025 and OS_TEXT_10026. The values are symbolic references; the runtime resolves them through the OS Text Library.

3.2 Populate the OS Text Library

The OS Text Library is the master dictionary the WinCC runtime consults to resolve user-defined text. Add the same number of entries as the number of distinct TEXT_n parameters across the project.

1. In WinCC Explorer open "Text Library" → "OS Texts".
2. Allocate one free row per MonDiS instance. The OS index is generated automatically; the engineering value is the symbolic name.
3. Assign the engineering strings, for example:

Line    Index    Symbol           EN (English)    DE (German)
 1      10025    DY_Supply_Norm   Normal          Normal
 2      10026    DY_Supply_Fail   Failure         Störung
 3      10101    DY_Pump_Run      Running         Laufend
 4      10102    DY_Pump_Stop     Stopped         Steht
 5      10103    DY_Valve_Open    Open            Offen
 6      10104    DY_Valve_Cls     Closed          Geschlossen

4. Compile the OS via "WinCC Explorer" → "OS Project Editor" → "Text Library Compile". The editor is documented in the Siemens Industry Online Support portal under "PCS 7 V8.2 OS Configuration".

3.3 Assign the Indices to MonDiS

Once the entries exist in the OS Text Library, return to the CFC chart and place the matching indices into the TEXT_0 and TEXT_1 inputs of the MonDiS block.

Block:  MonDiS (FB 187) - DY_Supply
  TEXT_0 := "OS_TEXT_10025"   // value resolved at OS compile = "Normal"
  TEXT_1 := "OS_TEXT_10026"   // value resolved at OS compile = "Failure"
  ACK    := I0.0_ack           // operator acknowledgment from WinCC
  SIG_1  := Ib0_inverted       // see Section 4 for the inversion pattern
  SIG_2  := Ib0_direct         // optional second alarm path
  EN_MSG := TRUE
  SIM_ON := FALSE

After the next OS compile, the WinCC alarm logging view shows the operator text "Normal" or "Failure" inside the descriptive column of @alarmnew.pdl instead of the default "Coming"/"Going". The internal message state bits are unchanged, only the user-visible text is replaced.

4. Inverting the Signal for Normal/Failure Display

Two patterns cover virtually every plant requirement. The preferred pattern reuses the binary signal directly by mapping the asserted state ("1") to "Failure" and the released state ("0") to "Normal". This pattern also removes the need for a special "Going" event because the value 0/1 itself communicates the status.

4.1 Pattern A: Inversion Inline at the Channel Driver

If the only consumer of I0.0 is the alarm path, invert the signal at the channel driver using the inversion capability provided by Pcs7Din V8.2 (block family V8.x):

1. Open the Pcs7Din block instance in the CFC chart.
2. On the "Parameters" tab, locate the "Value inversion" toggle and enable it.
3. Wire the output directly to MonDiS.SIG_1 without an additional NOT block.

4.2 Pattern B: Insert a Logical NOT Block

For projects that already use Pcs7Din elsewhere with the native polarity (e.g. for interlock logic), insert a NOT element from the PCS 7 libraries between the channel driver and the message block:

  [Pcs7Din] Ib0 --+--> [NOT] --> [MonDiS.SIG_1]   (alarm trigger follows inverted value)
                  |
                  +-------> (other consumers, e.g. interlock/control logic)

The inversion guarantees SIG_1 == 1 corresponds to the failure condition (24 V absent equals "1" when using a normally closed contact). With this in place:

• TEXT_0 displays when the value is 0 → message reads "Normal".
• TEXT_1 displays when the value is 1 → message reads "Failure".

4.3 Choosing the Polarity

5. Driving Messages from the MonDiS Output to Support Simulation

The second complication reported in the field is that MonDiS supports a faceplate simulation toggle. When operators click "Sim on" inside the faceplate, the simulated value must drive the alarm trigger as well. If the alarm trigger is wired to Pcs7Din directly (instead of the MonDiS output), the simulated status will not raise an event because the process channel does not see the simulated value.

5.1 Where to Tap the Trigger Signal

The cleanest fix is to source the trigger from the MonDiS output Q or the public value output VALUE rather than from the channel driver:

  [Pcs7Din] Ib0 -----+--> [MonDiS.VALUE]
                      |
                      +--> (other consumers, e.g. control logic)

  [MonDiS.Q]   ------+--> [Alarm_8P.SIG_1]   // SIG follows simulation state
                     |
                     +--> [Pcs7Din2_VALUE]   // optional secondary path

5.2 How Simulation Routes Through Q

Inside MonDiS the SIM_ON input selects between the field value (taken from VALUE) and SIM_VAL. The block output Q reflects the SIG_1 evaluation on the selected stream. Wiring the alarm trigger to Q means every state change in either the field or the simulated value raises exactly one event. The Q output is wired through MonDiS's simulation logic so it follows whatever state the operator has chosen.

5.3 Faceplate Configuration

1. Open the MonDiS faceplate object properties.
2. Confirm Operator Control Enabled is TRUE for the SIM_ON and SIM_VAL switches.
3. Set the operator authorization level to "Process Operator" or higher. Engineers typically require level 3 or higher, per the "Authorization Levels" chapter in the PCS 7 V8.2 manual.

Once the trigger signal flows through MonDiS.Q, toggling "Sim on" in the faceplate changes Q and Alarm_8P raises the appropriate "Normal"/"Failure" event.

6. Using Sig4 and Sig5 for Enhanced Messaging

Several MonDiS variants (notably the OCM-enabled release) expose external message inputs SIG_4 and SIG_5 wired straight into the alarm block. Each SIG has its own TEXT_n pair. Designers can use SIG_4 and SIG_5 for supplementary labels when the binary signal conveys more than two states, e.g. "Manual / Auto / Remote".

7. Avoiding Duplicate Events Across Multiple MonDiS Instances

A common architecture mistake is to wire both the direct and the inverted channel values into two separate MonDiS blocks for "completeness". Each state transition then triggers two events:

  [Pcs7Din]  --> [MonDiS_Direct.SIG_1]    // "Coming" with TEXT_0 of direct
            --> [MonDiS_Inverted.SIG_1]  // "Coming" with TEXT_0 of inverted

The operator receives two simultaneous entries, one labelled "DC Supply Normal Coming" and one labelled "DC Supply Failure Coming". The duplicate message confuses operators and clutters the alarm log.

7.1 Recommended: Single MonDiS with Inversion

Collapse the design to one MonDiS instance. Use the inversion pattern from Section 4 and keep TEXT_0 / TEXT_1 on the single instance. Result: a single event per transition, with the right text.

7.2 Alternative: Hide One Event on the Alarm View

If business reasons require both direct and inverted paths (e.g. for separate acknowledgment of "rising" and "falling" alarms), remove the "Went Out" indicator on the operator view:

1. Open @alarmoneline.pdl via the WinCC Graphics Designer.
2. Right-click the alarm view and open "Configuration Dialog" → "Message Display".
3. Uncheck Went Out (German: "Gegangen") to suppress the Going indicator for this view.
4. Repeat on the New Alarm view (@alarmnew.pdl) if relevant.
5. Compile and activate the OS.

7.3 Identifying Duplication via Diagnostics

Open WinCC Alarm Logging on the operator station and filter by tag name. If the Event List shows two rows with the same timestamp but different status, the duplication is at the CFC side, not the view. Fix it as in Section 7.1 rather than hiding it.

8. WinCC Alarm Control Display Configuration

Even after the CFC side is wired correctly, the operator view must be configured to honour the new texts. The default @alarmoneline.pdl includes a Status column whose cells map directly to the Alarm_8P state machine.

8.1 Confirm Status Column Mapping

The Status column in the Alarm Control reads "C", "G", "A" (acknowledged) from the message state bits. The text values are read from the OS Text Library; if a TEXT_n index is invalid or empty, the column falls back to the literal "C" / "G".

8.2 Confirm the Status Column is Active

1. Open the Alarm Control properties dialog in the Graphics Designer.
2. On the "Columns" tab, ensure the Status column is selected and the column width is wide enough for the new text (e.g. 80 px instead of the default 40 px).
3. If "C" / "G" is still displayed, open the project language settings and retranslate the OS Text Library with the entire base set. PCS 7 typically carries a copy of the default OS_TEXT_BASE that must be overridden by importing your OS_TEXT_PROJECT entries.

8.3 Audit Alarms in WinCC Alarm Logging

Open the alarm log on a process operator station and verify the following for each Boolean tag:

• Source: tag name such as "DY_Supply"
• State: "Came In" / "Went Out" with the appropriate "C" / "G" bit
• Text: "Normal" / "Failure" rather than "Coming" / "Going"

Any row still showing "Coming" / "Going" indicates an empty OS Text Library entry. Re-add the missing TEXT_n index and recompile the OS.

9. Commissioning and Verification

After the wiring and library work, verify the change end-to-end before placing the system into production. The sequence below reproduces the most common verification tests for a single Boolean tag.

1. Stop the OS Runtime on the affected server before recompiling to avoid resource conflicts.
2. CFC download the chart: "CFC" → "Compile and Download Objects" in the SIMATIC Manager.
3. OS Compile via WinCC Explorer → "OS Project Editor" → "Compile OS".
4. OS Activate the server.
5. Force the input in the PLC using the Variable Table (VAT). For a discrete I0.0, force the value to 0 then 1 with at least 2 seconds between actions to ensure each transition is captured.
6. Observe the Alarm Line on the WinCC operator client. Confirm the message text reads "Normal" or "Failure", and that the status column shows "C" / "G" (the state machine is unchanged).
7. Activate simulation via the MonDiS faceplate. Toggle the simulated value and confirm a new alarm entry is raised. If no event is raised, the wiring in Section 5 has been skipped.
8. Acknowledge the alarm from the operator client. Confirm the "A" (acknowledged) indicator updates.
9. Go offline from the OS runtime, then back online, to verify the texts persist across OS restarts.
10. Check audit logs for any "OS_TEXT_x not found" warnings. PCS 7 surfaces these in the WinCC diagnostics window and in the WinCC system log under the Alarm Logging service.

10. Troubleshooting Matrix

The matrix below maps the most common field symptoms to their root cause and remediation step. Capture the symptom in the maintenance logs and consult the matrix before editing the chart.

11. PCS 7 V8.2 Compatibility and Migration Notes

PCS 7 V8.2 reflects the last generation before the TIA Portal integration push. Configuration patterns described above carry forward to PCS 7 V9.0 and V9.1 with the following adjustments. Use these notes when migrating an existing project.

12. Frequently Asked Questions