Unlocking Greyed-Out Message Classes on Function Blocks in SIMATIC PCS 7

In SIMATIC PCS 7 CFC, when the Message Class column in a block's message configuration dialog is greyed out and locked, it is because the message class property was locked at the master Function Block (FB) type level in the block folder. To unlock it, navigate to the S7 Program's Blocks folder in SIMATIC Manager, right-click the master FB, select Special Object Properties -> Message, click the padlock icon to unlock the desired message class, and save. In CFC, execute Options -> Block Types to update the block type across the project. Propagating this change requires a full AS compilation and full OS compilation, but allows online download in RUN mode without requiring a CPU stop.

PCS 7 Message Configuration and Class Locking Architecture

In SIMATIC PCS 7, alarm management relies on message attributes defined on technological Function Blocks (such as MonAnL, MotL, VlvL, or custom user FBs) using Alarm_8P (SFB35) or Alarm_DQ system functions. Each message definition consists of an Event ID, Message Text, Message Identifier, Priority, and Message Class (e.g., Alarm - High, Warning - Low, Tolerance, Operating Message, or Process Message).

To enforce corporate alarm management standards and prevent accidental modifications by commissioning engineers, Siemens STEP 7 provides a locking mechanism (padlock symbol) inside the block type definition. When a message class is locked at the block type level, every chart instance of that block inherited in CFC renders the Message Class column greyed out and read-only.

Root Causes of Greyed-Out Message Classes in CFC

An engineer opening block properties in CFC (Object Properties -> Messages) cannot modify the message class under the following specific conditions:

Master Block Padlock Enforced: The author of the FB (or the default Siemens APL library author) locked the message class in the block's Special Object Properties in the Master Data Library.
Standard Library Protection: Many standard APL blocks intentionally lock safety-relevant alarm classes to maintain ISA-18.2 / IEC 62682 compliance and prevent plant alarms from being inadvertently demoted to unacknowledged operating messages.
Instance-Level Inheritance: CFC instances strictly inherit locked type attributes. Overriding the message class for a specific instance requires unlocking the attribute globally on the master block type.

Message Class Locking Attributes and Download Requirements Matrix

The following table details the impact of unlocking message classes on project compilation and downloading:

Engineering StepScope RequiredCPU Mode (STOP / RUN)WinCC ImpactNotesUnlock FB in Blocks FolderMaster Data Library / S7 ProgramN/A (Offline only)NoneChanges block type templateUpdate Block Types in CFCEntire CFC Chart FolderN/A (Offline only)NonePropagates unlocked attribute to all instancesAS CompilationFull AS Compile mandatoryN/A (Offline)Updates S7 DB headersCFC changes-only compile is insufficientAS DownloadChanges Only DownloadRUN Mode permittedNoneFull CPU STOP download is NOT requiredOS CompilationChanges Only or Entire OSN/A (Offline)Updates Alarm LoggingRe-aligns WinCC alarm classesOS DownloadChanges Only DownloadRuntime active permittedLive update of alarm bannersOperator screens update seamlessly

Step-by-Step Procedure to Unlock and Propagate Message Classes

To unlock the greyed-out message class and reconfigure instance alarms:

Locate the Master FB in the Block Folder:
- In SIMATIC Manager Component View, navigate to your Master Data Library (or S7 Program's Blocks folder).
- Identify the Function Block (e.g., FB1845 or user FB).
Unlock the Message Class Property:
- Right-click the FB and select Special Object Properties -> Message.
- In the Message Configuration table, locate the column displaying the padlock icon next to the Message Class.
- Click the closed padlock icon to switch it to the Unlocked (open padlock) state.
- Click Save to update the block type template.
Update Block Types Across CFC Charts:
- Open any CFC chart in the project.
- From the CFC menu bar, select Options -> Block Types.
- In the Block Types dialog, select the modified FB in the chart folder list and click New Version (or transfer it from the Master Data Library).
- Confirm the prompt to update all instances.
Reconfigure Message Classes in CFC:
- Open the target CFC chart, double-click the block instance, and click Messages.
- The Message Class column is now editable. Select the desired message class from the drop-down list.
Compile and Download:
- Perform a Full AS Compilation in CFC (Chart -> Compile -> Chart as Program -> Scope: Entire Program).
- Download changes to the AS in RUN mode (PLC -> Download -> Scope: Changes Only).
- Compile the OS and download changes to the OS Server while runtime remains active.

Verification

Verify message class modification:
1. In CFC, open the block instance message properties and confirm the modified message class is retained.
2. Trigger the process alarm condition online in the controller.
3. In WinCC Runtime Alarm Logging, verify that the triggered alarm displays under the newly assigned Message Class banner (e.g., Warning instead of Alarm).
4. Check that the message color coding, horn assignment, and acknowledgment behavior reflect the updated class configuration.

Limitations and Operational Precautions

Full AS Compile Requirement: Modifying message class locking flags alters block type metadata, requiring a full AS compilation. Attempting a changes-only AS compilation will be rejected by the compiler.
Alarm Flood Risks: Demoting safety-critical alarms to non-alarm classes can mask critical process deviations from control room operators.
Master Data Library Consistency: Always execute the modification in the Master Data Library first; modifying blocks only in local project folders will cause changes to be overwritten during future library updates.

Engineer FAQ

Does updating message classes require putting the CPU into STOP mode?

No. While a full AS compilation is mandatory, the resulting delta can be downloaded to the S7-400 CPU in RUN mode using the standard Changes-Only download procedure.

Why does CFC prevent changes-only compilation after updating block types?

Updating a block type modifies the internal structural definition across all instances in the chart folder, invalidating previous incremental compiler signatures.

Will unlocking the message class on one block affect other instances?

Unlocking the class makes the property editable across all instances, but existing instances retain their current class values until individually modified.

Can I change message classes directly in WinCC Alarm Logging instead?

No. In PCS 7, WinCC Alarm Logging is strictly generated and overwritten by AS-OS compilation. Any manual modifications made directly in WinCC will be erased during the next OS compile.