PV+ to different subnets

Hi,

We have a site that has a CLX-L61 with dual ETN's, & 2x L32E's, + a 2x PV+'s.

The CLX ETN's have IP's on 10.1.17.xx & 10.1.18.xx. One of the L32E's is on 10.1.17.xx, whilst the other is in 10.1.18.xx.

The 10.1.18.xx has 2 point IO drops also on 10.1.18.xx, whilst the 10.1.17.xx has VSD's, that are on 10.1.18.xx.

The PV+'s are on 10.1.17.xx.

What I want to be able to do, is to access the L32E on the 10.1.18.xx network, from the PV+'s, on 10.1.17.xx.

Is this easy enough to accomplish? Do I just need to open the subnet mask up to allow comms to 10.1.18.xx?

Without getting too deep into IPv4 and subnetting, I will assume from your nomenclature that you are using a Subnet Mask of 255.255.255.0, which is also called a "/24" network, because the Network Number is 24 bits (three octets) long.

You have two options:

1. Use the 1756-ENBT modules and the ControlLogix backplane as a CIP (Common Industrial Protocol) bridge. The path you define from PV+ to CompactLogix in RSLinx Enterprise will go into the 1756-ENBT, across the backplane to another 1756-ENBT, out onto the "remote" IP network, to the CompactLogix. This method is the only way if the two networks are physically separate.

2. If the networks are physically tied together, the simplest thing is to change the Subnet Mask so that 10.1.17.xx and 10.1.18.xx are on the same network. A subnet mask of 255.255.240.0 would make both of the hosts you mentioned members of the 10.1.16.0/20 network, which has 16,769,024 possible hosts between 10.1.16.1 and 10.1.31.254.

Thanks Ken,

Without getting too deep into IPv4 and subnetting, I will assume from your nomenclature that you are using a Subnet Mask of 255.255.255.0, which is also called a "/24" network, because the Network Number is 24 bits (three octets) long.

Click to expand...

I think that the actual mask is 255.255.254.0, with a gateway of 10.1.16.1

1. Use the 1756-ENBT modules and the ControlLogix backplane as a CIP (Common Industrial Protocol) bridge. The path you define from PV+ to CompactLogix in RSLinx Enterprise will go into the 1756-ENBT, across the backplane to another 1756-ENBT, out onto the "remote" IP network, to the CompactLogix. This method is the only way if the two networks are physically separate.

Click to expand...

When you say physically separate, I am assuming that you mean complete isolation? Both of the 1756-ENBT modules are connected to the same managed switch, so perhaps option 2 is better suited, and possibly, less complicated?

2. If the networks are physically tied together, the simplest thing is to change the Subnet Mask so that 10.1.17.xx and 10.1.18.xx are on the same network. A subnet mask of 255.255.240.0 would make both of the hosts you mentioned members of the 10.1.16.0/20 network, which has 16,769,024 possible hosts between 10.1.16.1 and 10.1.31.254.

Click to expand...

This is what I will try, this should work. I wasn't sure how far I should of opened up the mask. I am assuming that I will need to do this both on the PV+ & 1769-L32E?

As long as the managed switch is not also separating these ports out into separate VLANs, changing the subnet mask on the PV+ and the CompactLogix controllers from 255.255.254.0 (15 bits) to 255.255.252.0 or lower should allow them to communicate directly with one another.

The most likely options for Subnet masking of this Class C network are:

255.255.254.0 network hosts 10.1.16.1 through 10.1.17.254
255.255.252.0 network hosts 10.1.16.1 through 10.1.19.254
255.255.248.0 network hosts 10.1.16.1 through 10.1.23.254
255.255.240.0 network hosts 10.1.16.1 through 10.1.31.254

