Change the MOTL Feedback-Failure Indication in PCS 7 V9.0
In the reported PCS 7 V9.0 MOTL case, a blinking black S indicated an active, unacknowledged message assigned to the project's “AS process control message” class; it did not by itself indicate an active motor trip. The reply reports that assigning the feedback-failure message to “Alarm high” or “Alarm low” changes the indicator to A, but message-class labels and colors are project-specific. Verify the exact message and alarm philosophy before changing its class.
Table of Contents
- Why the symbol stays gray while S blinks
- Separate feedback monitoring from symbol appearance
- Assigning a more prominent alarm class
- Safe configuration and test sequence
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Why the symbol stays gray while S blinks
In the reported PCS 7 V9.0 case, the MOTL motor command dropped after its feedback delay expired, while the motor symbol remained gray and the faceplate showed a blinking black S. The forum reply identifies S as an active, unacknowledged message in the configured “AS process control message” class. The display is therefore conveying message class and acknowledgement state; it is not necessarily the motor's trip state. Siemens' APL V9.0 SP1 Readme cautions that alarm-class labels and colors depend on project-specific message-class settings.
Separate feedback monitoring from symbol appearance
First confirm the motor block's feedback input and monitoring delay are configured as intended, and that the feedback signal truly fails to arrive before timeout. The PCS 7 APL V9.0 SP1 Readme notes that static feedback monitoring at motor and valve blocks is active during control warning times. The indication after timeout depends on the generated message and its assigned class. Do not change a feature bit or block-icon color blindly to compensate for a signal or monitoring configuration issue.
Assigning a more prominent alarm class
If the site alarm philosophy requires the feedback-failure message to appear as an alarm, identify the exact message generated by MOTL and review its configured message class in the applicable APL/PCS 7 message configuration. The thread reports that assigning an “Alarm high” or “Alarm low” class changes the indicator from S to A in that project. This is a class change, not merely a cosmetic symbol recolor: confirm priority, acknowledgment, annunciation, and operator response with the site alarm standard before applying it.
Safe configuration and test sequence
- Record the installed APL library/block version and the current MOTL instance settings. 2. In a project copy or approved test environment, simulate the feedback-not-arrived condition and identify the exact message instance and current class. 3. Confirm the applicable message-class configuration and project-specific icon/color mapping. 4. If justified by the alarm philosophy, change only the relevant message's class using the version-matched engineering documentation. 5. Compile and test the active/unacknowledged, acknowledged, and cleared states, as well as the motor's command and feedback behavior. 6. Have operations and alarm-management owners approve before deploying to production.
Verification
During a controlled test, confirm that feedback loss after the configured delay produces the expected message, that the faceplate's acknowledgement indicator behaves as configured, and that acknowledging or clearing the message changes its indication correctly. Separately confirm the symbol reflects actual motor/trip state and that the command is removed as intended. A red A is not proof that the motor stopped safely.
Limitations and Operational Precautions
The ticket does not state the exact APL release, MOTL block version, message-instance configuration, or project-specific alarm-class mapping. The S to A behavior is reported in the thread and must be checked in the target project. Changing a message from process-control to high/low alarm can affect annunciation and operator response; do not use classification solely to obtain a desired color. The APL Readme's statement that class labels/colors depend on project settings reinforces the need to inspect the actual configuration.
Engineer FAQ
What does a blinking S mean in this report? The reply describes an active, unacknowledged message assigned to the “AS process control message” class.
Does gray mean the motor trip is active? Not necessarily. The source distinguishes the gray block symbol from the blinking message indicator; inspect the actual trip and feedback signals.
Can a feature bit force the symbol red? The discussion identifies no such feature bit. It points to the message class associated with the message.
Will changing the class to Alarm high/low change more than color? It changes message classification and can change alarm handling and acknowledgement behavior according to project configuration; check the plant alarm philosophy.
How should the timeout behavior be checked? Verify the actual feedback signal, configured delay, generated message, command reset, and faceplate states in a controlled environment.
Technical References
- PCS 7 Advanced Process Library Readme V9.0 SP1 (online), A5E42614514-AA, section 6, states that labels/classes such as Alarm, Warning and Tolerance and their icon colors depend on project-specific settings when user-configured message classes are used.
- PCS 7 Advanced Process Library Readme V9.0 SP3 (online), scope includes APL V9.0 SP1 and documents release changes; section 4.3 notes feedback monitoring at motor/valve blocks during control warning times.