Hi Terry,
I've experienced something as described by Tom twice now, each at a
different plant. The peer-to-peer connections were frozed on the sink side,
but there was no indication that the values were bad. Status showed good,
but the values didn't update. The impact was severe as most of the p2p
connections on the CP270 were affected. No amount of checkpointing each
side, delete-undelete then checkpoint, etc would fix the problem.
In the end, I performed an online-image update with a warm start (please
read olug manual for details and consequences). This re-built all of the
p2p without the need for a full CP reboot and thus avoiding a full plant
shutdown.
Hope you get to the cause of the problem,
--
Maks Wilde, P.Eng
Senior Control Systems Engineer
mwilde@xxxxxxxxxxxxx
www.kicsystems.ca
On Wed, Jan 25, 2017 at 2:20 PM, Tadeo Armenta <dmarc-noreply@xxxxxxxxxxxxx>
wrote:
RSOM both CPs to figure out how many IPC connections and lists you have
open on each CP
This would be my guess and what I would try to rule out:
FCP270 has maxed out the "source IPCs" there was someone else on the
waiting list.
As soon as you checkpointed the FCP280, it loss the IPC with the FCP270
(it should not happen), and the one on the waiting list, took the IPC .
When you checkpoint the source FCP270 it refreshes the IPCs and gives it
back to the FCP280 following its own order of IPC creation (and leaving the
other guy out)
--------------------------------------------
El jue, 1/26/17, terry.lloyd@xxxxxxxxxxxxxx <terry.lloyd@xxxxxxxxxxxxxx>
escribió:
Asunto: [foxboro] Peer To Peer Issue Causing Process Trip
A: foxboro@xxxxxxxxxxxxx
Fecha: jueves, 26 de enero de 2017, 05:17 am
Yesterday we had a CP Peer-to-Peer
issue that caused some valves to trip closed, which in turn
tripped our plant.
On closer investigation we found a number of BAD (cyan)
connections, some of these had also changed state from FALSE
(healthy) to TRUE (trip), even though the source block was
healthy. The sink end of the connection is an FCP280,
the source end of the bad connections came from two
FCP270's.
The event was triggered by adding new blocks to the FCP280
that were totally unrelated to the trip logic. Exiting the
ICC runs a checkpoint, and that created the bad peer to peer
connections.
The only way to resolve the bad connections was to
checkpoint the source CP then checkpoint the sink CP.
The images were updated to the latest available at the time,
after last June's advisory regarding Loss of Peer to Peer
Connections with CP270 or CP280.
We realised that this also happened here last October on the
same CP, but the resolution was different, i.e. delete one
bad connection, checkpoint sink CP, all bad
connections cleared, then rebuild connection, checkpoint ,
all ok.
A case has been raised with Schneider UK, they are looking
in to this now.
Has anyone else had similar problems with FCP280?
Regards
Terry
Terry Lloyd, Systems Engineer
-------------------------------------------------------------
Building W601, Mail BA111C
Voice: +44 (0)1446
723501
Dow Corning Ltd
Fax:
+44 (0)1446 723674
Cardiff Road
E-Mail: terry.lloyd@xxxxxxxxxxxxxx<mailto:terry.lloyd@xxxxxxxxxxxxxx
Barry
Vale of Glamorgan, CF63 2YL
-------------------------------------------------------------
Dow Corning Limited is a limited liability company
registered in England and Wales, registered number:
00486170, registered office address: Cardiff Road,
Barry CF63 2YL, UK
This e-mail transmission and any files that accompany it may
contain sensitive information belonging to the sender. The
information is intended only for the use of the individual
or entity named. If you are not the intended recipient, you
are hereby notified that any disclosure, copying,
distribution, or the taking of any action in reliance on the
contents of this information is strictly prohibited. Dow
Corning's practice statement for digitally signed messages
may be found at www.dowcorning.com/dcps<http://www.dowcorning.com/dcps>.
If you have
received this e-mail transmission in error, please
immediately notify the Security Administrator.
[cid:image001.jpg@01D27723.F3757E90]
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by
Schneider Electric
(formerly The Foxboro Company). Use the info you
obtain here at your own
risks. See the disclaimer at
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
_________________________________________________________________________
This mailing list is neither sponsored nor endorsed by Schneider Electric
(formerly The Foxboro Company). Use the info you obtain here at your own
risks. See the disclaimer at 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
