Welcome to the new Schneider Electric Community

It's your place to connect with experts and peers, get continuous support, and share knowledge.

  • Explore the new navigation for even easier access to your community.
  • Bookmark and use our new, easy-to-remember address (community.se.com).
  • Get ready for more content and an improved experience.

Contact SchneiderCommunity.Support@se.com if you have any questions.

Close
Invite a Co-worker
Send a co-worker an invite to the Exchange portal.Just enter their email address and we’ll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
84248members
353348posts

[Imported] Using analog output to change field alarm set points and detecting field change to set point

EcoStruxure Geo SCADA Expert Forum

Find out how SCADA systems and networks, like EcoStruxure Geo SCADA Expert, help industrial organizations maintaining efficiency, processing data for smarter decision making with IoT, RTU and PLC devices.

sbeadle
Janeway Janeway
Janeway
0 Likes
0
350

[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!_**