Communication fails when more clients or points are added
Establish a one-client baseline, then separate serial load from connection and memory limits.
Reduce to a measurable baseline
- Close unused test clients and browser sessions. Read one known-good point from one client and record response time/error counts.
- Add requests gradually. Several TCP clients share the serial bus; Ethernet speed does not remove RTU response times.
- Check polling intervals, retry counts, serial timeouts, and requests to missing devices. A client timeout that triggers retries before the previous request completes can increase congestion.
- Group only supported contiguous registers and respect the field device's smaller block limits and complete-value requirements.
- Check available device resource/status information and the installed release's connection limits. Limits can be shared across services rather than allocated separately to each port.
- If appropriate to the required data age, examine register caching. It can reduce repeated bus reads, but it changes freshness and does not fix a bad register definition.
Wi-Fi, TLS, browser sessions, and protocol services share device resources. Do not use a universal “points lost per feature” number as a capacity guarantee.
Expected result
The required client/point set runs with acceptable response time, freshness, and error rate. Record the smallest configuration that fails, active services, versions, polling/retry settings, and observed resource/connection messages for support.
