Re: [foxboro] Problems with Nodes that have Nodebus Extenders

Tom,

Be sure to check the grounding on your 1 X 8's, in particular, on your
nodebus cables that jump from 1X8 to 1X8.  Check ALL enclosures.

Just a thought.

Michael L. Jaudon
Kerr-McGee Chemical LLC
(662)343-8710
mjaudon@xxxxxxx


-----Original Message-----
From: tom.vandewater@xxxxxxxxxxxxxx
[mailto:tom.vandewater@xxxxxxxxxxxxxx]
Sent: Tuesday, April 30, 2002 2:30 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] Problems with Nodes that have Nodebus Extenders



Dear All,
        There is an intermittent problem on Fox IA dual nodebus systems on
nodes that have either Nodebus Extenders (NBEs) or Fiber Optic Nodebus
Extenders (FONBEs). It is very difficult to diagnose as there are many
different symptoms that indicate individual component failures or bus
failures. Our most troublesome problem was extremely slow graphic call-up on
WP-51's and intermittent cyan on the same screens, coupled with many
intermittent nodebus cable errors in SMDH. The problem seems to be most
prevalent on nodes that have AW/WP51B's and above, combined with CP-40A's
and above. It took us more than 6 months to get to the bottom of the
problem, and now we have been waiting for over a year for a reasonable fix
to the problem. We have had to scratch and dig for any progress update and
the best we have gotten so far is "we're working on it." It should be noted
that we have 22 nodes on a single carrierband at our site, 9 of which have
NBE's or FONBE's. Luckily most of them are still at CP-10/30 level and the
boot hosts are 51-series across the carrierband. This makes the problem much
less likely to occur.
        With no defined end in sight, I recently subscribed to this list in
order to raise awareness to technical problems that the user community is
experiencing. Past experiences with Foxboro have been that if you chase a
problem down to the root cause, they will finally admit to you that they
know the problem exists and have seen it at other sites, but they won't pass
that information around internally or to potential affected users until
Foxboro has designed a fix for the problem. In the mean time, many users,
Foxboro Sales reps, and Foxboro field maintenance techs are chasing their
tails trying to figure out what is going on.
        I didn't have to wait long before the problem with Nodebus Extenders
was mentioned. The note below, posted by Frits Shouten, had several
responses that indicated that other users have experienced similar problems
and have replaced a myriad of hardware trying to fix the problem. Some have
claimed success but I can tell you that the success is most likely
temporary. When I read Frit's note I immediately recognized the symptoms as
ones we had seen and sent a note asking him if the problem node included
NBE's or FONBE's. It was no surprise to me when his answer was YES!!
        We have had a serious problem since we upgraded a Node with
pre-existing nodebus extenders, from AP-20's, WP-30's, and CP-30's to
AW51D's, WP51D's, and CP-60's in Oct. 2000. I have been actively tracking
this problem since Feb 2001 and have compiled an informative but lengthy
document that I can send to anyone interested in either Adobe .pdf format or
Word .doc format. 
        This forum is excellent for just this type of problem discussions,
because these issues are not advertised by Foxboro, for obvious reasons, and
are often swept under the carpet at Fox IA user group meetings. But there
are many good Foxboro employees participating and they know that the users
on this list provide their bread and butter.
        If you are interested in receiving a copy of my notes on this issue,
you can contact me at:
tom.vandewater@xxxxxxxxxxxxxx or tom@xxxxxxxxxxxxxxx Please indicate .pdf or
.doc format preference.

Tom VandeWater 
Dow Corning Corp. 
Carrollton, KY 

----- Original Message ----- 
From: "Schouten, Frits JF" <Frits.Schouten@xxxxxxxxxxxx> 
To: "Foxboro DCS Mail List (E-mail)" <foxboro@xxxxxxxxxxxxx> 
Sent: Monday, April 29, 2002 4:44 PM 
Subject: [foxboro] DNBX problem

On Monday, April 29, 2002 4:44 PM Frits Shouten wrote:
Dear all, 
        For a long time now we have a problem with one of the WP's which is
connected to the nodebus via a DNBX.  Values on the graphics are
occasionally smurfed for a few seconds, updates on the graphics are slow,
changing graphics can be very slow, etc.  In SMDH the cable error for this
WP are alternating between all four options TA,TB,RA and RB.   I normally
have 'station cable A and B' inhibited and the operators have grown acustom
to the slow response and smurfed values. 
        Last software upgrade to 6.2.1, for some reason, un-inibited the
station cable faults and the operators were screaming their head off about
this system alarm.  I think it's time to do something about it.  What I'm
asking is, does anybody know a way of catching what goes on on the DNBX?  Is
it perhaps the comms (you know that second cable) to the DNBX that is having
difficulty and can I monitor that one.  I've been snooping le0 but what am I
looking for? 
Regards, 
Frits Schouten 
Process Computing Department 
New Zealand Steel 
Phone: +64 +9 375 8111 ext 5261 
Email: Frits.Schouten@xxxxxxxxxxxx 


It appears now that if we have a nodebus cable test error on a node but the
entire cable doesn't get marked as failed, that some of the modules on the
node switch to "B" nodebus and some stay on "A".  An example of this type of
error is shown below:
03-22-01 07:46:00      0  SYSMON = SYS16B  15AW01  Process = NFD000116

NF8023 -00022 01CI16 RxA Failed. NB Cable Test to 16CP12 OK
We were not able to determine if all modules on one NBE segment stayed on
"A" while modules on the other NBE segment switched to "B", but when it
occurred display stations such as WP's and AW's were using one bus, and
control stations, at least the CP-60's, were using the other.  The symptoms
were extremely slow display call-up times that sometimes timed out and
resulted in cyan values on the screens.  We think the cause of the slowdown
was because the workstation calling for the graphic data from the CP's sent
the request out on "A" nodebus and didn't get a response from the CP because
it was communicating on "B" nodebus and didn't hear the request.  After
getting a timeout on the request, the WP sent out the request on "B" nodebus
and got the data from the CP.  Unfortunately, the WP didn't switch to "B" so
that it would be talking on the same bus as the CP, and didn't remember that
the CP was talking on "B" the next time it needed data.  Although subsequent
nodebus cable tests could be run and passed successfully, the modules never
switched to the same bus until we intentionally caused a bus failure that
modules on both nodebus extended segments recognized!  We were able to make
it happen by physically lowering the elevators and pulling out the "A" NBE
modules on both segments and then running a cable test.  Once all modules on
the node recognized that "A" was failed, they all switched to communicate on
"B" and normal communication resumed.  There was a short period of time,
after we lowered the elevators but before we ran the cable test, where all
data from the CP's went cyan on the display screens!   

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________
 
 
_______________________________________________________________________
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: