Ethernet subnet question

rocksalt · Mar 16, 2017

I have 3 racks(1756). The 1st rack has PLC and one ENBT module with a subnet of 172.10.10.X. The second rack has 2 ENBT modules + IO, one with 172.10.10.X and the other with 170.5.5.X. I use the 170.5.5.X to go to my office and other switches in the plant. The 172.10.10.X communicates the IO to the PLC of the second rack and third rack.

I can communicate from my office to the 172.5.5.X from any switch in the plant. I recently installed a remote IO device (Acromag 982EN-6012) at the other end of the plant on the 172.5.5.X subnet and the PLC cannot connect to it. I can see the device in RSlinx from my office on that network. As a test I connected a test PLC to the switch at the originating PLC and it can see and talk to the remote IO device across the plant.

Any suggestions?

harryting · Mar 16, 2017

It's hard to follow without a diagram. It's always hard when you mix in physical and logical separation. It seems from your post that the IO network is not involved at all with this Acromag device, at least physically. is that correct?

If that's true, what do you mean that can not connect? If all you dealing with are on the same network, physically and logically, then can you ping the Acromag device?

dmargineau · Mar 16, 2017

All your remote I/O is located on the 170.10.10. subnet since the 170.10.10. bridge is the only one located within the Local Chassis (PLC Chassis).

You will not be able to control any remote I/O on a subnet which's bridge is located in a remote chassis: EtherNet/IP I/O traffic does not "hop" over subnets as software applications do.

If you want to use the 170.5.5. network for I/O traffic too, add another bridge in the Local Chassis, address it 170.5.5. and patch it within one of the 170.5.5. switches.

rocksalt · Mar 16, 2017

That's what I thought.. I was hoping there was a work around.

cmothebean · Mar 16, 2017

Put the Acromag on the 172.10.10.X network?

Timbert · Mar 17, 2017

rocksalt said:
That's what I thought.. I was hoping there was a work around.

I'm pretty sure it can be done. It may not be very easy. The switches along the way must be properly configured as well as the Ethernet adapters. dmargineau is right EtherNet/IP I/O traffic doesn't typically cross subnets. In modern versions (about RSLogix v20) you can set up to have I/O use unicast instead of multicast. If the gateways and subnets are set correctly and there is a layer 3 switch to route across subnets this should work. This will allow connections to remote I/O. Don't know if your version or the Acromag support this.

If you have the IT skills and equipment you could make the Acromag part of a virtual LAN (vlan) where it thinks it still in the local subnet even though it is connected physically to a remote switch.

I don't think this is really the correct way to deal with it. Connect the Acromag to the proper switch and subnet and be done with it.

AGill · Mar 17, 2017

You could move the 170.5.5.X ENBT into the rack with the processor.

rocksalt · Mar 17, 2017

I cannot configure the Acromag to use the PLC subnet because it's connected remotely, on a different subnet. The PLC network only has access to it's own network. The only way traffic can can get from the PLC, to the plant network is through the 172.5.5.x network.

I thought about connecting the 172.10.10.X network directly to the plant network. However, I don't believe this will work unless the switch is configured, for that port, to do as Timbert suggests.

I think configuring the switch is to messy. I will need to re-configure the entire PLC network due to slot availability. Ideally, I would have connected the 172.5.5.X ENBT to the PLC rack, but I didn't have any slots left. There are quite a few network devices on this PLC network to change, sigh.

AustralIan · Mar 17, 2017

Please restrict your usage to private IP address ranges.

https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces

Using a public IP address range causes problems with some devices.

Interestingly, 170.5.5.x is owned by Fedex.

Also, it looks like you are mixing up 172.10.10, 170.5.5 and 172.5.5, which could be why your test plc setup works.

Also, not all switches support multicast or broadcast communications, which is the default for many devices, and the only option for some devices.

For further assistance, please post the IP address and subnet mask of devices involved. Also part numbers of the I/O and all switches involved.

This manual may help you help yourself:
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/enet-rm002_-en-p.pdf

rocksalt · Mar 17, 2017

AustralIan said:
Please restrict your usage to private IP address ranges.

https://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces

Using a public IP address range causes problems with some devices.

Interestingly, 170.5.5.x is owned by Fedex.

Also, it looks like you are mixing up 172.10.10, 170.5.5 and 172.5.5, which could be why your test plc setup works.

Also, not all switches support multicast or broadcast communications, which is the default for many devices, and the only option for some devices.

