1761-Net-Eni Loss of Communication over time

I have setup our plant with most of our SLC PLCs on ethernet. Most are 5/05 but some are Net-Eni's. I have been having some conectivity problems with the ENIs. They work for a few days and then stop communicating. I can ping them and they respond but They dont communicate with RSlinx. to resolve the problem I have to cycle the power on the ENI, then they work fine for a couple more days. I have tried old ENI revisions and new ones, both with the same problem.
Any suggestion?

Are the Net-ENI's faulted when you go to reset them ? What is the state of each device's RS232 and Ethernet link and traffic ports ?

Can you view the Net-ENI's embedded web pages ?

When you PING the devices, also do an "ARP -A" to check your ARP table's MAC ID's against the device's physical ID's, to be sure nothing is spoofing or replacing the Net-ENI's.

Is your automation network connected to the plant network ?

I have not seen Net-ENI's behave this way.

I too have encountered this. Got in the habit of cycling power to avoid.

My guess is that you are seeing an issue due to the connection limit of the Net-ENI module. 2-in, 2-out, 2 in/out.

For some reference try looking at the following tech notes.
http://www.rockwellautomation.com/knowledgebase/
Search using "CIP Connection"

And also this specific tech note
Answer ID 23057

Are you doing only read messages or are you also writing?

There is a small chance of this happening with write messages. If you are doing write messages change them up and have the target controller do read messages if possible or temporarily disable the write messages and see if it solves it

I have the exact same problem.
I have 3 NET-ENI's on a plant, 2 works fine, but the last one needs to be power cycled every 2 weeks.
It’s a very simple setup with the SLC and a SCADA system on the top. No communication to other PLC’s, panels or other SCADA systems.

I have read the tech notes mentioned but cannot find the solution!?!

Manual power cycling every 2 week is not a solution.

Can you give specifics on your incoming and outgoing connections?

Is anything special happening when this occurs?

It seems to happen randomly after 2 weeks to 2 months.

I haven't understood the concept of connection, but as I wrote there is only one SCADA system on the top communicating with an SLC trough the NET-ENI. There is no other communication going on.

I don’t even go online on the SLC.



This NET-ENI is on a VPN connection. Don’t know if that matters. The other NET-ENI is on the same physical network as the SCADA, and they never loose communication.

Could it be caused by short breakdowns of the VPN connection?

Bump...

I am having the same problem as the original poster and can not seem to resolve it. Just wondering if anyone has any additional information.

The setup I have is as follows:

Several NET-ENI modules connected to ML1500's. All 1500's connect to a KepWare OPC server via the NET-ENI modules. Not sure if they are pingable when they go offline (haven't actually been there when they go offline... maintenance resets them pretty quickly for production...). Sometimes we have to power cycle the NET-ENI a couple of times to get it to reconnect.
We also have a couple of 5/05's on the same network but don't have any problems with these.

Any suggestions on what might be causing this or solutions would be greatly appreciated...

Thanks!

I have probably 35+ ENI connected to 1500s around the plant that work without fail for the most part. I did have a spell were I would only see the ENI and not the 1500 in RSLinx but when we installed my own network a lot of problems went away.

I did have an issue yesterday that I have not determined if it is the ENI or a flaky cable/connection. It was as if I had to get it communicating with something else and then it started working. Connecting to it with the laptop to verify the IP and settings took a bit but I was able to and it has stayed connected to the original 1500 using the original cable.

I am not sure if it is, a flaky cable [I am betting on this one because of past success with the ENI] or the ENI is getting flaky.



Sorry for not being more help.

I've had occasional flaky comms with ENI modules, but for me the solution was to disable the 'Autobaud' setting in the configuration, and set the PLC port comms to exactly match the attached PLC.

They also really want a solid power supply.

Mine are all power through the cable, if that makes a diff.

Thanks for the replies... We have tried powering through the cable and with an external power supply without any change. I want to say that there is something wrong with the network, but they don't have any problems with the PC's that are connected, just the ENI's. The PC's in the plant are setup for DHCP, the ENI's have static IP's. Could this be causing an issue? (Don't see how it could but I'm not a guru with Ethernet either...) Also wonder if it could be an issue with the OPC server. It is very aggrevating as it is occurring daily now...

Yes/No.

It totally depends on how your ethernet infrastructure is set up.

If you have a DHCP (or BOOTP) server set up on a 192.168.1.2-192.168.1.254 address range, and your devices are also in that range, you will definately have periodic problems.

If that is the case, then you neec to configure the DHCP (BOOTP) server to manually exclude certain addresses (your NET-ENI's).

For some completely unfathomable (to me) reason, both DHCP and BOOTP servers, when requested to issue an IP address, don't "Pick next available, Ping it (to make sure nothings there) and Then Issue it"

But even if they did, DHCP/BOOTP IP leases are valid for a given time, so say (as above) someone comes in before the plant is powered up, turns on their computer, and is issued 192.168.1.14 (same as some static-non-powerd up device).

They run out to buy donuts (and COFFEE) for the startup crew, and power down their computer. Now, the startup crew powers up your device, which is statically assigned 192.168.1.14. Eventually boss-man comes back (with donuts and COFFEE) passes the goodies out, goes back to his desk, and turns his computer back on. What happens?

Boss-man's computer boots up, looks in it's log, and see's that is has a valid IP lease for another 6 hours. It tries to pop onto the network at 192.168.1.14 (and it actually identifies itself as such, THEN pings). Oddly, there is another host with that address. The newcomer (Boss Computer) and probably the other host (your device) get very confused. Boss Computer pops up (assuming Windows) a dialog saying "Duplicate IP Detected", and will switch itself to a total private address in the 169. region. The poor other device out there doesn't know quite what to do, and is probably trying to respond to packets it has no idea what to do with, so has a nervous breakdown.

Damn.. I'm babbling.

Moral of the story is, for Ethernet, PUT STATIC ASSIGNED DEVICES IN A COMPLETELY DIFFERENT GROUP FROM DHCP/BOOTP ASSIGNED DEVICES.

DHCP/BOOTP servers can be very finely controlled, so you can reserve dozens of individual IP's from the DHCP/BOOTP server's 'Avaliable List', or, as I prefer, just expand the subnet. Internally, there is no reason you can'e expand a Class C subnet (192.x.x.x to 223.x.x.x, standard subnet mask 255.255.255.0) up to a Class B subnet (128.x.x.x to 191.x.x.x, standard subnet mask 255.255.0.0). Then, assign the DHCP server to deal with 192.168.0.x for DHCP stuff, and assign 192.168.1.x for static stuff (both with subnet mask of 255.255.0.0).

kbcombs said:

Thanks for the replies... We have tried powering through the cable and with an external power supply without any change. I want to say that there is something wrong with the network, but they don't have any problems with the PC's that are connected, just the ENI's. The PC's in the plant are setup for DHCP, the ENI's have static IP's. Could this be causing an issue? (Don't see how it could but I'm not a guru with Ethernet either...) Also wonder if it could be an issue with the OPC server. It is very aggrevating as it is occurring daily now...

Click to expand...

Rdrast,

Thanks for the in-depth reply. The PLC's (read ENI's) are assigned static IP addresses somewhere in the 10.20.5.xxx range. Subnet is 255.255.0.0. From what I am told the DHCP server is assigning addresses in the 10.20.1.xxx range on the same Subnet. Would this not eliminate the problem you described of devices being assigned an already existing IP? Thanks again for the help!!!