Re: [foxboro] FBM214 incorrect input readings

Corey,
        First off, sorry about your interrupted vacation plans.  Based
on all past experiences with CAR's, you won't be able to find out if
there is a CAR filed by other users that match the problem you are
seeing until there is actually a Quick Fix issued to address the
problem.  You can file your own CAR so you can check on the
status/progress being made.  I don't remember a CSC customer
notification ever coming out saying that there is a problem with
software or equipment unless Foxboro has already issued a fix or
correction for the problem.
        At this point, every FBM214 user could be experiencing the
problem and could have submitted a CAR but there isn't a way for you to
know it unless other users tell you on this list.  I understand that
Foxboro doesn't want to publicize to the world all of the
hardware/software issues they may be working to fix, but it is our
contention that they have a list of all the companies they have sold
FBM214's to, and they should be able to contact each of them to make
them aware of the situation, which sounds quite serious.  We are just
getting ready to make a move toward HART FBM's and this problem
definitely tempers my enthusiasm.
        Is the offset always high?  Does the raw count, (Digital), value
in IA match the analog MiliAmp current running through the loop or is
the A to D, (Analog to Digital), conversion being incorrectly done in
the FBM?  I am interested in hearing from you how this finally gets
resolved, i.e. EEPROM update, software patch, hardware replacement,
etc...  It also sound like you may never have recognized the problem if
you didn't have redundant level transmitters.  Keep us informed because
we will only hear from Foxboro if they solve the problem.
Cheers,
Tom VandeWater

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of Corey R Clingo
Sent: Monday, December 19, 2005 3:53 PM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] FBM214 incorrect input readings

Hi list,

Forgive me if this sounds like a rant, but I'm supposed to be on
vacation,=20
and I find out today that I potentially have 1/4 of the plant's analog=20
inputs reading erroneously...


We were troubleshooting a problem with redundant level transmitters
today=20
where one was reading about 20% higher than the other.  Both the inputs=20
are on separate FBM214s, the points are in current mode (PV=3DCURRENT,=20
DVOPTS on the ECB=3DNOFAIL).  I called TAC and they responded that there
had=20
been some reports of this behavior, that two CARs have been filed (more
on=20
that later), that the problem is hardware- and software-related, that
they=20
have been working on a fix for 3-4 weeks and that "they hoped" it would
be=20
out in another 1-2 weeks.  They informed me that in the the instances=20
reported, they think the problem was initiated by either a mix=20
non-FBM-powered input, or an input driving very high (close to 30 mA).
I=20
don't believe either happened in my case; I can vouch for the fact that=20
all inputs are FBM-powered, but as for the driving high part, all I have

to go on are the transmitter specs.


Anyway, they tell me that in the cases reported, the result was that
*all*=20
the channels on the FBM exhibited some kind of offset, though not the
same=20
on each channel.  The only known workaround at this time is to reboot
the=20
FBM.  And now, to get an idea of the scope of the problem here, I have
to=20
get into IFDC or build a block that reads the HART PV, and compare that=20
value with the current.  Just exactly what I had in mind for my
vacation.


So I have a couple questions:


1) Has anyone else seen this, and if so, what have you done about it?


2) Why, oh why, am I having to find this out for myself?  The CAR
numbers=20
the TAC guy referenced aren't even in the database.  And what level of=20
system malfunction does it take for Invensys to give its customers a=20
heads-up?  I ask this in all seriousness, as I have asked our local reps

before and have not gotten an answer.  In my opinion, an undetectable
bias=20
error in all channels on an input card meets the "hmm, err, umm, I guess

we better tell them" criterion.


Off to file another CAR,
Corey Clingo
BASF Corp.


P.S. Merry Christmas and Happy Holidays.

=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: