[foxboro] Relocating Workstations -- Solution

When I found that the problem I created extended beyond our in-house
applications and prevented Alarm History from functioning, I called Invensys
for help.  Gianluca Alfani found the answer.  What he found was curious.
Since I believe I am not the only who will ever swap two WPs, I thought I
would pass along the information.  
There is an ASCII file, /etc/fox/loghost, that should contain the name of
the logical host, i.e. the local AP or AW.  The two stations I swapped had
their own identity in /etc/fox/loghost. The other WPs in the room had the
correct information in /etc/fox/loghost.  The modification date on the
loghost files of the swapped stations was the same as the day that I first
tried to swap the machines.  The loghost file on the workstations I did not
change had a modification date that corresponded to the date we last
upgraded our software.

I believe I created a problem for myself when I forgot to change the DNBIs
the first time I tried to swap the workstations.  Apparently, when the ID of
the workstation and the ID of the DNBI did not match at boot up, the loghost
file got changed.  I don't know what did it or why... I only know that it
happened.

The proper procedure for swapping the location of two WPs is to power down
both workstations and their DNBIs.  Swap the annunciator panels and swap the
letterbugs on the DNBI.  Power up the DNBIs, then power up the WPs.


Chuck Jones
Refinery Automation Technologist
Tate & Lyle -- Lafayette South Plant
765.477.5324 - Office  | 877.536.9219 - Pager

"Growing up, I always wanted to be somebody.  I guess I should have been
more specific." -- Lily Tomlin


>  -----Original Message-----
> From:         Jones, Charles R. (Chuck)  
> Sent: Tuesday, January 04, 2005 3:21 PM
> To:   'foxboro@xxxxxxxxxxxxx'
> Subject:      Relocating Workstations
> 
> Greetings All,
> 
> I have a situation for which I have not yet found a solution.  I had to
> swap the locations of two machines within the same control room.  There
> are five workstations on the local node.  The AP is in the same room.  All
> six are 51 series machines in a standard Industrial Enclosure.  The cables
> are all securely tie-wrapped in place for protection in the event of
> nuclear blasts or tectonic plate shifts.  So, it was easier to power down
> and move the two boxes in the racks.  (I also swapped their annunciator
> panels.)  I found out (on the second attempt), if I change the letterbug
> on the DNBI, they will even come back up with the correct identity.
> Almost everything came back up and ran fine.  
> 
> The problem is that we have several in-house applications that run on the
> AP.  The operating displays for these functions reside on the AP and are
> called up from any of the attached workstations and run from there.  They
> continue to work for all of the stations except the two that were swapped.
> The swapped workstations can ping and be pinged.  The graphs on the
> swapped stations display fully populated with historical data, so that
> particular connection to the AP is established.  But, the in-house
> applications will not run from the swapped stations.  I checked one of the
> graphics in question to find the command line information that was passed
> via dmcmd script.  It was simply:  
> 
> /path/ApplicationName GCLBUG  &  
> 
> So, I got on the AP console, went to the appropriate directory, and typed
> in the command.  I could not force the display to appear that way, either.
> (I can, however, get this to work on any of the unaffected machines.)  I
> checked the log file created by the application and could see that it was
> working in the background, had populated the shared variables for the
> display (that didn't come up), and was waiting for a user response from
> the screen.
> 
> By the way, I have also rebooted the AP.  I didn't think it would help,
> but I knew it wouldn't hurt either.
> 
> So at this point, the problem appears to be that the letterbug designation
> is not functioning as I expect for the two affected machines.  I can't
> believe that I am the only one to have swapped the locations of
> workstation within the same control room.  Perhaps someone has sweated out
> the answer to this problem before. I believe I've ruled out Link-Layer,
> Network Layer, and Transport Layer problems.  Application Layer problems
> have their documentation so spread out that it is daunting to even guess
> where to look.
> 
> Does anyone know why I cannot get this to work?  
> 
> Chuck Jones
> Refinery Automation Technologist
> Tate & Lyle -- Lafayette South Plant
> 765.477.5324 - Office  | 877.536.9219 - Pager
> 
> 
> 
> 
*****************************************************************************************************
This email and any files transmitted with it are confidential and intended 
solely for the 
use of the individual or entity to whom they are addressed. If you are not the 
intended 
recipient or the person responsible for delivering the email to the intended 
recipient, be 
advised that you have received this email in error that any use, dissemination, 
forwarding, printing, or copying of this email is strictly prohibited.  If you 
have received 
this email in error please notify the sender immediately. Please note that we 
reserve 
the right to monitor and read any emails sent and received by the Company in 
accordance with and to the extent permitted by applicable legal rules.
*****************************************************************************************************


 
 
_______________________________________________________________________
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: