Re: [foxboro] Node Troubles????

Dale,
    I'm with Kevin in thinking that your CP's are rebooting and the 
blocks that are going into manual are ones with the .INITMA parameter 
set to zero, (AKA initialize in manual).  Nodes with nodebus extenders 
are fickle beasts and from my experience are prone to network 
communication problems that can make life miserable and cause FT 
stations to go non-FT and even reboot both.  We replaced all of our 
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 
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 
1000 times more reliable than extending the nodebus. 
    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 
last checkpoint.  Then you need to schedule regular checkpoints using 
cpoint or a like utility through a cron job.  I don't think INITMA is 
connectible but if you want to lock your blocks into Auto, (we did for 
all of our I/O blocks), you can do the loopback that Kevin suggest by 
connecting the MA parameter to itself  MA = C:B.MA.1
    Let us know what you find out.  If your CP's are rebooting but you 
don't have SYSMON messages historized I think they would still have an 
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 =
> 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:
>   
>> 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=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:             http://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:             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: