Why PCS 7 Panel Alarms Remain Suppressed with Feature.Bit25 Cleared

Why PCS 7 Panel Alarms Remain Suppressed with Feature.Bit25 Cleared

Clearing Feature.Bit25 on an APL technology block does not, by itself, enable the Industry Library panel block's message path. For IL V9.0 SP1, Siemens documents the panel block's MsgLock as the relevant message-generation control and a separate MsgLock_Out connection for suppressing duplicate technology-block messages on the OS. Inspect those paths together, then verify the actual panel alarm list rather than relying on an icon.

Table of Contents

Understand the Two Message Paths

In the Industry Library V9.0 SP1 panel-integration concept, the panel block can provide messages for both the operator panel and PCS 7 OS. The APL technology block's original message path is then suppressed to avoid duplicates.

Feature.Bit25 belongs to the APL block's suppression behavior; it is not the panel block's master message enable. Inspect which block and message path are involved before changing it.

Documented PMotL and MotL Configuration

Siemens documents this concrete baseline for a PMotL/MotL pair:

  1. Connect PMotL's BlockConnector to a MotL output other than ENO.
  2. Set the panel block's MsgLock.Value to 0 for its message-generation path.
  3. Connect panel MsgLock_Out to the technology block's MsgLock structure, as documented for duplicate prevention.
  4. If CSF and ExtMsgx must also be suppressed on the original technology-block path, review Feature.Bit25 there according to the required design.
  5. Inspect DB_ConnErr, MsgErr, MsgSup and the relevant MsgStat outputs when investigating the actual instance.

This is an IL V9.0 SP1 PMotL example, not an assertion that the unidentified installation uses this block. Use the corresponding panel block's interface for another device type.

Inspect Panel Display Filtering Separately

The manufacturer's panel-integration chapter explains that message generation and instance filtering are separate. It also warns that required associated values in panel message texts must not be deleted or changed, because that can prevent display in the panel's message view.

As an engineering diagnostic sequence, first establish whether the expected message is generated on the intended path, then investigate the panel view and filtering. Do not conclude that a flashing icon proves delivery of a current alarm-list entry.

Verification

Under an approved test condition, generate a representative alarm and check its arrival, acknowledgement and return behavior on the intended panel and OS views. Confirm that the OS does not receive unintended duplicate messages from both paths.

Capture the panel-block lock and diagnostic state with the observation. Repeat after startup has completed rather than treating a transient startup suppression as permanent behavior. No successful correction is claimed for the unidentified installation.

Limitations and Operational Precautions

The affected IL version, panel model, technology block and message class were not specified. The article therefore establishes the documented V9.0 SP1 mechanism and a PMotL implementation baseline; it does not certify another combination.

Changing suppression affects operator alarm visibility. Preserve the current wiring and message settings, agree on the intended OS/panel message ownership, and verify both destinations before deploying. Do not clear all locks indiscriminately, which can defeat the intended duplicate-suppression design.

Engineer FAQ

Why is Feature.Bit25 = 0 insufficient?
It does not establish the panel block's MsgLock state or its message path.

Should the APL MsgLock also be cleared?
Not indiscriminately: the documented integration suppresses the original path to avoid duplicates.

Does an icon establish successful alarm-list updating?
No. Verify an actual message in the intended list.

Technical References

Related Articles

Related Tags

20 respuestas