Do I need to add our Gateway to the device list on the Allen Bradly CompactLogix 1769 in in order to communicate

[Cotafam]

We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is set for 1,0 because we are going through a 1783-ETAP switch using the Device port. For some reason, they are not communicating and I am looking for possible reasons and what we need to change. The 1783 is set for "Uses the IP settings that are acquired by a DHCP server". We are using a Linux based computer and can change DHCP at will I want to say we are DHCP enabled currently and are going to try Static to see if that works. Please let us know your thoughts.

 

[OkiePC]

Not the exact same setup, but when I use a VPN router to remote access an Allen Bradley PLC with programming software, I have to set the IP address of the VPN router as the Gateway IP Address in the PLC.

 

[Ken Roach]

The 1783-ETAP is just a 3-port switch on which two of the ports support Device Level Ring. It performs no routing or gateway or VLAN or other functions.

The "1,0" CIP Path is the normal default for a controller in Slot 0. It also applies to all the 1769-series CompactLogix. It doesn't have anything to do with TCP/IP or gateways. or the 1783-ETAP.

The ETAP does have its own IP address, though, for configuration and status and the embedded webserver. Make sure it's not duplicated by your remote access box or any other device on the network.

And the 1783-ETAP has some cousins, like the 9300-ENA and 1783-NATR that are little routers.

Try testing an ordinary TCP connection to Port 44818; in Linux you can just use netcat

nc -v -w 2 z <IP address> 44818

If your Linux box isn't on the same subnet as the controller, then it's an ordinary matter of networking that you should have the CompactLogix default gateway set to the IP address of your router.

 

[Cotafam]

The 1783-ETAP is just a 3-port switch on which two of the ports support Device Level Ring. It performs no routing or gateway or VLAN or other functions.

The "1,0" CIP Path is the normal default for a controller in Slot 0. It also applies to all the 1769-series CompactLogix. It doesn't have anything to do with TCP/IP or gateways. or the 1783-ETAP.

The ETAP does have its own IP address, though, for configuration and status and the embedded webserver. Make sure it's not duplicated by your remote access box or any other device on the network.

And the 1783-ETAP has some cousins, like the 9300-ENA and 1783-NATR that are little routers.

Try testing an ordinary TCP connection to Port 44818; in Linux you can just use netcat

nc -v -w 2 z <IP address> 44818

If your Linux box isn't on the same subnet as the controller, then it's an ordinary matter of networking that you should have the CompactLogix default gateway set to the IP address of your router.

Ah, so if I am understanding you correctly we cannot access the controller through the 1783 or we only need to change the IP of our gateway to the "assigned gateway address of the controller instead of using the IP address". What would the correct path be for this if the device port is an option? Thank you.

 

[Cotafam]

Ah I see, definitely need to change to static IP to something closer to the PLC.

 

[Ken Roach]

I'm not sure I understand your question.

The 1783-ETAP should be entirely transparent to the communications. The only way that you need to account for it is by not setting any of your devices to the same IP address as the -ETAP uses.

The CompactLogix has an IP address, a subnet mask, and a default gateway IP address. The default gateway IP address should be set to the IP address of whatever device provides a gateway or router function for the network.

If that's your remote-access device, then set the CompactLogix Default Gateway IP address to the LAN-facing IP address of your remote-access device.

The CIP Path is still "<CompactLogix IP>, 1, 0".

You can also try omitting the "1,0". CompactLogix controllers for the past 6-7 years (every controller after the 1769-L35E) accepts CIP comms directly to its built-in port and doesn't need the Backplane and Slot designations.

 

[Cotafam]

We are not using this as a read-only situation the "Linux gateway' is only polling tag values from the AB controller not providing internet access for the Controller. Currently, there is no Gateway address assigned to the controller do we need to add one in this case?

 

[plvlce]

If it is going to communicate with anything outside its local network, it needs to know where to send the traffic. Unless you are programming in a set route, that means you need the default gateway.

 

[Cotafam]

If it is going to communicate with anything outside its local network, it needs to know where to send the traffic. Unless you are programming in a set route, that means you need the default gateway.

Alright if I assign a Gateway address that would require a soft reset to take hold?

 

[Cotafam]

And by outside of its local network, I figure it is directly connected to the 1783 switch that it would not be needed.

 

[Cotafam]

Alright so we can set a gateway address on the AB and set the the Linux box connectioned to the 1783 switch to search for that address. I guess final question would be do I need to reset the PLC afterwards for this to take affect

 

[plvlce]

So is your Linux box already on the same subnet as the PLC? If not, you need a routing device, and I've seen no mention of one in your setup yet. Just plugging devices into each other doesn't automatically make them able to communicate.

As Ken already told you:

The default gateway IP address should be set to the IP address of whatever device provides a gateway or router function for the network.

Alright so we can set a gateway address on the AB and set the the Linux box connectioned to the 1783 switch to search for that address.

You don't just pull an address out of thin air to give as a gateway address, you use the existing address of the device that is performing the gateway function.

 

[Cotafam]

No no, I gotcha there. IP for the gateway is static (similar IP and exact subnet address) and I can ping the PLC, but yes still no values coming through our MQTT broker. So I can make the gateway address of the AB the same as the IP on the Linux. Soft reset the PLC and it's set. Now I still have to get a path on the Linux I am assuming I would keep this as the IP address of the PLC?

 

[Ken Roach]

>Now I still have to get a path on the Linux I am assuming I would keep this as the IP address of the PLC?

Yes.

Is your Linux hardware and application something commercially supported or open-source (like Node-Red or a well known Python library) or is it wholly home-spun ?

I mention it because sitting next to me is a Raspberry Pi 3B running Node-Red and some simple Python scripts and it's on an isolated network where both the Raspberry Pi and the CompactLogix 1769-L30ERMS2 have their Default Gateways set to 192.168.1.1 (and there's no actual gateway or router installed at that address). It's totally normal IPv4 on a private LAN, and it works fine.

In both Node-Red and Python, the target address I use for the CompactLogix is just the IP address. Both the Node-Red EtherNet/IP node and the pylogix (thanks, Dustin !) library have the option to add "1,0" to the end if I were using a slot-mounted ControlLogix or an older CompactLogix, but I don't use that option because I have a "5370" family CompactLogix that has embedded DLR and can either accept direct IP endpoints or emulate a Logix backplane (1,0).

You're describing your system as being intended for "remote monitoring", and mentioned that you are using MQTT to send data to a broker. So I figure you've either got a gateway or router that gives you access beyond the PLC LAN for the MQTT feature, or you've got a device with more than one network interface.

 

[Ken Roach]

>do I need to reset the PLC afterwards for this to take affect

Probably not. CompactLogix controllers apply their IP address changes immediately when the TCP/IP Object is written to by application code, or by RSLinx Classic, or by anything else that can modify the TCP/IP Object. Most switches and other clients will promptly update their ARP tables to resolve that new IP address.

The TCP/IP Object that Rockwell devices use is defined by the CIP Specification. Virtually all RA devices store that in nonvolatile memory separately from the user application. Downloading a new user program, or even new firmware, to a CompactLogix does not change its IP address.

It can't *hurt* to cycle power to everything, but it's not normally necessary.