One of the primary challenges you may encounter is the sequencing of alarms. If the initial alarm activates after the scan flag has already passed, and a subsequent alarm triggers before the scan flag advances again, the alarms will not be in the correct order. In this scenario, the second alarm will be registered during the first scan, while the first alarm will be detected during the second scan. Based on my experience, this sequence issue is virtually unavoidable.
Hello Combo,
You mentioned having 3,000 alarms within your system. To enhance efficiency, it's essential to break down your processes into units, cells, or lines, depending on your operational structure. It's likely that your alarms are already categorized into logical groups. If you're looking to optimize a specific segment of your process, you may find that the total number of alarms can be significantly reduced. Additionally, consider how many of these 3,000 alarms are actively generating alerts. As Bob B pointed out, challenges related to scan order could pose the greatest obstacle for your operations.
Prioritizing the management of alarms and addressing scan order issues can streamline your process and improve overall operational performance.
**Title: Optimizing Alarm Sequence for 3000 Alarms in PLC Systems: A Solution Approach**
Combo shared: "Hello, I’m facing a challenging coding issue with our system. We manage machines equipped with 3,000 alarms, and some engineers aim to enhance the Overall Equipment Effectiveness (OEE) of our setup by determining the correct sequence of these alarms. Naturally, reprogramming the entire alarm logic for all 3,000 alarms is not feasible.
I've experimented with querying a database when a particular bit is activated, but this method has proven ineffective. Relying on SCADA or HMI systems is limited due to their acquisition time. Hence, I need to devise the right alarm sequence directly within the PLC.
I’m considering the following approach in the PLC:
1. Utilize a block copy to transfer the alarm bit data to a new database containing an array of bits.
2. Create a database with an associated array of Time-of-Day (TOD) values (Read Clock).
3. For each triggered bit, log the corresponding TOD.
4. Apply the Bubble Sort algorithm to organize all arrays by their TOD values.
What are your thoughts on this strategy?"
### Seeking Advice on ControlLogix Solutions
Since the processor isn't specified, I’ll assume you’re using the ControlLogix L71 or a more advanced version. I recommend employing the ALMD instruction for managing each of the 3,000 alarms. I’ve heard that FactoryTalk View can present alarm summaries with timestamps directly from the PLC, orderly arranged based on those timestamps.
While I don’t have personal experience with this particular solution yet, I have it on my agenda to explore implementing timestamp logging in the PLC for Sequence of Events (SOE) management.
Using this method will significantly improve your scan time, while maintaining a straightforward approach. If a ControlLogix system isn't available, I've successfully implemented timestamps directly in the PLC; however, I still need to identify an HMI that can accurately display the alarms in sequential order according to the PLC timestamps.
---
This rephrased version maintains the original message's intent while enhancing its readability and SEO-friendliness with relevant phrases such as "Overall Equipment Effectiveness," "SCADA," "HMI systems," and "Sequence of Events."
**Title: Addressing Multiple Alarm Activation in Siemens S7-317 PLC Systems**
Hello everyone,
Thank you all for your responses! I appreciate your insights. Currently, we are facing a significant challenge: when an alarm is triggered, multiple alarms become active at once. For instance, during a drive fault, we might see up to five alarms activating simultaneously. While the primary issue lies with the drive, the PLC program can generate additional alarm bits within the same cycle or during subsequent cycles. This results in a lack of order in the HMI Alarms and SCADA system.
Our HMI and SCADA system, powered by WinCC, interfaces with the Siemens S7-317 CPU. Unfortunately, the current configuration struggles to manage alarms effectively due to a polling rate of around 500 milliseconds from the PLC, which allows for the potential activation of numerous alarms within that brief timeframe.
Understanding the machine's workings is not my strong suit, and I don't intend to comb through 3,000 alarms for regrouping or altering the logic. Therefore, I am actively seeking an alternative solution.
@Lare: Your suggestion seems almost perfect for what I’m looking for! I’ve implemented a method involving an array of bits, where, upon a bit setting to 1, I send the corresponding array index number to a new alarm view window on SCADA with WinCC. However, this approach only captures one active alarm number at a time. If I loop using a ‘Repeat Until’ function, I only retrieve the first active alarm, and with the ‘Next’ function, I get the last one – which isn't effective for my needs.
One potential workaround is to iterate through the list (array of bits) to identify active alarms. When an active alarm is found, I can transfer its index to a new integer array (alarm numbers) and append it to the list (or FIFO structure). By utilizing a 'for-next' loop, I can effectively build a list of all alarms that were not triggered within the same cycle.
Once all alarms have been resolved, clearing that list will be straightforward. Although sequencing still poses a challenge when multiple alarms occur in the same cycle, most alarms do seem to appear in a sequential manner. For example, when an emergency stop is initiated, there is typically a delay before the air pressure alarm is activated, as the PLC requires a few cycles to process the physical changes and feedback.
Thank you for your support!
Best regards,
Gerry
We have an exciting development on the horizon: we are in the process of constructing a brand new manufacturing facility. To prevent future issues, I propose instructing our suppliers to integrate Prodiag into their systems. This solution will eliminate similar problems, as alarms are generated directly by the PLC. What are your thoughts on adopting Prodiag for our operations? For more information, check out this video: [Prodiag Overview](https://w3.siemens.com/mcms/automat...ortal-options/videos/pages/video-prodiag.aspx).
If your PLC lacks sufficient memory for this task, consider linking a timestamp to the alarm bit. You can implement an instruction that records the timestamp each time the alarm is activated. Additionally, it's worth noting that writing to the PLC’s diagnostic buffer can provide insight into the sequence of multiple alarms; while it may not be the most efficient solution, it can be helpful in certain scenarios. However, retrieving this information can be somewhat complex.
Check out my previous comment. It's important to note that in a Programmable Logic Controller (PLC), alarms may not always activate in a sequential order. This is due to the scanning process and the timing of when an alarm is triggered—there's no way to circumvent the scanning sequence!
Subject: Alarm Triggering Issues and Alarm Logic Optimization
Hello,
I completely understand your concerns regarding the alarm triggering system. The challenge lies in the fact that multiple alarms can activate simultaneously during a single scan. This same issue arises with Prodiag, where the sequence of alarms displayed may not reflect the actual order of events when multiple alarm triggers occur in the same scan.
From my perspective, the core issue stems from the way these alarms are programmed. For instance, certain alarms, like the air pressure alert, should not be flagged as serious alarms when an emergency stop is activated. This requires an overhaul of the alarm logic to effectively filter out unnecessary alerts based on their root causes.
Unfortunately, it appears that while the supplier has implemented all necessary alarms, they haven't prioritized the accurate representation of pending alarms or their correct sequence. This oversight is understandably frustrating for the engineers tasked with conducting Overall Equipment Effectiveness (OEE) assessments for this installation.
At this point, I believe the most effective solution would be to have someone review and modify the alarm logic to ensure better functionality moving forward.
Best regards,
Gerry
Additionally, as BobB noted, even within the PLC, alarm notifications may not appear in the correct order due to the nature of the scanning process. This is an inherent limitation that needs to be navigated.
Feel free to reach out if you have any further questions or insights.
Subject: Alarm Triggering Issues and Proposed Solutions
Hi,
I understand your concerns regarding the alarm system. It’s true that multiple alarms can activate during a single scan, which complicates the system. The same dilemma occurs with Prodiag; when more than one alarm is triggered, the sequence of these alarms is often out of order, creating further confusion.
A significant issue appears to lie in how the alarms are programmed. Certain alarms should be disregarded if the underlying cause is unrelated. For instance, an air pressure alarm should not be activated when an emergency stop is engaged. This discrepancy needs to be addressed in the alarm logic. Unfortunately, while the supplier has provided all necessary alarms, they did not prioritize the accurate representation of pending alarms or their correct sequences. This oversight is particularly frustrating for engineers assessing Overall Equipment Effectiveness (OEE) on this installation.
I’m not sure what the best course of action is, but I believe it may be wise for someone to revisit the alarm logic and implement necessary changes.
Best regards,
Gerry
P.S. If you continue to collect data under the current circumstances, it may only serve to verify your existing concerns without leading to a real resolution for the overlapping alarm groups. It’s akin to a scenario where a current loop opens, resulting in a hardware fault alarm, a current loop alarm, and a pressure/transmitter not available alarm, among others.
To effectively address this issue, we should establish a standardized approach applicable to all new builds and modify the software accordingly to prevent the generation of multiple alarms for the same incident. This will streamline the alarm system and improve its functionality.
### Enhanced Overview of Example Blocks and Alarm Integration
In this section, we present an in-depth look at two exemplary blocks that showcase the integration of a Profibus module. The bundled bits within the IO_Alarm are effectively linked to Human-Machine Interface (HMI) and SCADA systems, illustrating crucial alarm functionalities. For instance, the supply fault alarms are organized through the bits in O_Alarmen, which also connect to HMI and SCADA platforms.
The entire system is structured on an Object-Oriented Programming (OOP) foundation, with alarm sequences consolidated into a distinct alarm word situated outside each Function Block (FB). Notably, the grouping of these alarms is not categorized into separate classes for HMI or specific units; instead, they are aggregated according to equipment types. There exists a Function Chart (FC) for every category—such as one for all scanner objects, another for drives, and yet another for valves. The alarms are directly derived from these objects, indicating that internal object logic operates independently of other alarms.
Revising or overhauling this system poses challenges, particularly in an operational environment where downtime is not permissible. While the new factory setup presents opportunities for improved programming and organization of alarm logic, the current installation constrains our flexibility. Therefore, it may be essential to allocate a dedicated resource to focus solely on the reconstruction of the alarm logic, or alternatively, to maintain the existing setup as it stands for the time being.
By optimizing the structure of alarm management and integrating advanced programming practices, we can enhance the overall efficiency and responsiveness of our factory operations.
Combo expressed a crucial issue regarding alarm programming: certain alarms should be disregarded when triggered by unrelated factors. For instance, an air pressure alarm should not activate during an emergency stop. This issue needs to be addressed within the alarm logic framework.
Moving forward, I believe it's essential for someone to revise the alarm logic and ensure proper follow-up. Additionally, alarms should only activate based on the specific conditions outlined in their descriptions. If an alarm can be set off by alternative causes, the existing code fails to account for these possibilities.
To illustrate, monitoring the 24V power supply to the sensors can help. When the 24V supply fails, only the relevant alarm for the power failure should activate, while silencing all other sensor alarms. While implementing this approach can be challenging, I firmly believe it is the most effective method. We strive to maintain this practice as much as possible, even though achieving a perfect hit rate—where alarms only trigger under the conditions specified—is not always feasible.
Thank you, JesperMP! JesperMP stated: "Exactly! Alarms should solely be activated based on the conditions outlined in the alarm description. If an alarm can be triggered by other factors, then the underlying code fails to account for those alternative causes. For instance, when monitoring the 24V supply to sensors, if there is a failure in the 24V supply, it should activate a specific alarm for the 24V issue while silencing all other sensor alarms. Although this approach requires some effort, I believe it is the best practice. We strive to implement this as effectively as possible, even though achieving a 100% accuracy rate—where alarms are triggered only by the conditions specified in the alarm text—can be quite challenging."
Feel free to expand upon this discussion!
After dealing with numerous alerts and false incidents during a single scan, I implemented an event-logged bit for each specific event condition. This allows me to call a subroutine that records the timestamp and logs the occurrence into an array, subsequently marking the event as logged upon returning. For smaller systems, I typically allocate space for 32 events in this array. Additionally, I also route to the same subroutine whenever a condition is met, ensuring that both the change and the time are logged accurately.
Ventax shared their approach, stating: After experiencing numerous false alarms and unexpected events during a single scan, I started implementing an event-logged bit for each specific event condition. This approach involves jumping to a subroutine that timestamps and records the occurrence in an array before returning and setting the event-logged bit. For smaller systems, I usually allocate space for 32 events within the array. Additionally, I access the same subroutine each time a condition changes to accurately log the time and the event itself.
Given that this is a Siemens S7 PLC, it's worth noting that Siemens offers a robust solution for event-driven alarms, known as ALARM-S, which features precise CPU timestamps. The alarms, complete with multilingual text descriptions, can be integrated directly into the PLC project. When paired with a Siemens HMI, these alarms and their respective texts can be imported with minimal programming efforts. Furthermore, traditional bit-triggered alarms can seamlessly operate alongside the ALARM-S system.
This method not only enhances reliability but also streamlines the alarm management process, making it a valuable strategy for effective PLC programming.
ProDiag and PDiag in TIA likely utilize the ALARM-S feature, making ProDiag a potential option for future machinery implementation. However, a concern arises regarding alarms generated within the same scan cycle—don’t they share identical timestamps? When multiple triggers occur during a single scan without distinct timestamps, this situation could lead to an incorrect sequence of alarms.
Best regards,
Combo
In response, MP noted that since we are working with a Siemens S7 PLC, it's important to highlight that Siemens offers a robust, pre-built solution for event-driven alarms, known as ALARM-S. This system ensures accurate CPU timestamps for all alarms, which are programmed into the PLC project and can include multilingual text descriptions. If a Siemens HMI is incorporated, the alarms and their respective texts can be seamlessly imported with minimal programming requirements. Additionally, it’s worth mentioning that standard bit-triggered alarms can operate concurrently with ALARM-S for improved functionality.
The timestamps for the Alarm_S/D/8P are recorded with millisecond precision. It’s important to note that if two Alarm_S events occur in quick succession, they may share the same timestamp; however, this typically shouldn’t pose any issues. If you are utilizing WinCC, this specific alarm type can only be implemented if your WinCC project is integrated within your PLC project and you're employing AS/OS engineering. Additionally, if your project includes the S7-400, be aware of a limitation: the S7-400 model does not support Alarm_S blocks. Instead, it features alternative blocks known as Alarm_8 and notify. Please keep in mind that, unfortunately, Alarm_8 messages are not compatible with WinCC flexible panels, which could affect your project development.
Thank you for your input!
Thomas_v2 mentioned that the timestamps for Alarm_S/D/8P are precise to the millisecond. When two Alarm_S calls occur in quick succession, it’s possible for them to share the same timestamp. However, I don't believe this poses a significant issue. If you're working with WinCC, this alarm type can only be utilized if your WinCC project is integrated within your PLC project using AS/OS engineering. Additionally, if your project includes an S7-400, you will encounter a limitation: the S7-400 does not support Alarm_S blocks. Instead, it utilizes different types of blocks known as Alarm_8 and notify. It's worth noting that Alarm_8 messages are not compatible with WinCC flexible panels. For more information, click to expand.
For precise alarm management, nothing surpasses the performance of a PLC scan at the end of the line. The timing of when the alarm triggers during the scanning process is crucial, and other factors become irrelevant in this context.
Absolutely, you make a valid point. BobB commented: "For optimal alarm accuracy and stamping, nothing can compare to the PLC scanning process at the end of the line. The timing of the alarm within the scan cycle is crucial; the specific actions taken afterward are secondary." Click to learn more...