Re: [foxboro] DM relative picks and dm variables question
- From: "Tom VandeWater" <tjvandew@xxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Tue, 15 Jan 2008 15:52:50 -1000
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
= p1 CMPDNAME ; = 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.
> =20
>
> 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.
>
> =20
>
> 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=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
