ST145 and ST146 are the clue.
There are a couple of possibilities:
1. There is so much comm traffic on the PLC's network that it is unable to keep up processing, and has overrun the IP stack's packet queues. This is probably bursts of broadcast traffic. We see switches do dumb things occasionally, like rapid bursts of gratuitous ARPs. We've also seen cameras broadcast a lot. Scan time affects the PLC's ability to process these, so it could be a combination.
2. You have created one or more UDP or TCP devices and something is sending traffic to the them, but the PLC program isn't processing them. This can eat the queues.
Unless you are doing any custom protocols, it is likely #1.
The first best answer is to prevent that kind of traffic. We do our best to handle it, but we have still seen occasions where a perfect (packet) storm can cause the IP stack some heartburn. If we can get details on how to dupe it, we're happy to try to harden things up further.
Barring elimination of offending traffic, if the PLC can tolerate a reboot, you could add some code to check the state of the remote slaves and if all of them stay logged out for too long, do the REBOOT command from the PLC. Be careful that you write the code in a way that the PLC don't get trapped in a reboot loop...be sure you clear the timer/counter/delay trigger before issuing the REBOOT.