I am assisting a client with two Human-Machine Interfaces (HMIs) — let's refer to them as HMI1 and HMI2 — that control adjacent areas. They aim to merge the interfaces of both HMI programs into a single application while retaining distinct startup screens for each HMI. Essentially, this would allow both HMIs to function independently but still enable seamless access between them. In practice, if HMI2 were to fail, the user would simply click a designated "GoTo" button on the HMI1 main screen, which would navigate to the main interface of the HMI2 program, granting access to all remaining screens associated with HMI2, and vice versa. The goal is for both HMIs to maintain their individual operations, with all screens available through the original main screen of each HMI program. I seek a solution that allows for alarm filtering based on the program currently being viewed, along with a Physical Button (PB) — let's call it PB1. For instance, when users are on HMI1 and wish to access HMI2, they can press the "GoTo" button on HMI1's main screen, which will then transition to the main screen of HMI2. This screen will include a "GoTo" option to return to HMI1, providing full access to all HMI2 screens from that interface. Moreover, I would like to implement an alarm filtering system based on the current "program" being viewed. If users activate PB1, they will see alerts from both HMIs. PB1 will be present on the main screens of both HMIs. I use the term "program" in quotes because, at this stage, they are not entirely separate applications; they have been integrated into one. The functionality should enable the following: - Access to either HMI from both HMIs without needing to navigate to the configuration settings to load different programs. - If both HMIs are operational and an operator wants to toggle between them (perhaps due to convenience), alarms should only appear for the program currently in use (PB1 = 0). - If one HMI is inoperative, operators should still be able to switch between the two programs while displaying alarms for both (PB1 = 1). While I recognize that this functionality exists in SE, I prefer to retain it within the ME environment. Any insights or recommendations regarding this setup would be greatly appreciated!
One of the simplest approaches to create custom alarm screens in ME is to design multistate indicators that specifically display only the alarms you wish to monitor within each application. In this setup, if the alarm status is "off," the small indicator will be green, while a "on" status will cause the indicator to flash red. You can also place the alarm description adjacent to the display box. However, as the number of alarms increases, this method may become less practical. Additionally, it may not be feasible to accomplish this solely with the native alarm features in ME. An alternative solution could involve programming at the PLC level; however, this could lead to complications such as automatically silencing alarms, which is generally not advisable.
When managing your alarms, it's beneficial to customize the filters for the triggers included in each list. Utilizing combined alarm trigger keywords that encompass multiple alarm bits can simplify this process significantly.
Are you referring to the Alarm List (History) or the Alarm Banner (Pop-up)? If it's the Alarm List that you mean, I recommend utilizing two distinct Alarm Lists, each with its own filter. The GOTO buttons can be programmed to select which Alarm display is active at any given time. On the other hand, if you're discussing the Alarm Banner, the approach will differ. Controlling the pop-up display requires modifying your triggers to support PB1, transforming each trigger into an expression. For example, if PB1 and HMI1 have an alarm, then it equals 1; otherwise, it equals 0. Similarly, for the scenario where PB1 is not active and HMI2 has an alarm, the expression would be 1; otherwise, it equals 0. A potential challenge arises when viewing HMI1, as no alarms will populate the Alarm List (History) for HMI2 due to the state of PB1, and vice versa. Alternatively, you could consider utilizing the INFORMATION DISPLAY feature. By mapping your alarms within the PLC to the corresponding connection word and consolidating all your messages in the Message file, you can leverage the PLC to control which INFORMATION DISPLAY appears based on the status of PB1. However, implementing this option would necessitate additional logic within the PLC. This optimized solution enhances your alarm management while ensuring that both the Alarm List and the Alarm Banner function efficiently based on your needs.
Upon reviewing your post again, it’s clear that you're interested in displaying either one set of alarms or both. To achieve this, you can utilize the Variable Display feature linked to your GOTO buttons. By navigating to the connection tab, you can craft an expression that determines the required Alarm Display based on the status of PB1. This approach involves creating three distinct Alarm Lists: one for each individual view and another for the combined view. Additionally, you'll need to implement tags to differentiate the various HMI views. In the connection tab, you would write an expression like this: `IF HMI1 VIEW AND NOT PB1 THEN "Alarm_Screen1" ELSE IF HMI2 VIEW AND NOT PB1 THEN "Alarm_Screen2" ELSE "Alarm_Screen3"` Here's how the alarms are organized: - **Alarm_Screen1** = Alarms for HMI 1 - **Alarm_Screen2** = Alarms for HMI 2 - **Alarm_Screen3** = Combined alarms for both HMIs It's important to note that the quotation marks designate these entries as strings, and they must correspond exactly to your display names. This setup will enhance your HMI's functionality by allowing dynamic display of alarms based on user selection.
User cwal61 mentioned that we would need to create three distinct Alarm Lists—one for each individual view and an additional one for both combined views. However, my primary focus is on implementing a banner pop-up notification system. It's essential for operators to receive immediate alerts regarding any alarm faults, particularly since one of the Human-Machine Interface (HMI) alarms does not utilize a buzzer for notifications. The current Alarm List setup only permits operators to see alarm faults when they actively access the display to view this list. I apologize for not providing this clarification in my original message.
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.