Re: [foxboro] FCP270-FBM100
- From: dirk.pauwels@xxxxxxxxxx
- To: foxboro@xxxxxxxxxxxxx
- Date: Wed, 29 Sep 2010 16:01:42 +0200
Hi Tom,
Strange thing is we don't get sys errors for most of these cards in the
sysmon when the state alarms occur, recently we do get sysmon errors for 2
of the cards, but never on the same timestamp then the alarms.
I might try to disable bus switching like you did tomorrow, at the rate
the alarms are occuring now I should soon see if it's related to the bus
comm errors.
thanks for the help & Rgds,
Dirk
tjvandew@xxxxxxxxx
Sent by: foxboro-bounce@xxxxxxxxxxxxx
29/09/2010 14:50
Please respond to
foxboro@xxxxxxxxxxxxx
To
foxboro@xxxxxxxxxxxxx
cc
Subject
Re: [foxboro] FCP270-FBM100
Dirk, we had some funky problems with temporary communication errors on
FBM-41's running ladder logic, even on CP-60's. This may or may not be
related. The errors were captured by System Monitor and caused the
fieldbus to switch from A to B and back again. This communication problem
could be associated with what you are seeing because the ladder logic
executes in the memory of the FBM and then all values get communicated to
the CP across the fieldbus. If there are fieldbus communication errors
that cause a delay in fieldbus COMM's the PLB interface block running in
the CP may not be getting status updates from CIN or OFL's as they are
happening in the ladder. To insure this isn't your problem be sure that
you are capturing ALL of your system monitor errors and then check to see
if you get any intermittent fieldbus errors from the offending FBM41 at
the same time as the plb error.
FYI, we forced our fieldbus to communicate only on A bus and the
intermittent errors quit coming into system monitor. We theorized that an
error caused the bus to switch if bus switching was enabled and would stay
on the same bus and retry if bus switching was disabled. A CAR was
entered but never resolved to our satisfaction. When I was in Hawaii I
saw the same error occur on the Bailey migration IO that contained 100
series components. The error can happen on other 100 series FBM's with
FBM04's Beng the 2nd biggest offender but discrete FBM's runnng ladder
logic were far and away the most frequent. To me it appeared to be a
fieldbus communication timeout issue where the FBM's ran out of time to
fnish communication in the time allotted and that caused the error.
Regards,
Tom Vandewater
Control Conversions, Inc.
Sent from my Verizon Wireless BlackBerry
-----Original Message-----
From: dirk.pauwels@xxxxxxxxxx
Sender: foxboro-bounce@xxxxxxxxxxxxx
Date: Wed, 29 Sep 2010 12:11:00
To: <foxboro@xxxxxxxxxxxxx>
Reply-To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] FCP270-FBM100
Hi List,
We've had following problem ever since we changed from CP60 to FCP270,
I've posted it earlier, but never found a sollution for it. Seemed we were
the only site to suffer from it. Maybe in the meantime someone else has
experienced this behaviour. So I'm posting it again:
Mesh 8.4.2, ZCP270's, mix from FBM100 and FBM200.
The problem we're having is limited to FBM100 only (FBM41/42), and for the
moment we have it on 2 CP's, the other CP's seem to be fine
ZCP270 -> FCM100 -> FBI twinax -> FBM100's
Each FBM41/42 is used with GDEV and PLB - looking more or less like this:
-| |--------------------|\|----------------------------------------------(
)
ifl open/close ifl HLD CO open/close
output to vlve
-| |---------------------------------------------------------------------(
)
cin feedback from vlve open OFL
-| |---------------------------------------------------------------------(
)
cin feedback from vlve closed OFL
The ofl is tied to the devlm1/2 of the GDEV.
What happens on +/- 25 FBM41/42 cards, (most cards are OK) is that the cin
feedback from the vlve fails for a short time (1-2 secs), which causes the
valve to goto into state alarm, which might trigger some interlocks. (if a
certain valve position is expected for some action)
At first we thought this failing of the feedback had to do with
power/wiring etc, but we couldn't find anything wrong.
these are the steps we took on one of the problem cards trying to solve
this problem:
1. We installed a bridge on the feedback, to determine if it was power or
software related, and even then the cin-ofl failed.......So nothing
power/wiring related
2. We then changed the card, still same problem
3. we changed the nose cone, still same problem
4. I put some delay (on/off) 5-10sec in the PLB , to prevent the ofl
failing when the cin failed. cin fails for 1 sec so a delay of 5-10sec
would certainly solve it. Turns out the OFL still fails????? which
probably means it's not actually the cin that fails but the cin-ofl fail
together despite the delay......Don't understand this.....
5. I set the FBM ECB to 5 sec's, as wel as the PLB block and the GDEV
block, to slow down processing, hoping this would prevent DCS from seeing
the cin fail. Errors seemed to decrease at first, but no final solution
6. Invensys adviced to swap the 41 cards for a more recent type, still
same problem
7. We updated the FBM100's Eeprom, still same problem
8. We're now planning on moving one of the valves onto an FBM200 card,
with temp wiring from one cabinet to another (messy), this will probably
solve it.........
Since we do not have the means to change all of the FBM100's for 200's I'm
hoping there's another solution, but sofar we haven't been able to find
any....I ran out of inspiration....
Problem seems to be related to the use of ZCP270, FBM41 with PLB's. We
didn't have this kind of problem with the CP60's.
Suggestions anyone?
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
Other related posts:
