Ring Network IP address sequence

Hello,

I'm adding devices to the existing ring network - AB Device Level Ring (DLR). Can you please suggest if having all of the devices' IP addresses in sequese is necessary (i.e. 192.168.1.100->192.168.1.101->192.168.1.102....etc.) or non-sequential works as well (i.e 192.168.1.100->192.168.1.117->192.168.1.102....etc.)

Thanks.

You can have them whatever you like - I would have them sequentially though.

janner_10 said:

You can have them whatever you like - I would have them sequentially though.

Click to expand...

I'd have them sequential too, but that means re-labeling all cables and devices themselves. Plus changing static IP addresses on all of the devices (DIP switches).

Do you mean having the IP addresses sequential, in keeping with the physical sequence they are placed in the Device Level Ring? Can you tell me why do ye think that matters?

That is not how how a ring topology works. That is not how Ethernet works.

The Ethernet cabling between devices simply provides the basic Level 0 Physical Layer of the OSI Model. The physical order of the devices, or the order of their IP addressing, does not dictate how or where the data at the higher Application Layer is propagated on the wire, nor does it do anything to improve efficiency. Two devices physically sequential on a ring, and irrespective of their IP addressing, may always be, may seldom be, or may never be communicating with each other. It has nothing to do with where they physically are or what IP addressing they are configured for.

The data on the wire is targeted according to the Application Layer configuration, but each device port on the physical ring topology will be exposed to the data. However, only devices that the data is targeted for will process and reply to the source. All others will reject the data.

Placing devices that must communicate with each other on the same Subnet is important, or on the relevant VLAN, if using routing. But sequentially addressing devices within those in an attempt to physically sequence them serves no real purpose.

Don't get me wrong. I suffer O.C.D. as much as the next poor soul, and I'm all for neat and orderly design. But if provisioning devices onto an existing network, I would not be trying to go as far as this.

192.168.1.10 will communicate just as well with 192.168.1.100 at 6 physical hops away, as it will with 192.168.1.11 just 1 hop away.

Regards,
George

Hello Geospark:


I believe the advise of our colleagues is based not on Ethernet communication considerations, but from the point of view of system documentation, maintenance, cabling labeling considerations. Imagine there is a problem on New Years Eve and there is no sober IT guy around. Having a system properly documented, cables properly labeled, etc., can be crucial in diagnosing and fixing certain issues, without IT specialist or PLC developer.

Also check the switch controlling the ring if you didn't put it in. Some of the Stratix switches can do positional DHCP which you may have to add to that scheme to properly add a new device.

AlfredoQuintero said:

Hello Geospark:


I believe the advise of our colleagues is based not on Ethernet communication considerations, but from the point of view of system documentation, maintenance, cabling labeling considerations. Imagine there is a problem on New Years Eve and there is no sober IT guy around. Having a system properly documented, cables properly labeled, etc., can be crucial in diagnosing and fixing certain issues, without IT specialist or PLC developer.

Click to expand...

Hi,

Yes, I do/did consider this. I did mention how I can be O.C.D. with the order of things, in any design. But "this" should not matter, if done properly. If you drop a new 192.168.1.100 node into an existing ring topology, where the highest previous node is 192.168.1.10, and label it as such, then the next person to deal with this system should be relying on those very document updates you speak of, which should now include this new node number, which has its new and correct labelling. You should not need (or want?) to start shifting existing nodes, cabling, labelling, configurations and schematics around.

If someone is viewing Industrial Ethernet layout schematics, and expecting everything to be perfectly sequential, or else their head might explode (exaggeration, of course), then really they should not be viewing them in the first place. 10 loops to 100 and then on to 20. It looks strange, perhaps, and one might wonder why it was done that way, buy if the schematics match the installation, all should be well.

I'm using a distant node number (100) just as an example of how little it should matter. Of course, just because we are dealing with an Ethernet ring topology does not mean we have a closed loop with respect to available node numbers. A ring topology, like any other topology, will have a lowest to highest node numbering schema. So realistically speaking, there should always be a next highest node number available (11 after 10) or a next node number within each decade of nodes, depending on the schema (11 after 10 or 21 after 20, etc.). Leaving spare node numbers in between existing nodes is often done for this reason. Node 1 is 10, 2 is 20, etc. This way if you add a node physically, or otherwise, after 10, it can be 11, with still further spares up to 19. Also, as a ring topology can be physically spread out between different areas, say on a production line, or different steps in a process, we would/should use a segregated schema. Either under the same Subnet with grouping, as I've outlined just now (nodes 10+ for area 1, nodes 20+ for area 2, nodes 30+ for area 3, etc.), or using segregation by VLANs where each designated area in an installation is given its own "Subnet", if you will. With VLANs, two separate areas or machines could even be using identical IP node addressing, but the VLAN number for each area will be the unique identifier.

You should just install the device where it is physically intended to go and cable to it in the best or simplest manner you see fit. The addressing applied should not need to be specific in accordance with its position on the ring, but should be in keeping with the IP addressing schema for the system.

