David, Did you manage to resolve this issue? I am having similar issues with an installation which has hung 3 times since implemented in September. The system is lightly loaded <30 tags. I'm talking to two controllogix PLC's. Here's the rub. The points don't go cyan, but they stop updating so everything looks OK from an operator's and System Monitor's point of view. I will implement a watchdog alarm to let the operator know it's time reset the FBM233 from system management to re-start communications. mk David Johnson wrote: > 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: //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