1756-EN2T "lost" IP address

Good day folks,
We have an L71 processor (v30.02) in a rack with an EN2T connected to the plant network & another (v10.007) used for IO only - both are connected to a managed switch.

The other day, we had a brief power/network outage. When everything came back up, the IO network EN2T had a "minor" IP address conflict fault. Looking at the module properties in Studio 5000, The general tab showed the correct Ethernet Address (grayed out) while on the Internet Protocol tab, the Physical Module IP Address, Subnet Mask & Gateway Address fields were now all 0.0.0.0. I was able to re-enter the correct information and restore comms but the fact that communication to all remote IO racks was lost for a while really caused our plant some grief. So here are my questions:

1. Any idea why this happened?
2. What can be done to prevent this from happening again?

Thanks in advance.

1. Any idea why this happened?

Click to expand...

The person who configured the 1756-EN2T forgot to disable BOOTP/DHCP.

Or, someone who didn't know what they were doing used a tool like Studio 5000 or RSLinx Classic to enable BOOTP/DHCP.

When the next power cycle came along, the module did what it was configured to do.

>The general tab showed the correct Ethernet Address (grayed out)

Click to expand...

The user program still had that information from when the Studio 5000 user keyed it in. While the IP address of any ControlLogix Ethernet module must be entered into Studio 5000, it is actually *stored* in the NVRAM of the module (or module object, if it's virtual) and not in the user application.

Yes, it's possible that you encountered a bug or glitch that caused the module to reset itself to defaults. But it's far more likely that the module was set to use BOOTP/DHCP.

Thanks Ken. To confirm: this is a static network configuration and DHCP/BOOTP are both unchecked in the port configuration. I set up this module about six years ago, and can't recall if I used RSLinx or BootP utility to do so, I'm certainly capable of such mistakes.

One clarification is that power was not lost to the 1756 rack, so I'm wondering if this was a result of temporary IP conflict as the network was coming back up. We have VLANs set up through our managed switches and while I'm not very knowledgeable on their inner workings. When this rack has powered down in the past, the module has always retained its IP settings upon power up. I hope this helps.