Re: [foxboro] global variable setpoint limiting
- From: "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 31 Mar 2005 17:17:22 -0500
Generic for all PIDs.
The script is a Bourne shell script and you can do math using 'bc' for
example.
Use omgetimp to get the ranges and such. You can derive the name from P1
which holds C:B.SPT.
If you wanted you could write a short program to do it too.
I should have mentioned using ramping. I can only offer in my defense that
I'm on the phone in a meeting. :)
Don't tell my boss.
Regards,
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of tom.vandewater@xxxxxxxxxxxxxx
Sent: Thursday, March 31, 2005 3:42 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
Alex,
I understand everything you said except I don't understand if the
script is custom for each PIDA or generic for all PIDA's. Also, are you
doing the math internal to the script or passing off to a math or calc
block? For Tim's purpose, the script would need to know either the
allowable engineering unit limit per each controller or the high and low
scale and a percentage.
For our PIDA's, we use a generic overlay. We define upper and lower
setpoint limits SPHLIM, SPLLIM and every block has SPROPT set to 3 = (Target
Over Time), and the generic overlay has an entry window for .SPTARG and
.SPRATE which always indicates Minutes to ramp to target. Once entered on
the generic overlay the operator can toggle .SPRAMP to begin a ramp to the
new target. This gives them time to insure that their entry is valid before
beginning a ramp. Ramping the setpoint is also much nicer to the process
than bumping a setpoint by 5% of scale all at once. We have a color
convention that allows the user to look at the base graphic and know if a
setpoint is currently being ramped. Our entire strategy is generic and
consistent.
Tom VandeWater
Control System Developer/Analyst
Dow Corning Corporation
Carrollton, KY USA
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Johnson, Alex (Foxboro)
Sent: Thursday, March 31, 2005 1:48 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
I've usually done this by:
1) Creating a pick point on the main graphic that loads P1 with the tag
(C:B.SPT) and raises an overlay (generic).
2) On the overlay
a) Displaying the current value
Connects to $P1
b) Having a data entry box
Connects to P2
c) Having a Confirm button
Runs a script that validates the setpoint and either:
i) Makes the change or
ii) Clears P2 and re-raises the overlay
d) Having a Cancel button
Closes the overlay
Works pretty well and can easily be implemented on your "standard" library
element used for showing the setpoint.
Hope this helps.
Regards,
Alex Johnson
Invensys Process Systems
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (switchboard)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of William C. Ricker
Sent: Thursday, March 31, 2005 12:25 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
Note that a MATH block takes a quarter the space of a CALC.
====
On one site where ops entry error was a concern, we took away
all numeric operator entry fields and gave them only ramp keys.
Crude, but effective.
====
Regards,
William C. Ricker
FeedForward, Inc.
Marietta, GA USA
770.426.4422
wcricker @ feedforward.com
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
