1734-AENT will connect

Title should read "WILL NOT"

I have a small (15 node) system controlled by a 1769-L33ER PLC. All of the IO is remote and connected via 1734-AENT modules. The system is spread out over our campus, which forced me to, don't yell, use the IT network.
I have one panel that I cannot get to connect to the network. Of course, IT says there is something wrong with the panel, but after checking chassis size, auto-negotiate, unicast, and everything else I could not get the panel to connect. I then took the panel to a working connection it worked fine. Following are the details.

1. IT has set up a VLAN for 10.184.198.xxx and configures particular ports for me to use.
2. On the port in question, I can connect a laptop and ping the PLC successfully.
3. I can also ping the laptop from my desk.
4. When I connect my panel and turn on the power.
a. I get a solid green Module Status LED, a solid green Network
Activity LED, a slowly flashing green Network Status LED, and a
solid green PointBus Status LED.
b. The Module Status and the Network Status lights on both IO cards
are solid green.
c. After several seconds, the NA led rapidly flashes.
d. The NS led turns solid green and I can I see outputs turn on.
e. Less than a second later the 1734-AENT NS LED turns red, the
outputs turn off, and the NS LEDs on the IO cards start flashing
red.
f. Shortly after that the PBS LED starts flashing red.
g. This is the final status of the LEDs
i. MS – Solid Green
ii. NA – Rapidly Flashing
iii. NS – Flashing Red
iv. PBS – Flashing Red
v. IO MS – Solid Green
vi. IO NS – Flashing Red

Questions
1. I know ziltch about VLANs. Any thoughts on what I should suggest IT look at?
2. Any idea what would cause the AENT to respond this way?
3. If I end up using Wireshark to troubleshoot is there anything in particular I should look for?

Unplug the trouble device from the network, ping the trouble device. See if you have a second device with the same IP. The almost immediate drop off can indicate an IP collision. No two devices may share the same IP at the local level.

"I then took the panel to a working connection it worked fine. ".

Cable length from PLC to the non-working location?
Ask IT to do loop test on the cable.

If these are routed subnets there may be ACL's involved blocking the CIP port 44818. Rockwell had a utility that would check the common rockwell ports, "TCP Port Probe utility" I think...
Worth a poke.

All the Status Indicators you mentioned seem to be pointing to a communication timeout.

Edit: from your laptop connect to the port and try Test-Netconnection YourIP -port44818 (I think, I have not had to use this in awhile)
2nd Edit: Think should be like Test-NetConnection -ComputerName plcIP -port44818

maybe someone else can come in and save me here but I used something like this in the past to test if a port was open on IT side.

I like TCPing for testing the connectivity over TCP.


But when the I/O connection switches to UDP for cyclic I/O, you're back to other rules/configurations.

This is the sort of thing where Wireshark and a mirror/sniffer port is likely necessary.

telnet <ip> <port> is best, IMNSHO.

It's neat to see what folks prefer !

I seldom use Telnet to poke around with automation equipment, especially A-B, because so few devices support the protocol, on any port.

The Windows PowerShell Test-connection command does work to determine if an arbitrary TCP Port is open, as does TCPing.

A connection failure of this type is probably more complicated than just opening TCP Port 44818 because it's cyclic data on UDP after the connection is established.

According to ODVA's latest conformance test report, in order for an EtherNet/IP device to pass the current conformance test, port 44818 should be available, while the use of other ports is discouraged. I do not know exactly when this became a requirement. I think for security reasons ODVA does not recommend the use of Telnet protocol. The below screenshot is part of the current test report for EtherNet/IP devices.

Of course there could be tenths of thousands of EtherNet/IP devices which were installed prior to this requirement being mandatory item of the conformance test suite. But new devices should conform to this, because at least the laboratory with which I am familiar with does a very thorough testing, and I am assuming ODVA has a very uniform standard for all of its accredited laboratories.

Ken Roach said:

It's neat to see what folks prefer !

I seldom use Telnet to poke around with automation equipment, especially A-B, because so few devices support the protocol, on any port.

Click to expand...

What I meant was that [telnet <ip> <port>] is a quick way to see if you can connect - pass packets* to - to the port, nothing more.


I.e. it will either connect*, or not (typically either connection refused if the host at <ip> is not listening on <port>, or connection timeout or no path if there is no connectivity to the host at <ip>.


I did not mean to imply that the host at <ip> actually implemented a telnet protocol e.g. provided a command line or shell.


* press the key sequence {<Ctrl-]> <c>- <Enter>} to close, IIRC.
** TCP packets only, of course

See below: .1.112 is a MicroLogix 1100 that has Ethernet/IP enable; .1.214 is an S7-1214 that does not:

great point; refusal of a TCP connection is also a way to infer basic IP connectivity.

I prefer a positive and tidy confirmation that Port 44818 is open and listening, which is why I use TCPing.

Maybe time for a different thread titled "If you only use PING, you're typing with mittens".

Ken Roach said:

great point; refusal of a TCP connection is also a way to infer basic IP connectivity.

I prefer a positive and tidy confirmation that Port 44818 is open and listening, which is why I use TCPing.

Maybe time for a different thread titled "If you only use PING, you're typing with mittens".

Click to expand...

mittens. heh, good one.


So telnet is TCPing without the timing info output and a few other command-line options, and the default port is 23 instead of 80.

Thanks for all of the suggestions. I am afraid I don’t have anything definitive to report. Shortly after posting this the connection started working. IT tells me that they replaced the cable between the patch panel and the switch. I suspect it was something with the port configuration but will never know.

I did confirm there were not identical addresses.

I also checked the length and it was well under 100m. The electrician used his tester and confirmed the pinout.

I searched for the TCP Port Probe Utility and found a very handy pdf that listed the various ports devices use. It has a link to the utility but I was not able to get it to install on my PC.

I was able to open PowerShell and use test-netconnection xxx.xxx.xxx.xxx –port 44818 to confirm I can get to the port. Make sure you use test-netconnection and not test-connection (no “net”).

I also installed TCPing which worked. Make sure the command prompt is using the same directory and where TCPing is installed.
Again, thanks for the help.