Ethernet communication problems

So here is my update. After spending 2 hours on the phone with a very nice engineer from China turning my computer over to him to reload the firmware and the program. We still have the same problem. Then he realizes that the IP address is a dynamic instead of a static address even though it is set up for static address. So, I ended up doing a little work around I timed how long it took the HMI to communicate and set up a timer on the second switch that I have the two diameter controls connected to turn on in one minute. Rebooted everything a half a dozen times and everything communicated. I hope this will take care of this problem. Only time will tell. I checked out the web p age for the 1400 and from what I saw there was no problem. Thanks again for all your input.
Sorry don't know why the Jpeg is so big

Glad to see you fixed your issue! Just out of curiosity, is this IP address for these diameter gauges? Or is it on the 1400?

I am also curious about how the IP addressing is done in this system, but we may have identified the culprit.

In general, static IP addresses are recommended for any small automation LAN.

You're probably familiar with how Windows or Linux can be set up to "fall back" to a fixed IP address, or an "Automatic Private IP Address" (169.254.0.x) in the event that a DHCP dynamic address isn't obtained.

The MicroLogix 1400 operating system cannot do that. If you set it for dynamic IP addressing, it will keep trying to get a dynamic address forever.

The PanelView Plus is based on Windows CE, though. If it's set up for DHCP and does not get a response from a DHCP server, it will try to determine if there are any other devices connected at all (using gratuitous ARP).

If there is at least one other device connected, the PV+ will give itself an APIPA address. If there are no other devices connected, the PV+ will keep trying for a DHCP address forever.

I'm not certain about what's going on here.

With the PV+ and the MicroLogix 1400 both connected to the same switch, if the PV+ is inadvertently set for DHCP it should detect the MicroLogix as another network device and give itself an APIPA, thus putting itself on a different logical network than the MicroLogix (169.254.0.x versus 192.168.1.104). That would be consistent with the network timeouts and inability to read the Data Tables in the MicroLogix.

The presence of the networked diameter controllers shouldn't matter, but evidently it does.

I know there was a PV+ bug where some static configuration data could get corrupted; the firmware was supposed to have been fixed in 2018.

https://rockwellautomation.custhelp.com/app/answers/answer_view/a_id/1076421/loc/en_US

Related: When I do a PV+ project, I like to put the FactoryTalk "Diagnostics List" object on a full size screen all by itself, instead of just in the automatically-created Diagnostics window that pops up when there are errors.

That will let you see the history of the services that run at startup, which I think includes the DHCP client status. I would have to get out a PV+7 to be sure.

Even if you hide the GoTo Display object that opens that screen, this is useful to have for the engineer's use.

The PV, 1400 and 1 of the diameter controler are static IPs the second one is stuck on dynamic. That is the webpage for the 1400. All seems well I haven't had any complaints today.

"Even if you hide the GoTo Display object that opens that screen, this is useful to have for the engineer's use."
That makes sense. I will use that on the next one. Thanks