Communication fails when more clients or points are added

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

  1. Close unused test clients and browser sessions. Read one known-good point from one client and record response time/error counts.
  2. Add requests gradually. Several TCP clients share the serial bus; Ethernet speed does not remove RTU response times.
  3. 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.
  4. Group only supported contiguous registers and respect the field device's smaller block limits and complete-value requirements.
  5. 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.
  6. 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.