Re: [foxboro] DM relative picks and dm variables question
- From: "Kubbenga, Otto" <otto.kubbenga@xxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Wed, 16 Jan 2008 03:49:50 -0500
Hi Tom, Brad,
A little comment on Tom's message below:
- since 4.2 the DM supports pop-ups, customized sized overlays (on
absolute location, or relative to picked location), ov_conn, and many
more overlay features. Actually this feature was developed specially for
4.2. FoxView came later (1996). (I should now, I was on both teams
DM/FoxView (-: ). =
- Please avoid using P1..P8 variables in overlays. If possible implement
the ov_conn dmcmd (open overlay with connect to C:B possibility)as
Philip mentioned. This is safer and improves performance. =
Disadvantage of using variables is that they will be substituted the
moment they are executed. That is, for example, when an action as
setting variable or toggle etc contains a variable, it will be
substituted when the action is executed (not during the open-overlay).
I.e. the variable may then be different and you are setting the wrong
c:b. So please, watch out using variables in overlays.
Good luck
Otto Kubbenga =
Consultant Advanced Applications
Invensys Systems N.V. =
A v e n t i s * E u r o t he r m * F o x b o r o * S i m S c i * T
r i c o n e x * W o n d e r w a r e
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Tom VandeWater
Sent: Wednesday, January 16, 2008 2:53 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] DM relative picks and dm variables question
Brad and Philip,
In my previous life at Dow Corning working with Duc and the boys,
Duc
and I developed quarter screen overlays that were configured much like
you
mention. We used p1-p10 variables. This was done using the DM on
UNIX. The DM pick on the base graphic that opened the overlay ran:
EXECUTE-->PROGRAM
=3D p1 CMPDNAME ; =3D p2 BLKNAME ; dmcmd script /usr/DC/fp/pida1
The dmcmd script called "pida1" and when executed, used the p1 and p2
variables as input, did a little more variable setting/substitution, and
then used the ov command to open the generic PIDA1 overlay in the upper
left
corner of the display. PIDA1 was built only for the upper left position
as
an unoptimized overlay. PIDA2 was built only for the upper right
quadrant.
That was all we allowed open at one time. A "SWITCH" button on the
generic
overlay allowed you to transfer the variables to the ones for the other
quadrant and then open the overlay for the opposite quadrant using the
same
CMPD:BLK. A TREND button on the generic overlay allowed the user to
call up
a dedicated, custom 1/4 screen TREND overlay in the opposite quadrant
for
that PIDA. Since the TREND was a custom built trend the settings for
the
TREND could be changed and saved by the user / operator. I'm not sure I
have seen that done in FoxVeiw although it should be possible.
To my knowledge the DM can only call fixed overlays within
quadrants of
the screen but doesn't allow floating overlays like Foxview. I could be
wrong about that but I don't think so. It also seems like the DM only
allows a maximum of three overlays called up at one time.
Shortly after my arrival as PM on a Tesoro Hawaii project, I got to
witness what Philip Pulas describes in his posting. Tesoro Hawaii is
using
the Faceplate/Overlays that Philip/Golden Eagle has implemented.
Although
there has been some confusion in implementation that caused improper
variables to be set at Hawaii initially, the issues have been resolved
and
the Foxview capability that Philip mentions is working for Tesoro HI.
It
has taken me a while to wrap my head around it all because of my limited
experience with Foxview/FoxDraw, but as Philip says, you can open many
overlays, of any size you decide to build, and they can be moved
around/repositioned anywhere on the screen with no apparent limitations
and
no pickability confusion using a limited variable set such as p1-p10.
Essentially, it works as if when each overlay is called from a base
graphic
"faceplate" it gets assigned a full path for each variable, making it
work as if you had built a dedicated custom overlay, but it does it on
the
fly. It is pretty slick.
Philip, do you know if this stategy was developed by Golden Eagle
or
was it something you inherited from elsewhere and customized?
Anyone
else that might be doing something unique with generic overlays please
share
your knowledge for the benefit of all.
Brad, I doubt you can reproduce the same results as Philip within
the
DM but am interested to know if anyone has done something close in DM.
As
for the Capital or Lowercase "p" variables I'm not sure, but I think
that
will work seamlessly, but we always used lowercase. The p1-p-8
variables
used to be the only ones automatically established by Foxboro as
defaults.
If you needed more than that I think they had to be added to the
init.cmdsfile?? I don't have a way of checking and all of this is
coming from
distant memories so I may need correcting. How about it Duc?
BTW, when newer DCS guys came along at Dow Corning and asked what
the
acronym "dmcmd" stood for, they were told it stood for Duc Man Computer
Man
Do ;<) I never had the heart to tell them any different because Duc is
a
god at DC and I was just a lowly apostle.
Cheers to All,
Tom VandeWater
Control Conversions Inc.
PM Tesoro Hawaii
On 1/15/08, Pulas, Philip <ppulas@xxxxxxxxxxx> wrote:
>
> Brad,
>
> This applies to FoxView and I haven't tried it in DM, but it might
work
> in DM also. How are the various overlays being called up? If they
are
> called up from a faceplate, then you can eliminate the usage of all of
> the P1, P2, etc. variables in the overlays. Configure the faceplate,
> which is linked to a compound block already, to call up the overlay
> using the following display commands (we use sticky overlays):
>
> close -nonsticky
> ov_conn -cb . -file [path_to_overlay] -sticky -ontop -pick
>
> If the overlays aren't called up from a faceplate, use the C:B
> hard-coded in place of the "." in the second line above. For the
> overlay, open "File | Display Properties" and check the box on the
> General tab for "Detail Overlay". Then, all of the connections and/or
> references to $P1:$P2, etc., can be replaced with "." on the overlay.
> This performs a run-time substitution of "." with the faceplate's C:B
> upon opening the faceplate. This also allows you to have multiple
> copies of the same overlay open in one FoxView window. Because "." is
> already substituted upon opening the overlay, as you switch between
any
> other opened copies of the overlay, no variables need to be reset and
> any actions that are configured on the overlay will be performed on
the
> correct C:B.
>
> Thanks,
> Philip Pulas
> Tesoro Corp.
> Golden Eagle Refinery
> Martinez, CA
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Wilson, Brad
> Sent: Friday, January 11, 2008 7:11 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] DM relative picks and dm variables question
>
> I'm working on a project that has 4 copies of every quarter-screen
> overlay. All the overlays are configured for position 1 (UL) and the
> quadrant is defined in the ov command. My question is about the
relative
> picks used when opening these overlays. The overlay to be used in UL
> uses p1:p2 for C:B, while the UR overlay uses p4:p5, LL overlay uses
> p7:p8, and LR overlay uses p10:p11. Is this a requirement that the
same
> overlay in different positions must use different variables to avoid
> confusion on the screen? I thought these variables were run-time
> substitutions.
> =3D20
>
> In addition, I find many overlays that use P1/P2 (capital letters)
> instead of p1/p2, and others that use P1/P2 in addition to p1/p2, even
> though the capital variables are not set in the dmcmd call. These
appear
> to be sloppy overlay configuration, but it seems that DM is able to
> translate the upper-case to lower-case on the fly, because I'm not
> getting smurfed connections in the overlays.
>
> =3D20
>
> Brad Wilson
>
> brad.wilson@xxxxxxxxxxxxxxxx
>
> Invensys Process Systems, Inc
>
> 1090 King Georges Post Rd, Suite 204
>
> Edison, NJ 08837
>
> 732-661-4012 o
>
> 732-874-0087 c
>
=
_______________________________________________________________________
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=3Djoin
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=
* Confidentiality Notice:
This e-mail and any associated files are intended solely for the individual=
or entity to whom they are addressed. Please do not copy it or use it for =
any purposes, or disclose its contents to any other person. Further, this e=
-mail and any associated files may be confidential and further may be legal=
ly privileged. This email is from the Invensys Process Systems business uni=
t of Invensys plc which is a company registered in England and Wales with i=
ts registered office at Portland House, Bressenden Place, London, SW1E 5BF =
(Registered number 166023). For a list of European legal entities within t=
he Invensys Process Systems business group, please click here http://www.in=
vensys.com/legal/default.asp?top_nav_id=3D77&nav_id=3D80&prev_id=3D77.
If you have received this e-mail in error, you are on notice of its status.=
Please notify us immediately by reply e-mail and then delete this message =
from your system. Thank you for your co-operation. You may contact our Help=
desk on +44 (0)20 7821 3859 / 2105 or email inet.hqhelpdesk@xxxxxxxxxxxxx T=
his e-mail and any attachments thereto may be subject to the terms of any a=
greements between Invensys (and/or its subsidiaries and affiliates) and the=
recipient (and/or its subsidiaries and affiliates).
_______________________________________________________________________
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:
