Best Practice for Ethernet I/O Communication fault

I was wondering how everyone is handling Ethernet Communication faults. I am trying to figure out what best practice is.
We running compact logix L36erm with some 1769-Aentr drops. Everything is connected with Stratix 5700 switch.

When the system powers up in the field the we sometimes get

Error (Type 03) I/O Fault (Code 16) I/O module connection failed on required

We want to have the I/O fault if there is loss comm while running.
I don't want to do it on the startup.

We have been told, this is caused by the Stratix 5700 switch. The switch does not boot-up fast enough. Has any seen this before?

I can reset the fault with GSV \SSV commands. I really don't like resetting major faults automatically. Not sure that this is best practice.

What is the best way to handle this error? Ant tips would be appreciated.

It probably is being caused by the slow boot time on the Stratix. The way I typically deal with that is to configure my ethernet modules so there is not a major fault on the controller when a connection fails, monitor the connection with logic and handle the faults programmatically. I typically map ethernet i/o to tags to use in the logic, and write zeros to these tags in a fault state. You could use a first pass bit to set a delay before entering the fault state or actively using the i/o.

Could you use a first scan bit to seal in a timer and have it run for a duration that would cover the boot up time for the stratix, then use the TT bit (along with any other required permissives) to clear any comms faults? That would get you past the initial startup.

I typically set all the networked I/O modules to not cause a major fault when disconnected, and then handle the comms failure programatically. You can for all intents and purposes treat an I/O station being offline the same as an e/stop*, so nothing will run until your comms are all established, but it's just a matter of waiting for the switch to start up and then pressing reset to clear the faults.

Edit: *from a programmatical point of view, that is. Obviously, there's a huge difference between an e/stop and a comms failure at the physical level.

Since you mention AENTx models outright, you can configure fault states for the discrete and analog outputs (depending on the application).

Try this. After a specified time delay the PLC will check the connection status of a module using GSV. If the connection is broken the COMM_FILLPOINT_TIMEOUT tag will break the operation. Once the connections returns to normal, the operation will resume automatically.