A quick bit of background on IP addresses and subnet masks.
10.1.16.1 actually represents the binary number 0001010000000010001000000000001 (I don't guarantee that I did the conversion correctly). Part of that number gives the network address and part gives the address of each machine/host on that network. The usual comparison is with telephone area codes and individual phones within each area. The subnet mask tells each machine/host how much of the left hand side of the number is network address and what remains is machine/host address on that network

So with a subnet mask of 255.255.255.0 which in binary is:
11111111111111111111111100000000
000101000000001000100000 is the network address part of 10.1.16.1
With a subnet mask of 255.255.252.0 which in binary is:
11111111111111111111110000000000
0001010000000010001000 is the network address part of 10.1.16.1

So even though the IP address is the same in both cases they are actually in different networks because the subnet mask is different. Everything on a network must have the same subnet mask otherwise by definition they aren't on the same network.

Bryan

Slight deviation but still (loosely) on topic.

We have just installed several PLCs and HMIs on a dedicated machine network at our customers plant in another country.

All works well and we've created various rules/routes within our Microtik router to allow us to VPN in from our office here in the UK. Now, we're fine running Linx Classic as the ETH-1 driver can be pointed directly to the PLCs IP address and Classic can see the PV+ without issue, but i'm struggling to get Linx Enterprise to see the PV+ units we have installed. It doesn't seem able to browse the remote IP network via the open VPN.

Any ideas?

(Also using Archie's Adv. HMI app across the VPN - looks good! )

Rob

All works well and we've created various rules/routes within our Microtik router to allow us to VPN in from our office here in the UK. Now, we're fine running Linx Classic as the ETH-1 driver can be pointed directly to the PLCs IP address and Classic can see the PV+ without issue, but i'm struggling to get Linx Enterprise to see the PV+ units we have installed. It doesn't seem able to browse the remote IP network via the open VPN.

Any ideas?

Click to expand...

None exactly, what is the problem you are having, you cannot download to the PV's over the VPN?

This site is also a remote location, and we can access everything via the VPN, including transferring PV+ application files (which I am always cagey on doing), but does seem to work ok.

This post may help?
http://www.plctalk.net/qanda/showpost.php?p=286338&postcount=4

That's the problem i'm having - I can't browse the PV+ via VPN using RSLinx Enterprise (RSLinx Classic can see everything using the ETH-1 driver)...

Apart from that - all works well!


Rob

The browsing mechanism of the EtherNet/IP drivers in RSLinx Enterprise and RSLinx Classic are similar. They both broadcast a frame with the CIP command "List Identity Request" in it.

Every device that is on the IP subnet should hear that broadcast and reply with its Identity Object data, which lets RSLinx populate the "RSWho" browse window or table.

Devices that aren't on the IP subnet, or which are connected through a mechanism that does not transmit Broadcasts, won't reply. This is the case with most VPN networks.

In RSLinx Classic, that's the end of the story, and you have to go back to using the Ethernet Devices driver, into which you put the actual IP target address (and can even specify which protocol to use by appending :EIP or :CSP to the address).

In RSLinx Enterprise, you can manually add a device to the browse by right-clicking and selecting "Add Device". You need to know the device's basic type (ControlLogix family is the easiest) and choose it from a list.

RSLinx Enterprise will then browse the device's identity and request the CIP ports (the List Ports service) to decide whether or not to put a + sign next to the device and allow you to browse through it.

Once a device is in the browse window, RSLinx Enterprise periodically checks its presence using ordinary TCP connections instead of broadcasts. If it stops responding, and there is no Shortcut using it, RSLinx will "clean up" the browse by removing the device. If you choose "Stop Browsing" in the RSLinx Enterprise browse window this won't happen.

I'm still torn between which browsing mechanism I like better. RSLinx Classic can leave the browse full of devices that don't exist on my current network and lead to patience-testing waits for the TCP connection to time out and the browse to return control to the GUI. But RSLinx Enterprise can delete devices whose addresses I might have wanted to remember, even if they are not connected. I wish that "Start Browsing" and "Stop Browsing" were explicit on the GUI for RSLinx Enterprise, rather than being hidden right-click features.

I remember having to do that a few years ago - but forgot all about it!

All working fine now. Thank you.