Re: [foxboro] Out of Service (Cyan) Points

Philip,

You may wish to try inserting the "no longer in service" letterbug into =
a module and plu git into the node.  The module is supposed to issue its =
litterbug on the node and wait for a boot host.  But at the same time, =
other stations are supposed to check the OM for lists with that =
litterbug and issue a close command.

To the others who have replied, thank-you.  I will look through your =
comments and see what we can apply to the site.

Terry

-----Message d'origine-----
De=A0: foxboro-bounce@xxxxxxxxxxxxx =
[mailto:foxboro-bounce@xxxxxxxxxxxxx] De la part de Pulas, Philip
Envoy=E9=A0: 17 avril 2007 13:06
=C0=A0: foxboro@xxxxxxxxxxxxx
Objet=A0: Re: [foxboro] Out of Service (Cyan) Points

Duc and/or Jeremy Milum,

We have also been experiencing the same "orphaned" OM list situation
here for quite some time on our Mesh network.  A reboot of the
referenced workstation clears them, but a few of these lists are tied to
workstations that we no longer have on our system.  We can't reboot the
CPs, etc., that these workstations left the "orphaned" lists on, which
would also clear the lists.

We have a script that was developed for us to identify the "orphaned"
lists, but we don't have one for cleaning up these lists.  Would it be
possible to share the script you use (send it offline or post it on the
cassandra site)?  It would be very helpful to remove the lists for
workstations that we no longer have!

Thanks,
Philip Pulas
DCS Systems/Controls Engineer
Tesoro Corp.
Martinez, CA

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of duc.do@xxxxxxxxxxxxxx
Sent: Tuesday, April 17, 2007 9:51 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Out of Service (Cyan) Points

Chuck,

I don't know if your problem is the same as Terry Doucet's problem, but
I think it's similar to what we experienced. I wrote about our problem
in June 2005:

http://www.freelists.org/archives/foxboro/06-2005/msg00034.html

The long and short of our situation is we can correlate our
seemingly-random cyan problem to the proliferation of "orphaned" OM
lists on the WP/AW-51s. I call them orphans because the processes that
opened them are no longer running when you run 'ps -eaf'.

Out of that thread, Jeremy Milum sent me a script and a little compiled
C program to close the "orphaned" lists in the WP/AWs. I run that script
every couple of weeks or so to clean up these orphaned lists, and we can
keep our WP-51s running for months.

Duc


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Jones, Charles R. (Chuck)
Sent: Tuesday, April 17, 2007 9:35 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Out of Service (Cyan) Points

Terry,
We experienced symptoms that seem similar.  We found a work-around and
we no longer see those symptoms.  I choose my words carefully here,
because I don't know for certain that we ever identified the actual
problem.

For us, the symptoms began as you described then progressed.  The next
phase of the symptoms was that a particular display would exhibit the
symptoms across multiple workstations.

I have a couple of questions.  Does the affected workstation typically
call up the same work area (is the WP hitting the same CP pretty hard)?
If that is true, does that CP have some equipment on it that is common
to all the other workstations (does this CP communicate with more
workstation--above and beyond the other CPs)?  We believe that in our
case, the problem was actually a CP overloaded with IPC connections.
The problem just manifested first on a particular workstation.

We also suspected--but did not know why--that this WP was leaving OM
tables open.  We suspected this because, once the problem began to
spread to other workstations, rebooting the "problem WP" cleared up the
connection issues with other workstations.  This would clear up the
symptoms for a while, but they always gradually came back.

The work-around I mentioned was to off-load some of the work done by the
CP.  That CP has a water system that is common to the entire plant.
Overtime, every operator in the plant wanted to be able to pull up the
water system display.  Since most just wanted to monitor the system and
were not allowed control, we set up "distribution points" in other CPs
(one on each of the other nodes).  These points (mostly AIN blocks
connected to the loaded CP instead of to an FBM) mirrored the data that
was needed from the original CP.  We then created new displays that
connected to these points instead of the original CP.  This reduced the
display related IPC connections from every WP in the plant down to just
the local WPs.  The symptoms were greatly reduced.  Later, during a
planned shutdown, we rebooted (we did not Initialize and LoadAll) the
CP.  We no longer see the symptoms. =3D3D3D20

Did it fix the problem?  I don't know.  The symptoms went away, though.
I don't know if this will work for you.  I am not absolutely certain why
it worked for us.  But, I remember the frustration of troubleshooting a
WP only to find out the problem was likely with a CP.

For comparison, we have a four node system at V6.1.1.  Each node has its
own AP51 surrounded by WP51s running DM.  Control is primarily done with
a truckload of redundant CP30As and a few CP40As.

Chuck Jones
Automation Technologist
Tate & Lyle -- Lafayette Plant
Office 765.477.5324 | Cell 765.586.5290


=3D20
=3D20
_______________________________________________________________________
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
=3D20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
to unsubscribe:      =3D
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
=3D20
=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
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: