On Logix5000 system, why there are two or more Ethernet cards on the same rack?

wendaiyu

Member
Join Date
Jun 2014
Location
toronto
Posts
87
Hi, folks, how’s going?

We just get one new production line with Logix5000 system. But I cannot understand why there are 4 Ethernet cards and 1 Controlnet card over PLC rack.

For my understanding, we can use 1 Ethernet card to connect to a hub, then connect to few modules with that hub. So why we need 4 Ethernet cards on the same rack?

Thanks for your help.

4 Ethernet cards.jpg
 
I had done a number of systems that had 2 Ethernet cards. The reason was for 1 card to handle all of the local IO and the other was dedicated to a connection to the plant network. If you have ever put Ethernet IO on a plant network without a managed switch up set up correctly, IT will very quickly be coming after you.

Using a managed switch can keep the broadcast traffic off an IT network, but they require sometimes a complicated setup. So now what happens when a maintenance person replaces that switch and doesn't know about configuring a managed switch. It is just safer to isolate the two networks with separate cards.

Now why the system in your picture has so many cards, I can only guess that maybe the RPI is set so fast that it maxes out the capacity of a single card.
 
First of all, you should use switches, not hubs, to connect your IO to your PLC. Long story short, it helps keep a problem with one of them from affecting all of them.

2nd, there are a number of potential reasons multiple network cards might make sense. It is often a good idea to isolate the IO network from the main plant network. You use 1 card for the IO and 1 to communicate to the upper level SCADA/MES system.

Another reason would be if you have large IO systems, you might need multiple cards to support them all.

Finally, if you need the plc to have multiple IP addresses, then you need multiple cards. This goes hand in hand with the network separation from reason 1.
 
what are IP addresses of these cards ? Are all of them within the same subnet ?

if the answer is yes then the reason may be you want to handle communication better (1 card may not be enough but 4 cards might be too many).
 
CIP Routing is not Ethernet Networking...

DINT2 said:
what are IP addresses of these cards ? Are all of them within the same subnet ?

if the answer is yes then the reason may be you want to handle communication better (1 card may not be enough but 4 cards might be too many).

What if I said that all four Ethernet modules had the same IP address and Subnet Mask?

Would you think that that would handle the communications better or worse?

It's not a trick question. Your answer will determine your understanding of how these types of network configuration actually work.

Regards,
George
 
What if I said that all four Ethernet modules had the same IP address and Subnet Mask?

Would you think that that would handle the communications better or worse?

It's not a trick question. Your answer will determine your understanding of how these types of network configuration actually work.

Regards,
George

You will have an IP conflict if you set all of them to the same IP address.
 
You will have an IP conflict if you set all of them to the same IP address.

That is NOT true. That would only be the case if you plugged all four into the same physical network, which would be unrealistic.

One of the plants I do work at, it is common to see 3 ethernet modules in some of the racks. 1 for controls, 1 for remote IO, and 1 for HMI/SCADA.
 
My last project had 4 ethernet modules: 2 EN2TR ring modules and 2 EN2T regular modules. One ring was for connection to a communication gateway chassis, the second ring was for multiple subsystems to talk to each other, one of the regular modules was to provide data to a local HMI, and the last module was to provide a monitor only connection to a Yokogawa UGS setup. We have physical segregation for each network as a standard and other logical divisions where necessary.
 
LOL

you are unrealistic.

we talk about specific example ---> check post no.1 picture:

1rack
1PLC
4eth cards
all blue eth cables

you ask question: what of all cards are same IP address

my answet is: you get a conflict.


Sorry, not trying to be rude, just factual.

You can absolutely have 4 ethernet cards with identical IP/subnets configured, and as long as they are on 4 different networks, everything is fine. Conflicts can only exist on the same physical network, not across the backplane. ;)
 
Sorry, not trying to be rude, just factual.

You can absolutely have 4 ethernet cards with identical IP/subnets configured, and as long as they are on 4 different networks, everything is fine. Conflicts can only exist on the same physical network, not across the backplane. ;)

