Re: [foxboro] P2P links locked
- From: "Schouten, Frits JF" <Frits.Schouten@xxxxxxxxxxxxxxxxxx>
- To: "'foxboro@xxxxxxxxxxxxx'" <foxboro@xxxxxxxxxxxxx>
- Date: Tue, 7 Sep 2010 08:22:40 +1200
Hi Dirk,
We've had that exact same problem and the only way we got it to go again was to
delete the link on the peer site and after the delete re-entering it. Don't
forget the 'DONE' after you delete the link and before you re-enter it.
The bigger issue is probably finding those 'dead' links.
Cheers,
Frits Schouten.
NZSteel.
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of dirk.pauwels@xxxxxxxxxx
Sent: Monday, 6 September 2010 11:38 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] P2P links locked
Hi list,
Lately we experienced some problems with P2P links where the target in one
peer is not responding anymore to changes on the source in the other peer.
(CP270 on 8.4.2)
ie
Source CP6001: VACUUM_R:R1_V_062PVO.OUT ---> target CP6003 VACUUM:
LOCK_VACP2.RI0001 (value did not change)
and
CP6001:R04:P_MODULE_NEW.BO0005 --> CP6003 VACUUM:VACUUM_ASK.BI04 ( BI04
remained true, when it was actually false in the source)
We tried everything to get these links "unlocked" except an initialize all
(delete & undelete + checkpointing, deleting both blocks and rebuilding
them + checkpointing , reading the source tag in other block in
CP6003....) nothing worked
Because i couldn't do an initialize all, which solves the problem
according to Invensys, I changed the seq to use another Boolean out
(BO0011 in stead of BO0005) and used the MEAS in stead of OUT for the Aout
We'll probably do an initialize all in the next shutdown
My question to the list is following:
Does anyone have some sort of script we can run to detect similar "locked"
P2P links? I've been checking with Rsom, but this is very tedious
(checking line per line manually of every list refering to the CP for
errors). dbvu did not reveal any errors.
Now we were taken by surprise, there's nothing in the I/A system that
checks these things and offers alarming possibilities.... our interlock
valve handling was compromised because the data it used was not updated. I
would like to prevent his in future.
Thanks & rgds,
Dirk
_______________________________________________________________________
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
NOTICE - This message and any attached files may contain information that is
confidential, legally privileged or proprietary. It is intended only for use by
the intended recipient. If you are not the intended recipient or the person
responsible for delivering the message to the intended recipient, be advised
that you have received this message in error. Any dissemination, copying, use
or re-transmission of this message or attachment, or the disclosure of any
information therein, is strictly forbidden. BlueScope Steel Limited does not
represent or guarantee that this message or attachment is free of errors, virus
or interference.
If you have received this message in error please notify the sender immediately
and delete the message. Any views expressed in this email are not necessarily
the views of BlueScope Steel Limited.
_______________________________________________________________________
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: