Re: [foxboro] P2P links locked
- From: sander@xxxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Tue, 7 Sep 2010 14:32:43 +0200
All,
Below is the rsom-output of the occurence of this issue with our 8.4.2
system.
======================================================================
SINK PATH: BLOK2:UNIT_OVZ3.II0001 (C0D2E5)
SOURCE PATH: 034_0026_SQ:UNIT_STAT.LO01 (C0D2E3)
rsom on SINK-CP:
ID # Next Hdr Adr Status Lbug Opt? PID # Size Xdata FScan
05 0072:D3BC Local C0D2E5 N 00060 101 N N
OM OPEN POINTS DATABASE OPEN VAR INFORMATION 0073638C ID #005
001 034_0026_SQ:UNIT_STAT.LO01 N 016 001 3F800000 0073:6F94
Scanning 0226 R N -01 01 0000000001 02F9 0216
Time Stamp: Not Available
rsom on SOURCE-CP:
ID # Next Hdr Adr Status Lbug Opt? PID # Size Xdata FScan
07 0076:1514 Remote C0D2E5 N 00060 059 N N
19 0076:A100 Remote C0D2E5 N 00060 001 N N
OM OPEN POINTS DATABASE OPEN VAR INFORMATION 00746320 ID #007
OM OPEN POINTS DATABASE OPEN VAR INFORMATION 00746320 ID #019
======================================================================
Point is not shown any of the export-list on the source-CP!
So by extracting the output of rsom, it can be detected.
If anyone is intrested in the script to extract data from rsom, let me know.
Regards,
Sander
> 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
>
>
_______________________________________________________________________
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:
