Re: [foxboro] Best practices in displays managing.

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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: