Re: [foxboro] P2P links locked
- From: Michael Kessler <mkessler@xxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Tue, 07 Sep 2010 11:11:47 -0400
The last time I saw this issue was on a CP that had previously had a low
memory excursion. The memory recovered but a few points stopped updating
(I'm not sure exactly when they stopped working so can't be sure it was
due to low memory).
I suspect the low memory condition may have caused a corruption in some
of the lists.
Fortunately I had the opportunity to re-boot the CP which cleaned up
the issue.
mk
dirk.pauwels@xxxxxxxxxx wrote:
> 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
>
>
>
>
_______________________________________________________________________
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:
