Isolate the failed part

1. Confirm the gateway port and Unit ID. Use a documented read-only point from the exact field-device map. Start with one client, one request at a time, and the point's complete register width.
2. Confirm normal TCP → RTU operation. Exit commissioning before testing the production gateway; commissioning reserves the serial ports.
3. Open Diagnostics on the affected SB1000 and enable the bus log. Look for the request on the intended RS485 port. Account for an enabled register cache, which can answer a recent read without new bus traffic.
4. If no request appears, verify the listener/mode and client protocol. Modbus TCP, raw serial-over-TCP, and RFC2217 are not interchangeable. Confirm logging was enabled during the request.
5. If the request appears but no reply does, check the field device's power, Unit ID, baud/parity/data/stop settings, wiring, and any other bus master. Test an isolated device during an appropriate maintenance window if necessary.
6. If a corrupted reply appears, investigate serial settings, noise, termination/reference, or collisions. A longer timeout alone does not repair corrupted data.
7. If a valid reply appears, compare its address/function with the request and review the client's timeout and driver settings. The client must allow for serial response time and queueing under the intended load.

SB1000's configured failure action can leave the client to time out or generate an exception. The message seen in the BMS is therefore only part of the evidence.

Expected result

The same single request produces a valid response and a correct value in the external client. If it still fails, provide the request, diagnostic TX/RX, client error, actual service/Unit ID, serial settings, and both device versions.