1756-EN2TR/Stratix 5700 Question

jacoffey85

Member
Join Date
Nov 2016
Location
NC
Posts
75
Here's the scenario, We have a ControlLogix processor with three 1756-EN2TR modules:

Referring from the picture:
[2] - 1756-EN2TR - IP is 10.64.89.XXX - Communicates with the main line
[3] - 1756-EN2TR - IP is 10.64.90.XXX - Communicates with the main customer server
[4] - 1756-EN2TR - IP is 10.64.96.XXX - Internal machine network (contains our point I/O and drives).

The customer is wanting to be able to connect to our PLC through the main line card, and be able to still see all of our point I/O and drives from the master control station for troubleshooting purposes.

Whenever RSLinx is opened, they are able to see the EN2TR (machine network) but cannot see the Stratix switch directly after it or anything connected to the drives. Obviously when I plug into the machine network I can see the Stratix and everything connected to it.

Is there some kind of port inside of the EN2TR that I need to open or could it be an issue with the Stratix configuration? We have a major shutdown next week so I'm hoping I can have a solution for them during that time.

Also I did try to do some searching, but I might not have had the right terminology, as I couldn't find anything that really helped.

Thanks in advance!

i_o_tree.JPG
 
It is not the Stratix switch but the intended topology and chosen RSLinx driver.

If the customer's PC is connected to the 10.64.89.XXX subnet their RSLinx utility will need to use a Ethernet driver (not EtherNet/IP!) in order to access the 10.64.96.XXX subnet; moreover, you will have to provide them with (and them enter the information within the RSLinx Ethernet driver configuration) all the addresses of the devices on the Internal Machine Network (10.64.96.XXX).
 
I'm a little bit confused about the position of your Stratix switch, but by using the 3 x EN2TR cards, you will prevent anyone from getting to the control side from the line side (including the Stratix if it's there?).

In other words, if you connect to the PLC from any EN2TR, you will see the entire tree, the PLC will be fine with all devices, etc. However, if someone plugs into a switch upstream from the [2] - 1756-EN2TR - IP is 10.64.89.XXX, they won't be able to ping anything attached to any other EN2TR card.

All that being said, your design makes sense. Your controls network should be isolated. The customer should only connect through it to the PLC. Once on the PLC, an engineer/tech should be able to get most of the diagnostics on all devices. If they really need to get to the drives or pointIO, they would need to walk down to a "grace port" which would be set to that control network.
 
It is not the Stratix switch but the intended topology and chosen RSLinx driver.

If the customer's PC is connected to the 10.64.89.XXX subnet their RSLinx utility will need to use a Ethernet driver (not EtherNet/IP!) in order to access the 10.64.96.XXX subnet; moreover, you will have to provide them with (and them enter the information within the RSLinx Ethernet driver configuration) all the addresses of the devices on the Internal Machine Network (10.64.96.XXX).

I will give that a shot. One thing we found is that our 3rd EN2TR (Internal Machine) has a subnet of 255.255.255.0 (I did not originally set these up, I'm just the field engineer) while the rest of the 10.64.89.XXX network is on a 255.255.0.0. I believe this may be the next path to take whenever we can take the line down again.

I'm a little bit confused about the position of your Stratix switch, but by using the 3 x EN2TR cards, you will prevent anyone from getting to the control side from the line side (including the Stratix if it's there?).

In other words, if you connect to the PLC from any EN2TR, you will see the entire tree, the PLC will be fine with all devices, etc. However, if someone plugs into a switch upstream from the [2] - 1756-EN2TR - IP is 10.64.89.XXX, they won't be able to ping anything attached to any other EN2TR card.

All that being said, your design makes sense. Your controls network should be isolated. The customer should only connect through it to the PLC. Once on the PLC, an engineer/tech should be able to get most of the diagnostics on all devices. If they really need to get to the drives or pointIO, they would need to walk down to a "grace port" which would be set to that control network.

The Stratix Switch that I control is on the internal machine network. Our other two EN2TR's connect to the main line's switch and the customer switch respectively. I do not have any control of those switches, just the Stratix in our network.

They're wanting to have access to the drives through the global network for data logging purposes as well as being able to monitor changes. Other lines in their plant (not our equipment) require user login and password from the Technicians to do any changes so that the change and the person doing the change are both documented. They also have it tied into their DCS for large scale process monitoring.

It's a very unique case for us as we generally don't deal with this type of system.
 
One thing we found is that our 3rd EN2TR (Internal Machine) has a subnet of 255.255.255.0 (I did not originally set these up, I'm just the field engineer) while the rest of the 10.64.89.XXX network is on a 255.255.0.0.

There are reasons for these setups.

The 'Internal Machine' subnet is a time critical network carrying mostly I/O Class communications essential to the equipment's functionality. It is 'segregated' from the rest of the system's comms via dedicated Enet bridge and it is 'limited' to 254 nodes for functionality and security purposes.

The other two subnets are SCADA and MES interfaces thus needing to be accessed by various other IP Addresses probably scattered over multiple LANs; this type of communications are usually Peer-to-Peer and not time critical.

A software 'tap' into a Level 0 (I/O Class) subnet will inadvertently decrease the system's performance; multiple 'taps' might compromise some of the functionality.

Provide the customer with the IP Addresses of the relevant devices on the I/O subnet for the required access, however, I wouldn't make it 'easy' for others to do so; it is the right (and safe) way to do modern automation.
 
I believe this may be the next path to take whenever we can take the line down again.

You really don't need to take the line down to setup an RSLinx Ethernet driver...This is 2018...:D

Make a list of the IP Addresses of the devices on the 'Internal Machine' subnet.

On the customer's PC open-up the RSLinx applet, choose the Menu bar Communications menu and then pick Configure Drivers; from the Available Driver Types drop-down choose the Ethernet devices one then click the Add New button; OK the given name.
Once the Station Mapping applet opens up start typing in the IP Addresses from the list using the Add New button to add new rows.
When done Okay it.

Upon the completion of above procedure, using the newly configured Ethernet Devices type driver, the customer's RSLinx utility will be able to 'drill' through its own subnet's Enet bridge, move across the Logix Backplane and then go 'out' through the 'Internal Machine' bridge onto the I/O subnet.
 
Last edited:

Similar Topics

I am using Allen Bradley PLC 1756-L81E and EIP module 1756-EN2TR for Ethernet/IP communication. My communication works fine but in Get-Attribute...
Replies
2
Views
164
Hi All, Got a funny issue. I have a 1756-L85EP and a 1756-EN2TR in the same chase. The client asked for the Ferrari and the 3 lane highway!!! We...
Replies
1
Views
125
Good morning, I have a system on 1756 L73 that works with supervisor on EN2TR modules. Everything works correctly, except that EN2TR (1) with...
Replies
4
Views
457
Hi. Rockwell learning curve 132-1b. I was having trouble to change IP address on a EN2TR. Finally found out that I need to change the IP...
Replies
1
Views
734
Hello Everyone, What is the best practice for DLR set up. Should I keep all VFDs on one DLR and FlexIO on another or it would make sense to put...
Replies
8
Views
2,516
Back
Top Bottom