Re: [foxboro] FBM 233 to Controllogix question

David,
I believed I have observed the issue you are having when we 
first brought our 233s online. If you haven't already done 
so, investigate adding the @ and TO settings to the DVOPTS 
parameter of the ECB201 block representing the target PLC. 
The value entered after @ will influence the scan time. The 
TO value will influence the timeout value. I would also 
recommend you create diagnostic compound containing the 
following;

1) Main FBM load:       Block = RIN
                                DEV_ID = Target FBM ECB
                                PNT_NO = $FBMM_CPU_USAGE
2) Bkup FBM Load:       Block = RIN
                                DEV_ID = Target FBM ECB
                                PNT_NO - $ FBMB_CPU_USAGE
3) Main FBM Memory:     Block = RIN
                                DEV_ID = Target FBM ECB
                                PNT_NO = $FBMM_MEM_LOAD
4) Bkup FBM Memory:     Block = RIN
                                DEV_ID = Target FBM ECB
                                PNT_NO = $FBMB_MEM_LOAD
5) Main Messages Sent:  Block = IIN
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $M_MSGS_SENT
6) Main Msg Received:   Block = IIN
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $M_MSGS_SENT
7) Bkup Messages Sent:  Block = IIN
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $B_MSGS_SENT
8) Bkup Msg Received:   Block = IIN
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $B_MSGS_SENT
9) Main Timeouts                Block = IIN
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $M_RSP_TIMEOUTS
10) Main Timeouts               Block = IIN
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $M_RSP_TIMEOUTS
11) Counter Reset               Block = BOUT
                                DEV_ID = Target PLC's ECB
                                PNT_NO = $RESET_CNTRS

Add the counters to your historian. This will allow to 
observe the FBM/PLC data activity. Through observation, 
I increased our scan time and timeout values. 
As Mr. Doucet has mentioned, it is always a good 
practice to compact the data as much as possible. If a 
substantial amount of the data is at a bit level, 
consider using BOOL arrays in the PLC program to be 
scanned by PAKIN blocks or written to by PAKOUTs.
Anyways....just some thoughts.

___________________________________
James J. H. Dykes
Tesoro Petroleum
Golden Eagle Refinery
Technical Services
Process Controls
150 Solano Way
Martinez Calif.
94553-1487

Phone:925.228.1220 Ext. 2930
E-mail:jdykes@xxxxxxxxxxx 

 


-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of David Johnson
Sent: Tuesday, August 12, 2008 7:49 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] FBM 233 to Controllogix question

Hi all,

I am working with a customer running a fault tolerant connection
(FBM233) to fault tolerant controllogix processors using Foxboro's
ethernet IP driver.  We started with an older version of the driver, but
quickly had field service upgrade everything to the latest back in
March.  Everything will work for several (many) weeks and then all of
the blocks being passed to and from the gateway will smurf at the same
time.  We are having to re-boot the CP to clear this condition (it might
be enough to re-download the fbms and go off line and back on-line, but
they haven't tried that when the crisis occurs).  We are not adding or
deleting any blocks in the configuration, and to the best of my
knowledge the primary and secondary controllogix modules are not
swapping, neither are the primary and tracker FBMs swapping (again, as
far as I can tell.)  In other words it appears to work until it quits.
When it is working none of the points appear to be smurfed and
everything going to/from the PLC looks like a valid controller tag.  The
time interval between failures is not constant, but they have seen this
occur 3 times in the last 5 months.

The data load is reasonably light, only 262 controller tags.  The ecb
201 has the timeout set at 5 seconds, which should be plenty of time if
there is a network problem that corrects itself.

So I was wondering if anyone else has seen this or knows of issues that
might cause this performance issue on the FBM233 with EthernetIP.

Thanks,
David


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