For further assistance, please post the IP address and subnet mask of devices involved. Also part numbers of the I/O and all switches involved.

This manual may help you help yourself:
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/enet-rm002_-en-p.pdf

I made up the IP addresses used in this topic but the scenario is the same.

I miss-typed the IP below.

Rack 1: 172.10.10.1 ENBT/A - PLC rack
Rack 1: 172.10.10.2 ENBT/A
Rack 2: 172.10.10.3 ENBT/A
Rack 3: 172.10.10.4 ENBT/A
Rack 3: 172.5.5.1 ENBT/A

Rack 3 connects to plant Ethernet @ 172.5.5.X
*note 172.5.5.X and 172.10.10.X are fictitious numbers to illustrate a scenario .

The PLC cannot talk to the 172.5.5.X remote device through the 3rd racks 172.5.5.X ENBT/A module.

The switches are all Cisco switches (part number not known). I am able to connect a test PLC on the 172.5.5.X network, at the machine, and talk to the Acromag unit on 172.5.5.X located at another switch in the plant.

Sorry for the confusion.

dmargineau · Mar 17, 2017

I wouldn't ever consider controlling I/O over VPNs; the technology is sound and quite mature, however, even with network redundancy it is still a "soft" connector for Real-Time data transfer; we all know how that (still) goes.

I presume the Acromag I/O is quite far away from the nearest 172.10.10. switch and you need a fiber media run/hardware.

Do you have room in the chassis containing the 172.5.5. bridge? If you do, add another PLC there, "take-over" the new remote I/O and then Produce/Consume pertinent data between the original controller and the new addition using the existing 172.10.10. I/O subnet.

AustralIan · Mar 17, 2017

Can you enable unicast on your I/O module?

Attached screenshot for generic module with unicast enabled.

harryting · Mar 17, 2017

"The PLC cannot talk to the 172.5.5.X remote device through the 3rd racks 172.5.5.X ENBT/A module."

Ok, now I read your description again, I don't see why it wouldn't work.

so you have two network, Network A and Network B. Network A is the IO network that string all the rack together and Network B is the HMI network but connects through one of the Remote rack. I am able to configure it in the IO tree just fine.

Of course, I might be still be missing something without a diagram.

rocksalt · Mar 17, 2017

dmargineau said:
I wouldn't ever consider controlling I/O over VPNs; the technology is sound and quite mature, however, even with network redundancy it is still a "soft" connector for Real-Time data transfer; we all know how that (still) goes.

I presume the Acromag I/O is quite far away from the nearest 172.10.10. switch and you need a fiber media run/hardware.

Do you have room in the chassis containing the 172.5.5. bridge? If you do, add another PLC there, "take-over" the new remote I/O and then Produce/Consume pertinent data between the original controller and the new addition using the existing 172.10.10. I/O subnet.

This IO device is a secondary warning system to a guardshack to turn on a warning light.

I do not have any spare slots in any of the racks. Yes, I could add the PLC but this is more expense than needed. I can just change all the IP addresses if need be.

I do have another option that I did not consider and I just went out and tried it. I have 2 ENBT in rack 1, but I do not see any devices attached to it in the controller for one ENBT modules. I re-assigned this ENBT the 172.5.5.X and connected it to the VPN and it is working. I knew it would but I didn't realize it was not used. sheesh..

What I don't understand fully is why can't the ENBT's jump subnets in the rack with 2 ENBT modules. Once of them connects to the PLC. But.. if I install an ENBT in the PLC rack with different subnets it works. Seems like there is software than can do this.

rocksalt · Mar 17, 2017

My luck would have it...

I am running PLC ver 16.04. The ENBT is version 4.7. Connect it to the VPN and "duplicate IP address detected". I had this happen in the past and changed to PLC version 19. In this case the machine is running so I can't flash it now. I remembered this happened to be a few years ago and I changed the revision of the ENBT to 2.xx and it worked in a 1756 system. So.. changed it to 2.3 and it now works.

The newest revision is not always working due to some "enhancement"...

Ethernet subnet question

rocksalt

Member

harryting

Lifetime Supporting Member

dmargineau

Lifetime Supporting Member

rocksalt

Member

cmothebean

Member

Timbert

Member

AGill

Member

rocksalt

Member

AustralIan

Member

rocksalt

Member

dmargineau

Lifetime Supporting Member

AustralIan

Member

harryting

Lifetime Supporting Member

rocksalt

Member

rocksalt

Member

Similar Topics