yes I know. this is why I have re-read my post and deleted it few seconds after I posted it but I was not quick enough. unfortunately, you read it and quoted.

I apologize to Geospar, he is fully right.
 
Why CIP Routing is not Ethernet Networking...

No apologies necessary here...

But I do apologize if the tone of my post seemed in any way condescending. It was not intended to be. Quite the opposite in fact. Whenever I notice a statement that seems to be fundamentally incorrect, and I "think" I know better, and I have the time, then I will try to inform the person(s) as to what I believe is their misconception. I do so in an effort to teach, not ridicule...

I was trying to pose the question in a manner intended to make you stop and think about it for a while and then come back with your answer. I also added a subtle distinction into the post title to stir your mind a little. If you still came back with the "IP Conflict" type answer then that is fine too as it also informs me that my initial thinking was correct. You do not fully understand the difference between a Logix based Industrial Automation CIP Network, that happens to use Ethernet media, and any other "regular" Ethernet Network.

A design flaw perhaps?...

A fair few of us will have heard of or come across ControlNet and DeviceNet Industrial Networks.

A few of us are fairly experienced at using them.

A lesser few of us are very experienced at using them.

A lot of us will have heard of Ethernet Industrial Networks.

A lot of us "think" we are fairly experienced at using them.

A lot of us "think" we are very experienced at using them.

So much so that we will quite confidently give what we feel is experience backed advice to people that may be using what can be quite complicated Industrial Automation Control Systems (IACS), that happen to be using Ethernet media.

Huh? Why would I think that?...

Again, this is not to be condescending. The very fact that so much experience at standard Ethernet implementations can often be in place long before a user first meets Industrial Ethernet, and its implementation using CIP, that the waters are already muddied. Too much prior knowledge of the Ethernet Standards can be a dangerous thing. It's very important to grasp the whole concept of the Ethernet Standards, so as to better understand how they are implemented while using CIP. But it can often be seen, such as in this case, where a person automatically, but incorrectly, applies the Ethernet Standards in their normal way to a very different implementation to what they have experienced before.

When I first met ControlNet and DeviceNet, which also use CIP, I had to learn them from scratch. They were proprietary in every way. There were no previous systems quite like them; ODVA's Object based CIP was a new concept to Industrial Networking. Similarities could be drawn of course with others, but they were fundamentally unique in their implementations. So there was no prior knowledge of anything that could confuse you between each of them or any other networking architecture. Ethernet based CIP was not introduced until some years later. But...

I have been dealing with Ethernet Networks for as long as I can remember. Certainly long before Industrial Ethernet Networks and CIP arrived on the Allen Bradley scene. If I did not have any experience, or enough experience working with Industrial Ethernet Networks to know certain differences, some subtle, some not so subtle, then it could be quite easy for me, and of course many others, to draw upon there sometimes vast knowledge of "Ethernet" and apply it, incorrectly, to these apparently similar networks.

In short...

Many users who are quite familiar with Ethernet Networks, do not fully understand that the same rules do not always apply when dealing with Industrial Ethernet Networks.

I won't go all into ODVA and CIP and the OSI Layers. I'm off on a long enough tangent as it is. But I will put it as simple as this...

CIP is the Common Industrial Protocol Standard which was designed specifically for use in Industrial Automation Control Systems (IACS). It is an Object-Oriented Protocol which may be implemented using a number of different physical media. Therefore it is known as media-independent.

The fact that Logix based systems, such as ControlLogix, can use CIP over Ethernet media (EtherNet/IP), which happens to be the same media that many other Ethernet based protocols use, is not to be confused as these CIP systems being the same as those other systems.

Ethernet/IP, which is CIP implemented using Ethernet Standards, is an Application Layer Protocol. It defines its Transport, Network, Data Link and Physical Layers using the current Internet Protocol (IP).

