[Imported] Using analog output to change field alarm set points and detecting field change to set point
EcoStruxure Geo SCADA Expert Forum
Schneider Electric support forum about installation, configuration, integration and troubleshooting of EcoStruxure Geo SCADA Expert (ClearSCADA, ViewX, WebX).
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
You have entered an invalid email address. Please re-enter the email address.
This co-worker has already been invited to the Exchange portal. Please invite another co-worker.
Please enter email address
Send InviteCancel
Invitation Sent
Your invitation was sent.Thanks for sharing Exchange with your co-worker.
Link copied. Please paste this link to share this article on your social media post.
Posted: 2019-11-0502:05 PM. Last Modified: 2023-05-0312:33 AM
[Imported] Using analog output to change field alarm set points and detecting field change to set point
>>Message imported from previous forum - Category:ClearSCADA Software<< User: florian, originally posted: 2018-10-25 19:36:21 Id:284 This is a re-posting from the obsoleted (October 2018) "Schneider Electric Telemetry & SCADA" forum.
-------------------------------
**_hardin4019:_** **_Situation: I am wanting to setup Modbus Analog Outputs in CS to write a set point out to the alarm set point register in an RTU. This set point should never change at the RTU level unless changed by the Analog Output in CS. If it does change by user in the field or by some RTU logic or glitch, I want CS to recognize the change, and write the Analog Output back out again to correct the set point. What I am seeing right now, is I can use an Analog Output to send the set point to the RTU, and see it update both at the RTU and return the correct value in CS, then if I change the value in the RTU, after the next poll, the CS value changes. Is there a way to tell when a value changes, where/how the change was made, like it was from hand control in CS, Logic in CS, update poll from the field device? If there is a way to tell that the change in value was initiated in the field and the value no longer matches the previous value written out by CS, trigger a FBD to change the set point back, but not constantly run the logic to write the correct value to the Analog output causing the event log to record the event._**
-------------------
geoffpatton: Add an internal point or a variable, You can make a script that sets both it and the AO. Write a ST to run on input processed and have it compare the values and it they do not match set the AO to equal your internal. If the ST program has to correct the AO you can also have it set an internal digital to true and alarm off of that.
---------------
**_hardin4019:_** **_That was pretty much exactly what I was expecting to have to do if The answer to the other question was no._**
------------------
bevanweiss: The new ClearSCADA 2017R2 has new alarms for almost exactly what you are after. On field output points it's called Control Checks, and Uncommanded Change.
This would provide the alarm that the value has changed in the field, or through a mechanism other than ClearSCADA.
If you wanted, you could then have an alarm severity configured which would trigger an alarm escalation running a piece of logic that would cause the field setpoint change to be reverted. I'm not sure that I'd recommend this latter action however.
Where changes from the field are not supposed to happen (and for auditing and documentation purposes, they probably shouldn't) then I would recommend having the Uncommanded Change alarming. It can be considered as an Administrative Control applied against 'unauthorised setpoint changes' occurring (through a number of infiltration paths... obviously SCADA would still be an unguarded path)
-----------------
**_hardin4019:_** **_Now that you mention it, I remeber reading it in the release notes. We are still working our way into updating to 2017 R2 and this whole alarming on uncommanded change can likely wait until we are updated. Thanks for the reminder Bevan!_**