Hello everyone, I am attempting to set up a rate of change (ROC) alarm for a setpoint tag. The goal is to have an alert trigger when an operator accidentally enters the wrong number (e.g. typing 30 instead of 300), prompting a confirmation message to ensure the setpoint is correct. I have successfully linked an application script to my programmable logic controller (PLC) to acknowledge and disable the alarm. However, I am facing an issue where the alarm does not return to its normal state after being acknowledged. Though disabling the alarm temporarily solves the issue, it reactivates on its own even if the operator has not entered a new setpoint. I am struggling to find a solution to this problem and would appreciate any advice or guidance. Thank you.
It seems there is a better approach to prevent operator errors by implementing maximum and minimum entry limits. Adding logic to restrict changes exceeding a certain percentage could also be effective. Additionally, incorporating logic to smoothly transition from the current setpoint to the new operator entry may further enhance error prevention methods.
Utilize the State Coil/Fault Coil pattern to set up an alarm circuit in your system. When configuring the trigger for the alarm, consider using the ROC event as a one-shot event. This means that when a ROC event is detected, the value that caused it should be stored for operator review. If the operator chooses to disregard the alarm by clicking "yes I did mean that value," the tag with the new value should be reset to the current setpoint. Conversely, if the operator acknowledges the alarm by clicking "no I did not mean that value," the ROC event will not trigger again until a new value is entered.
In order to enhance the reliability of preventing operator errors, Steve Bailey suggests implementing additional safeguards. One effective method is the use of a popup window requiring operators to enter new values into two separate memory tags. Only when the operator clicks the "accept" button and the two entries match will the new value be accepted and written to the IO tag. This approach supplements existing maximum and minimum entry limits by adding a layer of protection against unintentional data entry mistakes. It also provides a safeguard against accidentally inputting incorrect numeric values, particularly for critical data entries that can impact plant operations.
Cemass inquired about setting up a rate of change alarm for a setpoint tag to prevent operator errors, such as entering 30 instead of 300. While the alarm pops up correctly, the issue lies in it not returning to normal after acknowledgment. Using the PLC for logic instead of Intouch scripting is recommended. Create a simple logic to monitor setpoint entries and trigger the alarm when a deviation is detected. This can be implemented by using a condition script in Intouch to display a confirmation popup. After confirmation, the PLC can update the final setpoint value and reset the alarm. This approach ensures the alarm functions properly without reappearing unexpectedly.
Hello! It sounds like you’ve done some solid groundwork already. From what you described, it seems like the alarm condition isn’t being properly reset after the alarm is acknowledged. When you write your script, you should not only include the part that acknowledges the alarm but also the part that resets the condition (setpoint deviation in this case). If the condition isn’t reset, the PLC might interpret it as a continuous abnormal situation thereby triggering the alarm again. Also, ensure the reset logic isn't tied to the disabling of the alarm, but to the correction of the setpoint. Take another look at your script and try this approach. You might find it beneficial. Best of luck!
It sounds like you’re on the right track with linking your application script, but it might be worth exploring how the alarm's reset logic is configured. Sometimes alarms are set to remain active until explicitly reset, so consider implementing a condition that checks for a valid setpoint after acknowledgment, which could automatically reset the alarm once the conditions are met. Additionally, look into whether your PLC allows for a 'latch' setting for the alarm that ensures it only triggers under specific circumstances, which might help prevent it from reactivating without a new input. Good luck!
✅ Work Order Management
✅ Asset Tracking
✅ Preventive Maintenance
✅ Inspection Report
We have received your information. We will share Schedule Demo details on your Mail Id.
Answer: - To set up a ROC alarm for a setpoint tag in InTouch, you can link an application script to your programmable logic controller (PLC) to trigger an alert when an unexpected change occurs.
Answer: - If the alarm does not return to its normal state after being acknowledged, it could be due to a technical issue with the script or the alarm configuration. Troubleshooting may be needed to identify the root cause.
Answer: - To prevent the ROC alarm from reactivating on its own after being disabled, you may need to review the logic of the alarm setup and ensure that it is properly configured to reset once the setpoint is confirmed by the operator.
Join hundreds of satisfied customers who have transformed their maintenance processes.
Sign up today and start optimizing your workflow.