 Home  Forums  Downloads  PLCs.

net Store  PLC Tut

 Log in Register

 New posts

Home  Forums  PLCS.net - Interactive Q & A  LIVE PLC Questions And Answers 

On Logix5000 system, why there are two or more Ethernet cards

on the same rack?
 wendaiyu ·  Apr 5, 2016

1 2 Next 

wendaiyu Apr 5, 2016  #1

Member Hi, folks, how’s going?

W 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.

Join Date: Jun 2014

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

Thanks for your help.

 Reply

Archie Apr 5, 2016  #2

Member
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

A 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.
 You are not registered yet... Please click here to register now and access all the forums FREE
Join Date: May 2002
Using a managed switch can keep the broadcast traffic off an IT
features!!
Location: Orangeburg, SC
Posts: 1,944
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.

 Reply

mk42 Apr 5, 2016  #3

Lifetime Supporting Member 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

M 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
Join Date: Jun 2013
from the main plant network. You use 1 card for the IO and 1 to
Location: MI
Posts: 3,519 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.

 Reply

alan_505 Apr 5, 2016  #4

Lifetime Supporting Member

Looking at your picture, maybe they are using one DLR for the safet
IO and one DLR for the normal IO and one card for the plant

A network and maybe one card for the HMI network.

Join Date: Feb 2007

Location:
Melbourne,Victoria,Australia
Posts: 1,155
 Reply

DINT2 Apr 6, 2016  #5

Member
what are IP addresses of these cards ? Are all of them within the
 same subnet ?

D 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).
Join Date: Sep 2013
Location: GER
Posts: 40
 Reply

Geospark Apr 6, 2016  #6

Lifetime Supporting Member

CIP Routing is not Ethernet Networking...

DINT2 said:

what are IP addresses of these cards ? Are all of them within the same
subnet ?
Join Date: Feb 2012
Location: Kildare if the answer is yes then the reason may be you want to handle
Posts: 3,010 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

 Reply

TConnolly Apr 6, 2016  #7

Lifetime Supporting Member

Standard procedure for us. We separate the Controller network from
the IT network.

Join Date: Apr 2005

Location: Salt Lake City
Posts: 6,152
 Reply
 DINT2 Apr 6, 2016  #8

Member
Geospark said: 

D
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?
Join Date: Sep 2013
Location: GER
It's not a trick question. Your answer will determine your understanding of
Posts: 40
how these types of network configuration actually work.
Click to expand...

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

 Reply

DINT2 Apr 6, 2016  #9

Member
TConnolly said: 

D
Standard procedure for us. We separate the Controller network from the IT
network.

Join Date: Sep 2013

Location: GER the same here. 1 or 2 cards per PLC for control nw and 1 card per
Posts: 40 rack for upstream comms.

 Reply

phuz Apr 6, 2016  #10

Member
DINT2 said: 

P 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
Join Date: Jun 2008 into the same physical network, which would be unrealistic.
Location: Mohnton, PA
Posts: 1,074 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.

 Reply

PCMusicGuy Apr 6, 2016  #11

Member My last project had 4 ethernet modules: 2 EN2TR ring modules and 2
 EN2T regular modules. One ring was for connection to a

P 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
Join Date: May 2013
physical segregation for each network as a standard and other
Location: Houston
Posts: 47 logical divisions where necessary.

 Reply

phuz Apr 6, 2016  #12

Member
DINT2 said: 

P
LOL

you are unrealistic.

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

Join Date: Jun 2008
Location: Mohnton, PA
1rack
Posts: 1,074
1PLC Click to expand...

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.

 Reply

DINT2 Apr 6, 2016  #13

Member
phuz said: 

D
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
Join Date: Sep 2013
Location: GER backplane.
Posts: 40

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.

  Reply

Geospark Apr 6, 2016  #14

Lifetime Supporting Member 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.
Join Date: Feb 2012
Whenever I notice a statement that seems to be fundamentally
Location: Kildare
Posts: 3,010 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: Apr 6, 2016

 Reply

Geospark Apr 6, 2016  #15

Lifetime Supporting Member

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

Join Date: Feb 2012
means that all CIP packets will require an explicit path to their
Location: Kildare
Posts: 3,010
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

 Reply

1 2 Next 

           

? Write your reply...

 Post reply

Similar Topics

R Laptop system requirement for Replies: 2 Dec 26, 2014

Views: 3,989 Operaghost
RSLOGIX5000
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...
ramzy2277 · Dec 25, 2014 · LIVE PLC Questions And Answers

P RSLOGIX5000 V16 Replies: 1 Sep 28, 2024

A
Views: 190 AlfredoQuintero
HELLO EVERYONE I HOPE YOU ARE HAVING A
WONDERFUL DAY! I WAS WONDERING IF ANYONE
COULD TELL ME HOW I CAN GET VERSION 16 OF
RSLOGIX 5000? RIGHT NOW...
pmiller42021 · Sep 28, 2024 · LIVE PLC Questions And Answers

S LMS8 ethernet connection parameters in Replies: 2 Oct 23, 2024

S
Views: 202 Sparker19
Logix5000
I have replaced an old ethernet switch (1783-EMS08T) on
a site, they were being monitored by SCADA. the
replacement switches as recommended by...
Sparker19 · Sep 24, 2024 · LIVE PLC Questions And Answers
 Logix5000 V21.03 - Online/Upload problem Replies: 13 Sep 11, 2024
J
Views: 435 joseph_e2
Hi guys - more issues with V21.03 - hoping someone has
some insight or ideas on f/w upgrades. Controller: 1756-
L73 ControlLogix Revision 21.11...
Level · Sep 10, 2024 · LIVE PLC Questions And Answers

A How to convert RsLogix5000 Version 20 to Replies: 14 Jul 10, 2024

Views: 873 I_Automation
RSLogix 5000 Studio version 30?
I have a 1769-L24ER Q1B1 Series B (Series B can only run
programs from series 30.00 and up) I updated the
firmware on the controller to ver. 30...
androcci · Jul 9, 2024 · LIVE PLC Questions And Answers

Share:       

Home  Forums  PLCS.net - Interactive Q & A  LIVE PLC Questions And Answers 

Contact us Terms and rules Privacy policy Help Home