With DirectSOFT connected and doing status, change the c-more to 5 (500 ms) and see if the errors go away.
You also want to double-check the timeout of your DirectSOFT connection. Make sure it is closer to 500ms, not 100ms.
If the errors do go away, that means that the PLC is able to respond, just not at the rate the C-more/DirectSOFT want it to when other clients are also polling.
The 260/ECOM can do 1 to 4 packets per PLC scan based on the complexity of the requests (this is function of the 260 firmware, not the ECOM firmware). Hence, it may take multiple PLC scans to respond to any 1 request. With large scan times, that can easily get you beyond 100ms timeout (2 x 55ms).
By having such a "tight" retry timeout, you end up actually perpetuating the problem because DirectSOFT and C-more will retry, even though the PLC is actually processing ALL the requests, putting more comm load on the system.
It's always best to start the timeouts high, then reducing them and figuring out where the "threshold" is, then doubling it for the actual timeout value. You really do NOT want clients retrying unless it knows for sure the packet was lost (which is rare, but can happen). Also, a timeout less than 100ms is usually not necessary.
Remember, this is TIMEOUT, NOT POLL RATE. Typically the POLL RATE is the FASTEST POSSIBLE rate (not actual rate), because a client typically will not start another comm when it has one pending. So you may want to change your poll rates back to FAST, just to see if the PLC CAN keep up with the new TIMEOUT value.