Re: [foxboro] Best practices in displays managing.
- From: Corey R Clingo <corey.clingo@xxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Fri, 14 Sep 2007 11:17:36 -0500
I too came from a TDC3000 background, and had to address the distributed
graphics issue when I inherited an I/A system. Fortunately I also knew
some Unix from some other work I was involved in so I wasn't averse to
writing the scripts to sync the displays.
One thing that made it challenging, and I bring it up because it has not
been mentioned in this thread yet, is the fact that an I/A station will
update its local copy of a display file with connection resolution
information the first time that display is called up. This has a couple
of ramifications: 1) the "last modified" timestamp will likely be later
than the last time the graphic was actually modified using Display
Builder/Configurator or Foxdraw, and 2) copying a display to a station
while that display was called up could cause problems ranging from display
corruption to station lockup. [Or so I've been told. I have accidentally
copied a graphic to a station that had it called up, or edited a graphic
that was displayed on that same AW, many times without incident. However,
we did see station lockups once with Foxview in a situation where several
folks were working on graphics and copying them around. YMMV.]
I wanted my script to be something that the graphic builder could run from
a button pick on a graphic, because we have non-admin folks building
graphics and don't want to have them in a terminal window for various
reasons. So what the script does is go through all our graphics
directories and look for files modified in the last day. It then further
refines this list by looking in each file to get the timestamp that
Display Builder or Foxdraw inserts in the file when it is saved, and only
copies the file if that timestamp is within the last day (this gets around
issue (1) above). That part works pretty well.
To get around issue (2) above, the script uses the "pref" command to
determine if a graphic that is to be copied is called up on any station.
If it is, another "pref" command is used to switch that station's
display(s) to a static graphic, the file is copied, and "pref" is used
again to switch the display(s) back to the (newly-copied) graphic. This
works pretty well, too, but gets slow for many files. Unfortunately,
"pref" cannot tell you what overlays are being displayed, so we just take
our chances with those, though I suppose we could unconditionally switch
to the static display to get around that.
I didn't want a scheduled mechanism for synchronization because if someone
was working on a graphic on an engineering station, but wasn't through
with it, I didn't want it to be copied around. Further, when you are
through editing and testing, you want it to be copied around right now -
not the next morning at 2 am when the scheduled task runs.
Corey Clingo
BASF Corporation
"David Vergara S. (SANTAFE - CMPC Celulosa)" <dvergaras@xxxxxxxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
09/14/2007 10:13 AM
Please respond to
foxboro@xxxxxxxxxxxxx
To
foxboro@xxxxxxxxxxxxx
cc
Foxboro Administrador <duc.do@xxxxxxxxxxxxxx>
Subject
[foxboro] Best practices in displays managing.
> Dear List:
> I found this issue very interesting in the "Barriers to migration
to
> Windows" thread.
> In your experience: Do you have some advise about displays residence /
> edition / distribution?
>
> We come from a Honeywell TDC 3000 DCS with a single network HDD,
> from where the same display is read from all the stations.
>
> The "station stored display" oriented strategy is new for Us.
>
> We are using this premises:
> 1.- The WPs are divided by AREA (~10) with 3 WPs each one.
> 2.- There is ONE "official displays building AW" for each area but...
> 3.- all AWs has ALL the displays stored in separated folders for each
> area.
>
>
> We are using MS explorer to distribute our displays over the network.
>
> *.- one problem is that we can't define "distribution groups" (... I
don't
> know how...), so we must type in the stations names one by one each time
> we want to distribute a schematic...
>
> *.- We are afraid about ambiguity in displays version (because
> distribution).
>
> *.-I have read that someone is using "blow" to distribute displays but I
> can't found any reference to it in our system.
> P92 - WinXp - I/A 8.2
>
> *.-What do you think about using Synchronization tools with scheduled
> tasks?
> regards,
>
> David A. Vergara S.
> CMPC Celulosa Planta Santa Fe
>
_______________________________________________________________________
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:
- » Re: [foxboro] Best practices in displays managing.
