Hi Sander, Once you know the link is bad, there are probably several ways of fixing it, the problem is how to detect a bad link, before the programming which uses the link, fails or executes incorrectly because of the incorrect input. Perhaps there is a way of running an rsom and capturing the error messages at regular intervals, thus generating an alarm when errors are reported, which would draw the operator or engineer's attention. (just thinking aloud) I know in the perfect Invensys world one would not have P2P links, but in real life it's almost unavoidable, so why is there so little (none except for the dbvu, which doesn't even report errors of this kind) alarming on this P2P stuff We know of 2 bad links, maybe there are more,...... Rgds, Dirk sander@xxxxxxxxxxx Sent by: foxboro-bounce@xxxxxxxxxxxxx 06/09/2010 15:07 Please respond to foxboro@xxxxxxxxxxxxx To foxboro@xxxxxxxxxxxxx cc Subject Re: [foxboro] P2P links locked Dirk, We've had the same issue some time ago. Connections between different CPs. Also fixed it relaying the connection to a different parameter, checkpointing en switching the connection to the original parameter. With us it did seem to happen only the connections with a CALC as the source. Regards, Sander > Dirk, > did the point show bad, deleted or out of service in the station block? > I run a script every day that checkpoints all control stations and then > uses > dbvu on the checkpoint files to find bad p2p links. It emails me the > results. > Kevin > > On Mon, Sep 6, 2010 at 8:37 PM, <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 > > _______________________________________________________________________ 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