Large Contrologix Network Configuration

We are currently in the design phase of a fairly large project involving Controlnet, Ethernet and Devicenet. This projcet will have 4 Contrologix PACs in one central rack. There are 4 large Devicenet MCCs , each so large that there are 3 Devicenet segements in each MCC. The MCCs are where I am getting stuck. I have used various scenerious using Integrated Architecture Builder, and hit road blocks such as exceeded bandwidth , connections and rack power supply capacity.

Due to the nature of this project i will have to message to the PAC that is controlling the MCCs via devicenet using produced consumed tags there are about 150 motors, mainly PF70s. Would I be better off using Ethernet or Controlnet?. My gut tells me to use Controlnet as I am still do not have the warm and fuzzy regarding ethernet controlling a pump in a remote PAC , where that pump is filling a tank with $10/gallon product.

Look into a:

1788-CN2DN linking device. Works great when connecting to MCCs controlled by DN.
Cat. No. Product Description 1788-CN2DN ControlNet-to-DeviceNet Linking Device Link a ControlNet network to a DeviceNet network
Cat. No. Product Description 1788-CN2DN ControlNet-to-DeviceNet Linking Device Link a ControlNet network to a DeviceNet network

jkerekes said:

Look into a: 1788-CN2DN linking device.......

Click to expand...

There is also a 1788-EN2DN that is used for Ethernet/IP. Same function, different network.

I know the 1788-EN2DN and -CN2DN products extremely well, and they both have their place. They are both especially good in MCC applications because they're relatively small, relatively inexpensive, and easy to locate close to the DeviceNet segments to which you plan to connect. One 1788-xN2DN per DeviceNet segment (for a total of 12 in the MCCs) should do the job admirably. If you are running out of connections, network bandwidth or processing bandwidth, consider 1756-CN2/B modules as the ControlNet bridges, or increasing the number of ControlNet segments and bridges at the main controller.

Of course, that might be entering right into the problem; you said there are 4 ControlLogix CPUs already in a central chassis, and I think I understand that you might be running out of power supply capacity with all the network cards they require.

I have built some systems recently where we used 1788-CNBR/E modules in a 4-slot chassis with 1756-DNB/C scanners instead of 1788-CN2DN or -EN2DN bridges. This was more expensive and took up more space, but I did it because the application is a plant that intends to add more DeviceNet nodes to the MCC as it grows, and it requires the Online Scanlist Changes At Runtime "OSCAR" feature that the 1756-DNB supports while the 1788-CN2DN and -EN2DN do not.

curlyandshemp said:

My gut tells me to use Controlnet as I am still do not have the warm and fuzzy regarding ethernet controlling a pump in a remote PAC , where that pump is filling a tank with $10/gallon product.

Click to expand...

I understand your concern, but I wouldn't worry too much. I have that very setup pumping product that costs far more than $10/gallon. Never had a problem...knock on wood.

curlyandshemp said:

...This projcet will have 4 Contrologix PACs in one central rack... Due to the nature of this project i will have to message to the PAC that is controlling the MCCs via devicenet using produced consumed tags there are about 150 motors, mainly PF70s. Would I be better off using Ethernet or Controlnet?...

Click to expand...

If the controllers are in the same chassis - use the backplane.

Personally I am not a fan of putting that many processors in one chassis, but thats not the question. For an EtherNet solution I would put a 4 slot chassis in the MCC. One slot would have an EN2T in slot 0 and the other 3 slots would have DNB's, one for each DeviceNet MCC segment in that MCC lineup. I am not a fan of the 1788-EN2DN, the setup is a little funky. Fine enough for data collection, but I wouldn't use it for control.
For a ControlNet solution, I would use a 1788-CN2DN for each DevicenNet segment. The problem with a DNB in a remote chassis connected with ControlNet is that if the input and output words are left at default, it takes up the whole capacity of the CNB. Easy enough to remedy, if you only have one DNB in a remote chassis but having 3 of them in one remote chassis may be a little harder to remedy, if at all possible.