Another ENBT dies...

Hi folks

Just has my second ENBT die on me with no outward indication. It worked again merely by pulling it out of the rack and putting it back in. (does it run on windows ??? )

Is this a common failure mode with these that I am just beginning to see the start of?

Please list the exact catalog number and series, plus the firmware revision that it is running on.


Also, when you say "dies", do you mean that it just stops communicating? What does the front scrolling display look like? What do the indicator lights look like?

1756-ENBT FW 6.006

All lights are fine and display says OK and scrolls the IP just like normal. Controller indicated nothing.

A couple machines appeared to be talking to it fine (because their comm alarms didn't set off till later) but most including my desktop could not. Plugging in locally also couldn't connect to, or ping it.

Had this happen a couple months ago to another PLC with identical symptoms and same resolution. I replaced it but found that when I plugged it into one of my test racks it came back to life.

These were both new in 2009 so maybe there is a built in time bomb that does this so we buy new parts.... Only half kidding.

Have you seen KB586614?


They suggest that you will probably see a lot of FSC/Alignment errors accumulating on a system that locks up like this. You should check to see if you are getting those errors accumulating, the only acceptable value is 0.


The only other concrete thing they offer is making sure that you are on FW6.006, which obviously you are.

FSC errors increment very slowly. KB hints that I should look at the network settings, as with everything networky always blame something else first.

The module I replaced months ago has zero FCS errors and its network facing hardware has not changed, so perhaps that is indeed a good indicator of a failing module.

TheWaterboy said:

FSC errors increment very slowly. KB hints that I should look at the network settings, as with everything networky always blame something else first.

Click to expand...

I understand where you are coming from, however I'd argue that this may not be a blame game, there may actually be something mis-configured. In our environment, every single packet is important.

To diagnose, we'd need to know the devices connected to the ENBT, how they are connected (switches, switch settings) and how all of the device baud rates are configured.

edit: If you have a new module and the FSC errors completely went away, maybe you did have a problem module. However, I'll start looking over the other tabs to check for other problems. Application/bridged connections, look for missed/rejected packets.

If the communications resources get used up (too many "Connected" or "Cached" connections, too many MSG instructions not completing or running concurrently) can cause exactly what you describe. Even too many "Stupid" HMI devices that each want to create connections (another reason to love Ignition), or other 'Smart' Ethernet IP based devices (Laser Scanners, cameras, etc) can use up connections. When the connections are just about gone, communications slows to a crawl.

I do know about the connection limits, duplex etc, but in these 2 cases nothing is wrong with the network around it, and nothing in the config changed. One day the thing just stops working but gives no outward appearance of failure. Changing ONLY the module corrects the problem. Cycling power to the module corrects it at least temporarily.

So FCS numbers appear for the moment to be the first indicator of a failing module. Just as it can indicate when other devices around it are failing, the module can also be the source of the problem and so with that number it kinda predicts it's own demise.

I'll have to start look at the more to see how that works out.

Thinking back too many years ago i had a similar problem with a modem card on a PLC2/30 with 5 racks.

Turned out the rack backplane was moldy, not any problem with multiple modems.

Might be a problem with the rack.

I have seen this sort of thing happen when any one or more I/O modules has an RPI that is way too small, it effectively causes bottlenecks on the Backplane.

Worth remembering that the poor old Backplane, or to give it its proper name "ControlBus", only runs at 5MB/sec., that's only 1/20th the bandwidth of the Ethernet module.

I guess the same could happen if there are too many Messages happening too quickly. I always use timers to trigger messages anyway, never let them re-trigger themselves.

Have any new devices been added to the system recently ?

Has the network infrastructure been "worked on" ?

I very much doubt you have had two ENBT modules fail, but stranger things have happened.

Yes, as already mentioned, the contacts on the module to backplane connectors could be dirty, you could try a cleaning spray on them and push the module in and out several times. Had this happen on a CNB module recently that had been in continuous operation for over 13 years. To be honest though, this would probably throw up a module fault of some sort, rather than appearing to be OK, but not working as it should.

I use timers on my MSG as well, once per second at the most and often 5 seconds or event based.
No new devices
Nothing worked on
These are in clean environments with no vibration.
RPI's are either 20 or 100ms for the 8 IO modules

I am now watching the FCS Counter with a MSG and it is not incrementing at all.

You last comment is what concerns me, there was no outward indication.

I'm going to dig out the task manager for the logix platform and see if that reveals anything.