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

[Cotafam]

Current Settings static
PLC: 192.168.1.10
Sub: 255.255.0.0
Gateway: 192.168.1.252

Linux Current Settings
IP: 192.168.1.254
Sub: 255.255.0.0
Gateway: 192.168.1.252

In our system, I have the Linux unit searching for the 192.168.1.10

 

[Cotafam]

>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.

We are running ubuntu 20.xxx in this case. Our platform that the MQTT is messaging to our "home-spun" software. This device is currently using cellular to commucate

 

[Ken Roach]

What you describe ought to work.

Run through the usual diagnostics on the Linux box; PING, ARP, NETCAT. Figure out if it can talk to the CompactLogix using ICMP PING and a simple IPv4 connection on Port 80 and Port 44818.

Once you've got that verified, then you can troubleshoot your PLC driver or library.

 

[Cotafam]

What you describe ought to work.

Run through the usual diagnostics on the Linux box; PING, ARP, NETCAT. Figure out if it can talk to the CompactLogix using ICMP PING and a simple IPv4 connection on Port 80 and Port 44818.

Once you've got that verified, then you can troubleshoot your PLC driver or library.

Oh man I didn't even think of making a driver on RSLinx for this application.

 

[Cotafam]

Modbus has been much more simple

 

[Ken Roach]

Yes, RSLinx Classic is a good way to verify that a Windows PC has basic connectivity to a Rockwell controller. The "Ethernet Devices" driver allows you to enter IP addresses or hostnames directly, and the "EtherNet/IP" driver binds to a NIC and uses a broadcast discovery mechanism.

If the application were using Modbus/TCP you would have verified that you could connect to a TCP server on Port 502, instead of Port 44818. PING and ARP would be the same. Default Gateways and IP conflicts would have been the same kind of things to rule out. You would have needed to verify link lights and pinouts and functional ports on the switch just the same.

Thanks for posting the updates... I'm confident you'll figure it out !

I haven't done any cloud/cellular/MQTT sort of applications so they're sort of exotic to me. But I connect to a handful of different networks and machines every week, so I do a lot of basic network troubleshooting and configuration.

 

[Cotafam]

Response from Netcat

 

[Cotafam]

Response from arp

 

[Ken Roach]

Sorry, bad syntax example above for netcat; I omitted the dash before z. Netcat options are always dash with an uppercase or lowercase letter, and the IP hostname or address and port are inferred because they're at the end.

-v means "verbose", -w 2 means a timeout of 2 seconds, and -z means that it will just try to make the TCP/IP connection without actually transmitting anything across that connection.

I have a Raspberry Pi so it's Debian, and I'm not using a Docker container. That's a wrinkle I wasn't aware of in your system. I'm connected to the host through an ordinary SSH console at 192.168.18.125, and my target is a 1756-ENBT module at 192.168.18.228.

Example of my basic connectivity troubleshooting:

 

[Ken Roach]

Your ARP rsponse above shows that you apparently have just one TCP/IP interface on this machine, and it's a Docker container. That container has an IP address that is on the 172.17.0.0 subnet, which might be private or might be assigned by your mobile Internet service.

I admit that Docker containers are outside of my expertise. I tend to run my Linux stuff on bare metal.

 

[Cotafam]

Phase of the day is "it was a backend issue" Thank you all for your support in these dark dark times.