(I said I wouldn't get into all the OSI Layers, etc., didn't I?...Oh well, that's blown it!)

EtherNet/IP defines the data structure to be used inside TCP or UDP data packets. For instance, using the CIP Object-Oriented model EtherNet/IP can use the well known User Datagram Protocol (UDP) to transport I/O messages, which is one of its most widely used implementations i.e. Implicit I/O Control.

In general on an Ethernet Network, Industrial or otherwise, most devices are transparent to each other on the same Subnet and so devices must be configured in a unique fashion, else there will be conflicts.

On an Industrial Ethernet Network, where many devices, or Nodes, exist on the same Subnet, they are all exposed to each other's traffic and faults. To reduce this risk you try to break down the devices into groups that only need communicate with each other. The most basic way to achieve this is by using IP Subnetting. This way the Subnet Mask will only allow devices on the same Subnet to communicate with each other.

Where you have more than one Subnet, and devices on each Subnet are configured the same, you must segregate them using a form of "Segmentation". This allows us to further separate out these individual Subnets so they can co-exist on the same wider network while using identically configured devices. A typical example is where you purchase more than one of the same machine or process that have identical networking configurations. Rather than getting into reconfiguring them all to be unique, you Segment them.

Segmentation can either be Physical or Logical. Physical means just that; you use hardware to physically create the boundaries between the network segments. An example of this is the Logix Backplane. All of the modules, whether processor, communications, etc. are physically isolated from each other via the Backplane.

Logical Segmentation may be achieved by creating Virtual Local Area Networks (VLANs). Different IP Subnetted devices can be added to the same VLAN but it is recommended to assign each IP Subnet to its own VLAN. VLANs have the added advantage of restricting the traffic to between the devices within that VLAN only. To communicate between VLANs you must use a Layer 3 Switch or Router to perform Inter-VLAN Routing.

You can assign the same IP Subnet range to multiple VLANs, as in the case of the identical machines, but you cannot use Inter-VLAN Routing between them. They must remain standalone to each other and can only be routed to other VLANs that use a different IP Subnet range. An example of this is two drives connected via Ethernet to their respective local controller. They both have the same IP address and Subnet Mask but are assigned to two different VLANs. They are both under the Implicit Control of their respective controller and do not need to directly communicate with any other device outside of their IP Subnet or VLAN. If you must route between devices on different VLANs then you must assign unique IP Subnetting. VLANs and Inter-VLAN Routing will typically be setup using Stratix 8000 series switches or their equivalent.

The more you need to break down different parts of your installation into meaningful segments, to avoid unwanted traffic and faults between unrelated sections, the more complicated the installation can appear to become. You choose whether to physically and or logically segment your Industrial Ethernet Network.

In this case here, they either by choice, or by necessity, decided to physically segment everything on the Industrial Ethernet Network in the local chassis. So the Backplane is acting as the Gateway or Router for any communications that these Ethernet modules may be passing between themselves and the local controller, or the other Ethernet modules. Even though it appears as though all the Segmentation has been carried out here in the local chassis; there may very well be heavily configured VLANs on switches connecting into this chassis. Physical and logical Segmentation.

One thing to consider is that it is entirely possible that none of them are actually talking to each other and that each one is just for segmented communications to the local controller.

The more that "you" i.e. wendaiyu, DINT2, or anyone unsure, understand about Industrial Ethernet Networks and the reasons why they may be physically and or logically segmented, the more you can appreciate how this installation may not be as convoluted as it may at first appear.

The guys have given plenty of good examples where multiple segments might be required, so I won't get into all the permutations as to why those modules might be there.

More on the Backplane to come...
 
Last edited:
CIP Targeted Traffic...

I just wanted to finish up with a little bit more of an explanation on the Logix Backplane and how it passes data...

On the Logix Platform CIP traffic must be "Targeted Traffic". This means that all CIP packets will require an explicit path to their destination. This will require criteria such as...

source/backplane/slot/port<<<>>>port\slot\backplane\destination

Where you have multiple Ethernet modules in the same Logix chassis they are isolated from each other by means of the Backplane. They cannot see, browse through or communicate with each other in any direct way. Again, the CIP packets coming in through one Ethernet module must be targeted to go out through another module. This is known as CIP Routing, or Multi-Hopping. The local chassis i.e. any local controller(s), or indeed other communications module(s), cannot using these specific CIP packets as they are not targeted toward them. It is being Routed through the Logix chassis to the specified target only. The Logix Backplane will not allow any other traffic through except for CIP targeted packets.

So how can two Ethernet modules, passing CIP Routed traffic between each other, have the same IP address?

Aside from the physical segmentation provided by the Backplane, why does it not matter?...

An age old analogy used by Rockwell is the Street Number v House Number...

A person on Street A, House 1 wants a package picked up and delivered to a person on Street B, House 1. The Delivery Service does not care that both Houses are numbered 1. Once they know that they are on different Streets they can easily Route their way from A-1 to B-1.

So, in the same chassis...

The first Ethernet module is in "Slot 4", which represents "Street A" with an IP address of "10.10.100.1", which represents "House 1".

The second Ethernet module is in "Slot 6", which represents "Street B" with an IP address also of "10.10.100.1", which also represents "House 1".

The Backplane represents the "Delivery Service".

Say one controller is sending the CIP data to another controller and the chassis with the two Ethernet modules is acting as the Gateway or Router. The sending controller must have a Multihop path set even though the transmission is only really between two end devices. This is again because all CIP traffic must be targeted, which not only means the destination device must be set in the path, but also any intermediate devices that the traffic has to Hop through. The same IP address may appear more than once in this path.

Example Path:

Logix controller in local chassis in Slot 0 and Ethernet module in Slot 5, sending to another controller in remote chassis in Slot 10, which as an Ethernet module in Slot 8. The path goes through a Gateway chassis with Ethernet modules in Slot 4 and Slot 6. There are four Ethernet modules in use here. The two Gateway modules have the same IP address of 10.10.100.2...

1, 5, 2, 10.10.100.2, 1, 6, 2, 10.10.100.3, 1, 10

Where...

1 = Local controller Slot 0 To Backplane
5 = To Slot 5 Ethernet module (10.10.100.1)
2 = Out Ethernet port
10.10.100.2 = To Slot 4 Ethernet module in Gateway chassis (10.10.100.2)
1 = To Gateway chassis Backplane
6 = To Slot 6 Ethernet module (10.10.100.2)
2 = Out Ethernet port
10.10.100.3 = To remote chassis Slot 8 Ethernet module (10.10.100.3)
1 = To remote chassis Backplane
10 = To remote controller in Slot 10

Once a properly formatted path has been set, it can include the same IP address twice or more times depending on the number of Hops. The CIP packets just follow the breadcrumbs home, no matter whether they think they've visited the same House more than once, or not.

While I'm going out of my way to point out this possibility, it is just to demonstrate the fact that it can be done and why it can be done. Where multiple modules are involved, and this can go for other networking types as well; while you can set identical node addressing, good practices would dictate that you avoid duplicate node addressing where possible to save confusion.

Regards,
George
 

Similar Topics

Hi all, I am new to the PLC world and I am about to start a new training specialize program to get trained on ALLEN BRALDLY PLCs, I want to buy a...
Replies
2
Views
3,722
I'm a Siemens person, and this is one of my first AB programs. The customer wants everything programmed in Ladder. I have a lot of data (3...
Replies
14
Views
153
Good day everyone. if you have a logic for 3 pumps (lead/lag/off), would you please email it to me? I really appreciate it!
Replies
7
Views
157
Maybe this is just not possible, or maybe I am doing something wrong. Background; I have a data array of over 1500 products. For sorting I...
Replies
6
Views
727
Hello everyone, I'm currently using RS Logix5000 software for machine programming with this Rockwell PLC using the Structured Text method. The...
Replies
19
Views
1,950
Back
Top Bottom