Dirk, I used to refer to this as the connection going to sleep as everything seemed OK. Observant Operators were the only method I knew to detect this happening and fortunately it did not happen often. Sorry, this is not much help to you. When it was an AIN block .PNT that stopped changing values in a SINK CALC block, we used to be able to work around it by making another connection in the SINK block to the .MA parameter of the SOURCE block and then exiting which forced a CHECKPOINT and a remake of the peer connection. Seemed to wake up the .PNT and we saw changes in the SINK block again. Terry > To: foxboro@xxxxxxxxxxxxx > Subject: [foxboro] P2P links locked > From: dirk.pauwels@xxxxxxxxxx > Date: Mon, 6 Sep 2010 13:37:45 +0200 > > 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