Re: [foxboro] Node Troubles????

Hi guys!

I don't see any sign of CP's rebooting and all INITMA's look good to me
on the Blocks I've seen go to manual (which are random).  I do monitor
Sysmon messages in a log file and nothing was happening around the time
this last block went into manual (Sat Night).  I also checked back on
the other instances 3 weeks ago and 2 months ago and nothing was
happening in Sysmgm to indicate reboots or any other suspicious
behavior.
I have done the connecting the .MA parameter to itself on really
important blocks in the passed.  But it doesn't explain why this keeps
happening.  One thing I will say though is that the Stations this
happens on are not only in the Extended Nodebus Section.  One is a FT
CP40B and the other is an AB Int30A in the Extended Node but I've seen
the same happen on a CP40A FT in the local NODE Extension.  =20
I don't have Operator Action Journal but I think I may implement it.
I have no Sequence Blocks and MBADOP is not used to trip any blocks to
manual.  I've checked System Definition and it has been set up to tell
these other stations that they are in an extended part of the Node (IE
Ext NB1).

The Extenders themselves are Copper Style not FONBE's.  I'm not sure of
the part number on them as I'd have to pull the module out to see it.  I
could take one side of the Node down and do this I suppose.  Any other
ideas would be appreciated.


Dale



-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of tjvandew@xxxxxxxxx
Sent: Tuesday, November 13, 2007 2:23 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Node Troubles????

Dale,
    I'm with Kevin in thinking that your CP's are rebooting and the=20
blocks that are going into manual are ones with the .INITMA parameter=20
set to zero, (AKA initialize in manual).  Nodes with nodebus extenders=20
are fickle beasts and from my experience are prone to network=20
communication problems that can make life miserable and cause FT=20
stations to go non-FT and even reboot both.  We replaced all of our=20
nodebus extenders, NBE's and Fonbe"s, with NCNI's or moved CP's into non

extended racks and that took care of our problems.  If you can find a=20
way to eliminate extensions entirely that is best.  Put all of your CP's

in the same rack/racks and run remote fieldbus communication which is=20
1000 times more reliable than extending the nodebus.=20
    Also, if your CP's really are rebooting and initializing all of your

blocks you can set INITMA to 1 which will cause them to re-initialize in

Auto or set to 2 to initialize in the same state they were in at the=20
last checkpoint.  Then you need to schedule regular checkpoints using=20
cpoint or a like utility through a cron job.  I don't think INITMA is=20
connectible but if you want to lock your blocks into Auto, (we did for=20
all of our I/O blocks), you can do the loopback that Kevin suggest by=20
connecting the MA parameter to itself  MA =3D C:B.MA.1
    Let us know what you find out.  If your CP's are rebooting but you=20
don't have SYSMON messages historized I think they would still have an=20
asterisk and be flashing white in system monitor until you acknowledge
them.
Cheers,
Tom VandeWater
Control Conversions Inc.
Retired from Dow Corning in Carrollton, KY
Currently in Kapolei, HI working for Tesoro

P.S. Haven't had time to look up, much less contribute to the list since

I took this job early in Oct ;<)


Kevin Fitzgerrell wrote:
> Hi Dale,
>
> I don't have a solid answer, but some things you may want to consider.
> 1) Can you tell when this occurs or is this normally discovered well
> after the fact?
> 2) Do you have operator action journal configured on all your
> workstations so you can check if these blocks were placed in manual?
> If not, this is fairly straightforward to enable.
> 3) When these blocks go to manual are they spread across control
> stations on both segments or are they limited to the stations on one
> segment?
> 4) Is there any possibility that this is the result of a control
> station reboot or reboots of control stations in a cellbus?
> 5) Do you log system monitor messages on your system monitor AW(s) -
> (by creating the file /opt/fox/sysmgm/sysmon/smon_log)?  Or can you
> check system monitor messages for the affected control station(s) in
> Legacy historian or AIM* messages?
> 6) Have you checked for block configurations that may be taking these
> blocks to manual?  INITMA, MBADOP, etc...  Or sequence blocks that may
> write to your MA parameter.
> 7) Especially for the input blocks where manual should be a very
> unusual condition, consider "locking" them in auto - you can connect
> the MA parameter to itself and set a default value - this should
> prevent it from ever being "accidently" switched to manual. - MA =3D
> C:B.MA.1
> 8) What kind of extenders are you using?  Are they FONBEs?
>
> Good luck with this problem,
>
> Regards,
>
> Kevin FitzGerrell
>
> On 11/13/07, Gillis, Dale <Dale.Gillis@xxxxxxxxxxxxx> wrote:
>  =20
>> Hi List
>>
>>
>>
>>
>> I have a problem that has plagued us over the passed several years on
>> one of our Nodes.  We have 3 Nodes and none are connected except Via
2nd
>> Ethernet Port and they are in a wide spread area of the plant.  All
AW's
>> are D Boxes and the WP's are B and D Boxes Combined.  Two of the
nodes
>> never show this symptom I'm about to explain and the only difference
>> between the one that has the problem and the other two is that it has
an
>> Extended Nodebus (About 400ft).  All are running at Version 6.5.2.
>>
>>
>>
>> Problem is that on this extended Nodebus NODE we randomly (May go for
>> months with no symptoms) get various blocks (AIN, CALC, MATH, MCIN,
>> MCOUT's) all on different stations that go to MANUAL for no apparent
>> reason.  The Extended Node is Copper with NBE's.  There is 3
redundant
>> CP40A's, 1 Redundant CP40B and 1 redundant CP60.  4 WP's are B Boxes
and
>> 5 are D Boxes all with DNBI and DNBT Connections.  Also there are 2
AB30
>> Stations, and 6 INT30B Stations and 2 INT30A Stations.  Most of these
>> Blocks are types we don't want Operations to be able to switch.  I've
>> repeatedly gone through protection classes and did dumps of the
graphics
>> and I see no where that allows an operator to do this.   Has anyone
with
>> a similar setup seen this on there NODES?  It is a very random thing
and
>> do you think it could be noise on the Ext Node????etc  Any ideas
would
>> be appreciated.
>>
>>
>>
>> Thanks in advance!
>>
>>
>>
>> Dale Gillis
>>
>> Instrument Technician
>>
>> 120 Pulpmill Road
>>
>> Port Hawkesbury
>>
>> Nova Scotia
>>
>> Canada
>>
>> PO Box 9500
>>
>> B9A1A1
>>
>>
>>
>> dale.gillis@xxxxxxxxxxxxx
>>
>> Phn Dir:902-625-6233
>>
>> Pager:902-625-2460 Ext 8
>>
>>      Pager 317
>>
>>
>>
>>
>>
>>
>>
>>
>>
_______________________________________________________________________
>> 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:
http://www.freelists.org/list/foxboro
>> to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
>> to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>>
>>
>>    =20
> =20
> =20
>
_______________________________________________________________________
> 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
> =20
> foxboro mailing list:
http://www.freelists.org/list/foxboro
> to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>
>  =20


=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: