Troubleshoot an X Alarm Display on a Customized PCS 7 MEAS_MON Faceplate
Treat an X alarm indication on a customized MEAS_MON as an unresolved message/display diagnostic, rather than assuming the Lock/Unlock button is faulty. In the reported PCS 7 V7.1 SP3 migration environment, standard DIG_MON blocks work while customized MEAS_MON instances do not. If the custom code uses ALARM_8P, inspect its ERROR/STATUS, message identifier and associated-value pointers, then check the matching OS references. No exact custom-block defect or successful correction was established.
Table of Contents
- Separate Message-State Failure from Lock Commands
- Inspect the ALARM_8P Call and Diagnostics
- Check Associated-Value Memory and Pointers
- Trace the OS Reference Back to the Actual Instance
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Separate Message-State Failure from Lock Commands
The reported environment is PCS 7 V7.1 SP3 on Windows XP, during staged migration toward V9.1. The customized MEAS_MON shows X indications in its faceplate, block icon and area display, while a standard DIG_MON behaves normally. Pressing the unlock control does not produce a lasting normal state.
That comparison localizes the investigation toward the customized block and its OS/message integration, but it does not identify a particular faulty SCL statement. The exact meaning of the custom faceplate's X indication must be verified against its implementation; it is not sufficient evidence that the operator lock button itself is defective.
Inspect the ALARM_8P Call and Diagnostics
If the customized block uses SFB 35 ALARM_8P, compare its actual interface and call with the historical Siemens system-function documentation.
The manufacturer defines ERROR and STATUS as processing diagnostics. Read them together. For example, the May 2010 manual documents ERROR = 1, STATUS = 21 decimal as the specified message being disabled, whereas ERROR = 1, STATUS = 1 decimal identifies communication problems. These are different diagnostic findings, not interchangeable interpretations of an X on the screen.
Inspect EV_ID, the associated instance DB and the message configuration using the actual project. The manual requires unique message numbers and explains that EV_ID is evaluated at the first call. Do not hard-code a replacement message number or force a faceplate state as a repair. System and Standard Functions, section 25.5
Check Associated-Value Memory and Pointers
The reply's suggestion about temporary associated values is a hypothesis worth checking, not a confirmed cause. The historical ALARM_8P parameter table lists SD_1 through SD_10 as ANY references to I, Q, M, D, T or C memory; local L memory is not included for those associated-value parameters.
- Preserve the customized block source and the pre-migration project.
- Inspect the actual SD parameters and determine which memory each ANY reference addresses.
- Check the declared data type, byte length and accessible memory range.
- For a DB reference, specify the DB explicitly as required by the documented interface.
- Compare actual ERROR/STATUS values with the manual before concluding that a pointer fault exists.
A bad associated-value pointer does not universally imply complete message loss: the manual also documents a condition where an activated message is sent without its associated values. Keep the diagnosis tied to the observed outputs.
Trace the OS Reference Back to the Actual Instance
As a project-specific diagnostic review, compare the customized block's message identifiers, generated OS tags and faceplate references with the intended AS instance. Confirm that the test station is using the matching compiled project and required custom block/icon/faceplate versions.
Use the working DIG_MON as a scope comparison, not as proof that the custom MEAS_MON's message implementation is correct. Do not copy DIG_MON parameters or replace the custom block without evaluating their different interfaces and behavior.
No manufacturer-verified event-state rewrite, exact custom-block correction or final successful recovery was established.
Verification
In an isolated test, verify the actual ALARM_8P ERROR/STATUS outputs and the OS indication before and after the reviewed correction. Trigger an authorized test condition and check incoming, acknowledgement and outgoing message behavior.
Then test locking/unlocking as a separate function and inspect the faceplate, block icon and area indication. A changed icon or a button that briefly changes state is not proof that the AS message path works.
Limitations and Operational Precautions
The customized source, faceplate implementation, migration sequence and actual diagnostic values were unavailable. The cited manual is historical S7-300/400 documentation from 2010; it supports the ALARM_8P interface checks, not a diagnosis of the specific custom MEAS_MON.
Preserve source code, project backups and a rollback state before changing the message interface. Compilation, message-number changes and AS downloads need their own reviewed deployment plan. Do not restart a production CPU or modify alarm suppression solely to clear an unexplained display symbol.
Engineer FAQ
Does the X prove the alarm is locked?
No. Establish the meaning of the custom display and read the actual AS/message diagnostics.
Is a temporary associated value a proven cause here?
No. It is an unconfirmed hypothesis; the documented memory-area restrictions provide a concrete way to inspect it.
Technical References
- Siemens — System Software for S7-300/400, System and Standard Functions, May 2010, Volume 2/2, section 25.5, pp. 515–517 — ALARM_8P identifiers, associated-value memory and processing diagnostics.