Re: [foxboro] P2P links locked
- From: sander@xxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 6 Sep 2010 15:06:56 +0200
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
Other related posts:
