PLC-5/20C and 1785 Ethernet Communication Dropout

Hi All,

I have an older system that incorporates a PLC 5/20C and 1785 ENET A sidecar. Right now, I have the rack in a lab environment completely isolated from other equipment. It is connected to my PC via ethernet and a DH+ via a PCMK card. In RSLinx Classic Pro (3.6), when I right click on the PLC within the ethernet driver and select "Device Properties", the system locks up for ~10 seconds before displaying a message that says "Unable to establish communications with the selected device". Monitoring data tables is possible, but very slow. This problem also manifests in the form of tags in an RSView project dropping out intermittently (I can force the tags to begin dropping out by attempting to monitor data tables in RSLinx).

When I right click within the DH+ driver and select "Device Properties" it displays them instantly, and I am able to monitor data tables with no issues.

I understand PLC 5's are limited to 10 half, but are these symptoms typical? The PLC is not doing any messaging at this time. I have tried changing the PC's ethernet port settings from "Auto" to 10 half with no noticeable change in performance. I have also tried a 1785 ENET C with no luck.

Thank you for any insight!

Try this..

You are correct that slow, balky, error-prone communications via the 1785-ENET are not normal. Despite being 10/Half, it's generally far quicker than DH+.

You can run Wireshark to look for retries and repeats and dropped connections, or examine the channel diagnostics for the 1785-ENET via another connection method to the PLC-5. Is the -ENET Channel 3A ? I think you have to designate an integer data file to serve as its diagnostics.

The fact that a different 1785-ENET shows similar problems suggests a problem with the PLC-5 or the backplane interface or however the power gets from the PLC-5 to the -ENET.

I can't see this being a firmware problem, especially if the hardware ran for years without the issue appearing.

The problem Mickey cited with CIP settings usually affects edits, not getting online or data table reads/writes. And it's specific to CIP, while the 1785-ENET/A very probably only supports good old A-B proprietary CSPv4 protocol on TCP Port 2222.

Thanks for the quick replies. I will continue to troubleshoot and let you know what I can find. When you say a problem with "however the power gets from the PLC-5 to the -ENET", do you mean the power supply to the unit through the backplane, or the communication signal between the PLC and -ENET card?

Also, another data point. I tried scanning this network of 1 with RSNetworx for Ethernet/IP and received an error ENET:80CA, "Invalid Identifier found for the device at the IP address/host name. Device ignored. The explanation states that the device at the specified IP address contains an unknown identifier".

If I do encounter a large number of retries, repeats, or dropped connections with wireshark, does that indicate failing hardware?

It's been a long time since I physically worked with these, but I recall just one card-edge pin array between the PLC-5 and the 1785-ENET. I don't know if the -ENET gets power from the 1771 backplane or via that connector.

Obviously clean up the connections (especially to the chassis) and make sure there aren't any bent pins or corrosion around the board connections.

I don't remember when the 1785-ENET got "dual stack" EtherNet/IP and CSPv4 firmware. RSNetworx for EtherNet/IP is probably going to notice any missing objects or unsupported services.

You can use TCPING to find out the support for sure: TCPING with Port 2222 and the -ENET will definitely respond (that's CSPv4), but TCPING with Port 44818 and it won't respond if it doesn't also support EtherNet/IP.

You can infer the same thing by using the Ethernet Devices (CSPv4 and EtherNet/IP) driver in RSLinx and also the EtherNet/IP driver (no support for CSPv4).

Retries and bad packets do tend to suggest failing hardware.

Does the 1785-ENET have a built-in web page with diagnostics and status ? I'm curious how the old ones were built.

Ken Roach said:

You can use TCPING to find out the support for sure: TCPING with Port 2222 and the -ENET will definitely respond (that's CSPv4), but TCPING with Port 44818 and it won't respond if it doesn't also support EtherNet/IP.

You can infer the same thing by using the Ethernet Devices (CSPv4 and EtherNet/IP) driver in RSLinx and also the EtherNet/IP driver (no support for CSPv4).

Click to expand...

FWIW you can test for open ports using windows powershell too, some companies won't allow installation of software such as TCPING,NMAP etc.
tnc xxx.xxx.xxx.xxx -p 502 would check if port 502 is open on a remote machine.

Thank you for that note about the Test Net Connection (tnc) feature in Windows PowerShell !

TCP Port 2222 will show that the controller supports legacy A-B CSPv4 Ethernet protocol.

TCP Port 44818 will show that the controller supports CIP / EtherNet/IP protocol.

Ken Roach said:

Does the 1785-ENET have a built-in web page with diagnostics and status ? I'm curious how the old ones were built.

Click to expand...

Certainly does. Very helpful in diagnosing problems.

Thanks for all of the information. Unfortunately wireshark and the built in web page don't have any red flags. A couple of other notes that I have found while troubleshooting: The only way I can get RSView tags to stop intermittently dropping out is by restarting the RSLinx application. We did have an ENET B card, I tried that as well with no different outcome using a couple different PLC5 processors. Interestingly enough. Interestingly enough, when looking at device properties within the Ethernet IP driver rather than the Ethernet Devices driver, I was able to see device properties with no errors.

Another issue I noticed is that in RSLinx the PLC 5 processors intermittently do not show the program name, but rather just their model.

This is a bit of a long-shot, but if you have a Tech Connect subscription, this note may be of help:

Throttle Back Feature on all PLC5 Ethernet modules

Also, there is a 64-active-socket limit for the sidecar, which could also be a problem. I'm not familiar with RS-View's connection behavior; maybe it is consuming a lot of those connections. I believe the connection usage is shown on the Application Memory Statistics page, next to the Connection Tokens and/or the CSP Session Table.

I found once that forcing the network switch to 10/Half instead of Auto fixed an intermittent problem like this. It was an older network switch, but its worth mentioning.