1756-ENBT/A in second chassis linked via ControlNet

Hey guys, I'm not super familiar with Cnet, so I'd like some insight from people with more ControlNet experience than I.

We have a controllogix L55 controller in the field overseeing two 13 slot racks. The first rack houses the previously mentioned processor, a 1756-CNB, a 1756-ENBT/A, and the rest are hard I/O. The second chassis has a 1756-CNB, a 1756-ENBT/A, and the rest of that one is hard I/O as well.


Here is the problem, we are using the ENBT's to pass data to and from our DCS. The first chassis's ENBT works fine, the second does not seem to work, and I don't believe it has ever worked.

As it stands, the DCS grabs values from controller level tags, which effectively means that when we go through the second ENBT, we then need to go through the CNB, over the ControlNet network, to the other CNB, then to the processor and back.

I'm only speculating here, but my guess is that the amount and speed of data acquisition is too high to function over the ControlNet network, or that possibly this type of data acquisition is not even possible. Can anyone confirm or deny this?

What sort of DCS system are you using ? How fast is it requesting data, and how much at a time ?

It is more likely that the DCS doesn't support CIP routing properly, or the CIP route isn't properly configured.

I have a bunch of machines from 10 years ago running with ControlLogix Redundancy and exactly this setup, where our MES system and our remote Logix 5000 access go through a CIP route:

MES Server -> IP Address/ENBT -> backplane -> CNB -> ControlNet -> CNB -> Backplane -> 1756-L62

What you definitely cannot do is run I/O connections or Produced/Consumed Tags across that "remote" ENBT: an I/O root bridge must be in the same chassis as the CPU.

Foxboro DCS, using FBM 233's. No produced/consumed tags. The FBM 233's are redundant, so they share the same programming. The only difference is the IP of each FBM, and the IP of each ENBT they communicate with. One FBM-ENBT pair works, the other does not. The only real difference aside from that is the location of each ENBT on the two chassis'.

The FBM's are set up to scan once per second. There are roughly 200 points being polled.

200 tags once a second is no problem.

I don't know enough about that DCS to know where the CIP path is configured for the FBMs, or if it can be different between redundant devices.

An FBM configured to talk to the CPU in Slot 0 via the ENBT in the same chassis would have a CIP Path similar to:


An FBM configured to talk to the CPU in Slot 0 via the ENBT in that ControlNet-linked chassis would have a CIP path similar to:


In a CIP protocol routing Path, the 1's represent a hop to a ControlLogix backplane, and the 2 represents a hop to the network port of the ControlNet card.

If both of the FBM's are literally configured identically, then it makes sense that the one connected to the remote chassis doesn't get tags from the CPU: it's trying to read them out of whatever's in Slot 0 of the remote chassis.

Ok, well that basically answers my question. I appreciate the help!

As far as I am aware, the FBM's drivers are already set up to accommodate the CIP protocol, and essentially only need the IP and slot# of the CPU. So their "accommodation" must only be for CPU's and ENBT's that reside in the same chassis.

Thank you so much for the quick replies and info.

I'll update if I find a way around this for anyone's future reference.