The two systems I'm having trouble with have gateways defined for both. I work across different subnets and have to have the gateway defined.
Well, I found a thing, not sure if it
the thing.
When we added the ECOMEX, it required enabling code that enabled some routing functions. For outbound packets this is required, but it went the extra mile for us and enabled an internal gateway function which was causing legit havoc in certain conditions. I don't know exactly what those conditions are, but the trigger is for something to send a subnet broadcast, mostly likely to a subnet not configured on either the PLC's NICs. I won't bore y'all with the details, but basically the gateway function commits a faux pas and improperly forwards a broadcast packet. By itself, that's no big deal...but if he tells everybody, and everybody else tells everybody, etc., it's geometric. The TTL in the packet eventually extinguishes the flames, but not before annoying the stack greatly. The immediately obvious symptom is brief comm dropouts and $QueuesFlushed (ST145) getting set.
We'll get a fix out shortly.
As I said, I don't know if this fixes the Modbus issue, but it may well do it. I don't think the stack enjoys being assaulted repeatedly, and after weeks or months of abuse it might have leaked enough resources to become non-responsive.
For reference, the thing that was generating the subnet broadcast was a Win7 PC doing a NETBIOS name resolution. It could be about anything though.
