How to Show MonDi08 Diagnostics from a PCS 7 MotL Faceplate
To make MonDi08 diagnostics accessible from a MotL faceplate, use the documented additional-faceplate navigation mechanism as the closest verified implementation. A separately engineered motor summary message is another possibility, but it does not inherit the original alarms. Direct MonDi08-to-MotL message inheritance without EventTs is not established by the available evidence. The distinctions below use APL V9.0 interfaces and avoid inventing an alarm-summary output on MonDi08.
Table of Contents
- Separate Navigation, Summary and Alarm Inheritance
- Method 1 — Add a Documented Faceplate Jump
- Method 2 — Design a Separate Summary Message
- Full Message Forwarding Remains a Separate Requirement
- Verification
- Limitations and Operational Precautions
- Engineer FAQ
- Technical References
- Related Articles
- Related Tags
Separate Navigation, Summary and Alarm Inheritance
There are three different requirements: opening the MonDi08 faceplate from MotL, creating a new summary indication associated with the motor, and making the original MonDi08 messages appear with their identities and acknowledgement state inside MotL.
Do not treat these as equivalent. The V9.0 MonDi08 I/O table does not list a SumMsgAct output, so a generic SumMsgAct-to-MotL wiring recipe is not supported for this block.
Method 1 — Add a Documented Faceplate Jump
APL V9.0 documents freely assignable faceplate buttons in section 2.1.12.2:
- In a project copy, locate the MotL instance and the intended MonDi08 instance.
- Connect MotL's SelFp1 to an output of the intended target block for a standard-view navigation button, using the installed block's corresponding interface.
- Set an informative label through the OS additional text attribute for SelFp1.
- Process the engineering and OS changes through the applicable compile/deployment procedure.
- Open MotL's faceplate and verify that the button opens the intended MonDi08 standard view.
This provides access to the original diagnostic object. It does not copy its messages into the motor's alarm list.
Method 2 — Design a Separate Summary Message
MotL has documented binary external-message inputs, including ExtMsg1. They can provide a project-specific motor-associated indication when a separately designed Boolean condition is required.
Before implementing that adaptation:
- Define which monitored conditions should contribute, including their active polarity and enable state.
- Decide how suppression, startup, maintenance and bad signal status should affect the summary.
- Map the reviewed summary condition to the appropriate documented MotL external-message interface.
- Configure a truthful summary text and verify its behavior separately from the original MonDi08 messages.
This is a new summary message, not inheritance of the original message identities, timestamps or acknowledgement. No universal OR of all Out signals is prescribed because the intended alarm semantics are unknown.
Full Message Forwarding Remains a Separate Requirement
For MotL V9.0, Siemens documents EventTsIn and EventTs2In connections from EventTs or Event16Ts to display those message-block alarms in the technology faceplate. That does not establish a corresponding direct connection from an arbitrary MonDi08 instance.
The exact requested full MonDi08-to-MotL inheritance without that message-block approach remains unresolved. Do not connect MonDi08 to an ANY interface merely because CFC allows a pointer-shaped connection; the receiving interface's documented semantics control.
Verification
Verify a faceplate jump against the actual target instance. For a summary adaptation, exercise each intended condition individually and together under approved test conditions, and compare the resulting motor indication with the written summary rule.
Check suppression and acknowledgement separately. Confirm that operators can still identify and inspect the original MonDi08 alarm cause. A visible navigation button or a new summary message does not prove full message inheritance.
Limitations and Operational Precautions
The installed APL version and final engineering outcome are unspecified. This article supplies documented V9.0 navigation and external-message mechanisms, while the exact inheritance requirement remains under review.
Preserve the existing alarm configuration and do not replace independent diagnostic detail with an unexplained motor alarm. Review any effect on message duplication, operator response and alarm history before deployment.
Engineer FAQ
Can MonDi08.SumMsgAct be assumed to exist?
No. It is not listed in the opened V9.0 I/O table.
Does SelFp1 merge alarm lists?
No. It supplies navigation to another faceplate.
Does an external summary preserve individual alarm identity?
No. It is a separately configured message.
Technical References
- Siemens: Advanced Process Library V9.0, March 2017, A5E39147331-AA — sections 2.1.12.2, pages 203–204; MonDi08 sections 4.7.3–4.7.6, pages 533–541; MotL message connection and I/Os, pages 1070 and 1075. The manufacturer PDF was downloaded and read directly.