Even for a new installation this should apply. If I have a DLR controller in a right side cubicle with a DLR HMI on the door. Also 10 DLR drives in a left side cubicle, in two rows of 5, one above the other. I then have a passthrough hole in the centre. The first loop from the controller could physically go to drive 5, then looping back left through to drive 1, then looping down to drive 6, and right through to drive 10. The last loop could go back through and up to the HMI, and then back to the controller. Physically, this may have been the best way to root the ring cabling. The controller is node 1, HMI is 2, and the drives are nodes 3 through 12. If you say you'd prefer to go from the controller(1) to the HMI(2), then to drive(3), and so on, with the cabling, then that is fine, and your prerogative. But all I am saying is that it is not necessary for any practical reason. If you document it as it is cabled and labelled, then that should be enough for future souls.

Regards,
George

Some industrial Ethernet protocols such as Profinet require support for LLDP (link-layer discovery protocol) for devices with conformance class B or higher. The TIA engineering tool allows assignment of specific ports on switches and devices with more than one port, and if one device is connected to a port different from the specified, even though the device is able to communicate with the PLC, the two or more devices with incorrectly connected ports send alarms to the PLC and the PLC flashes an alarm lamp. In some applications I have seen such an alarm with shut the system off, and this is done on purpose for safety considerations.


Currently ODVA is working on an enhancement of the CIP specification, the EtherNet/IP adaptation, to add support for a new optional class which will deal with topology management by means of LLDP. So for EtherNet/IP systems in the not too distant future it will be possible to, and perhaps some machine builders will, assign ports to connect field devices and manage this through the PLC program.


But yes, with current EtherNet/IP DLR technology, as long as the IP address is not used by any other node it will work without additional setup as long as there is at least one DLR supervisor and all other nodes are DLR node capable.

Did you know that Rockwell provides a FREE tool called "DLR Tool" that allows you to see the DLR ring IN ORDER, and, if the program was run on a healthy ring so it knows what to expect, can also show you where a break is?

IIRC, it's an extra install with Logix/Studio, and requires Linx to use. It's not a perfect tool, but it's better than trying to play musical chair with cable naming and IP addresses just to put everything "in order".

AlfredoQuintero said:

Some industrial Ethernet protocols such as Profinet require support for LLDP (link-layer discovery protocol) for devices with conformance class B or higher...

Click to expand...

LLDP does not require devices be sequentially placed on a network, so, with respect, I'm not sure what your point is here?

AlfredoQuintero said:

...The TIA engineering tool allows assignment of specific ports on switches and devices with more than one port, and if one device is connected to a port different from the specified, even though the device is able to communicate with the PLC, the two or more devices with incorrectly connected ports send alarms to the PLC...

Click to expand...

What you are describing is known as, among other things, DHCP Persistence. I've explained it a few times here on the Forum. Suitable switch appliances may allocate IP addresses to specific ports for specific node devices using a predefined pool of addresses. This allows the switch to manage the device addressing and helps deskill the provisioning of replacement devices. However, DHCP Persistence requires a star topology where each node device is directly connected to its assigned switch port. So it is not really relevant in a ring topology discussion.

To balance things up a bit here, I will mention the following feature which I "think" JaxGTO might also have been referring to it (positional DHCP)? Either way it reminded me of it...

There is another firmware dependent feature that Rockwell introduced to allow "DHCP with DLR", as it's known as. This involves assigning in the switch an index number for each device in ascending order, based on what will be their sequential order, starting out from the switch at index 1. To configure DHCP with DLR, however, you must preconfigure each device with their port settings before adding them to the ring network. This is usually done by first enabling and configuring DHCP Persistence and plugging all devices in to the switch in a star topology. Once all devices have received their DHCP port settings they are all disconnected from the switch and DHCP Persistence is disabled. Next on the switch, under DLR, we set the switch as ring supervisor and assign the 2 switch ports to be used for the ring. Then the Ring DHCP Server is enabled and the index numbering can be assigned to the IP addresses already assigned using the DHCP Persistence pool (we didn't delete that, did we?).

Then we connect the ring cabling in the order of the index numbering and DHCP will use the indexing to count the hops to each device, assigning the correct node addressing, hopefully. If the ring is added to or devices moved around, then the whole setup would need to be repeated to reconfigure the DHCP configuration.

All easy, right?

It's a bit convoluted, but nevertheless, it does exist. While I've implemented DHCP Persistence on several occasions I've no experience of using or seeing DHCP with DLR, yet. So I don't know how well it works?

So to the OP, I would add, "unless you happened to be using DHCP with DLR", then the sequential order of the devices still should not matter.

Aardwizz,

The DLR Tool is included with Studio 5000 v27 and above. But it is also available as a separate download from the PCDC webpage and is also compatible with older versions of Studio 5000 and RSLogix 5000. It does indeed work using an RSLinx Classic RSWho window. It's quite useful at interrogating a DLR but I have known it to sometimes be "buggy" like not identifying the supervisor, or displaying a break instead of a healthy device that should be there. Usually a refresh or restart can resolve that, though.

Regards,
George