Re: [foxboro] global variable setpoint limiting
- From: "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 1 Apr 2005 14:38:18 -0500
Generic overlays do not optimize, i.e., they don't remember where the data
came from on the last call-up.
Displays do optimize. They record the location of the data in a section of
the graphics file.
Generic display call-up times are similar to the initial call-up of custom
displays.
In general, the use of more than one block in a generic graphic does not
make it slower since FV looks for the points in parallel.
Does this help?
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 Dehler, Glenn SCAN--
Sent: Friday, April 01, 2005 1:33 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
Alex,
I recall that custom overlays had faster call-up times.
Trying to use generic overlays resulted in having to bind to C:B.P at =
display call-up (probably dating myself here is FoxDraw 99.2.1).
What is the call-up time impact on using aliases with the newer version =
of FoxDraw (versus the older custom overlay bound to the C:B.P during =
build)?
Appreciate your thoughts
Regards,
Glenn Dehler
Shell Research Center
3655 36 Street NW T2L 1Y8
Calgary, Alberta Canada
Tel: +1(403) 284-6710 Fax: +1(403) 284-6662
Email: glenn.dehler@xxxxxxxxx
Internet: http://www.shell.ca
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of Johnson, Alex
(Foxboro)
Sent: Friday, April 01, 2005 12:24 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
If you like generic overlays in the DM, you'll love aliases and what =
they
can do for generic overlays in FoxView.
Aliases allow you to have a generic overlay that references more than =
one
C:B.
For example, you might have a tank compound with AIN blocks for level,
temperature, pressure, etc. With the alias, you can build a generic tank
overlay that references the blocks.
Moreover, with the integration of FoxDraw and IACC, you can drag and =
drop to
configure large parts of your HMI.
Of course, all of this requires you to actually use IACC and
FoxDraw/FoxView. :)
Regards,
=20
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: Friday, April 01, 2005 1:16 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
Alex Johnson said:
"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."
Thanks for the explanation Alex. BTW, we thought you WERE the boss, but =
if
not, you probably just told him because he's probably on the list too. =
;)
I like the generic approach of your script. This brings to the
table another discussion about generic overlays. We decided to develop =
them
after we attended a Southwest Users Group conference that was held at =
the
Dallas-Fort Worth airport in the early 90's. The host was the utilities
superintendent at the DFW airport, Wayne ???. That UG meeting was one =
of
the most productive ones I ever attended because both Foxboro employees =
and
users presented very practical and specific training on topics that =
users
had expressed an interest in before the meeting.
Generic overlays happened to be one of the topics. We came back to
our plant and worked on our version for more than a month but the =
results
have undoubtedly saved us thousands of hours in configuration, (and
reconfiguration), since that time. In conjunction with the generic =
overlay,
we implemented an alarm convention that changes the background color of
normal text that indicates the engineering units for each controller or
indicator on the base graphic. The convention makes the background =
color
flash red if the blocks' alarm is active but unacknowledged, solid red =
when
active and acknowledged, solid yellow if inactive but unacknowledged, =
gray
if alarm is inhibited, and white if none of the above conditions exist.
Picking on the controller or indicator opens a generic overlay for
that block type, (i.e. PIDA), using the specific C:B name desired. The
overlay is where all control actions, (acknowledge, manual, auto, local,
remote, setpoint, output, open, close, start, stop, ramp, and change =
alarm
setpoints), are initiated. The overlay is opened from the base graphic, =
but
only if the user has logged into an environment that grants him the
appropriate access class. This allows other users to look at the =
process
operation but not change control settings. We did this work while we =
were
still using WP30's. Today, 50 series DM's allow read-only DM's to be
defined.
We have eliminated the need to build thousands of custom overlays,
(and the disk space required to store them), by using this generic =
approach.
I know many other users have developed their own generic strategies and =
I am
interested in hearing about them either through the list or off list if =
you
prefer.
I have said it before and reiterate that I think Foxboro should
develop a canned generic overlay that all users could easily implement. =
It
seems like it would be especially useful for those sites that don't have
their own development resources. I have a few other ideas about a =
global
alarm strategy that would provide generic capabilities to users but I =
have
already "talked too much" today so I'll expound on that idea some other
time.
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 5:17 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] global variable setpoint limiting
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 =3D =
(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.
=3D=3D=3D=3D
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.
=3D=3D=3D=3D
Regards,
William C. Ricker
FeedForward, Inc.
Marietta, GA USA
770.426.4422
wcricker @ feedforward.com
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe: =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
_______________________________________________________________________
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:
