Connect a Modbus TCP system through SB1000
Choose the correct gateway port, build a valid request, decode the value, and verify polling and writes.
What this guide helps you do
Use this guide when a BMS, PLC, SCADA system, or another Modbus TCP client needs to read or write a Modbus RTU device connected to an SB1000 RS485 port. First establish one correct read. Then add more points, choose suitable polling, and test any required writes.
The communication path is: your Modbus TCP client → SB1000 IP address and TCP port → selected RS485 bus → field device.
Your client starts the requests. SB1000 forwards them between TCP and RTU. The field device defines which registers exist and what their contents mean. In this forwarding mode, SB1000 does not automatically convert the returned bytes into temperatures, energy totals, signed values, or floating-point values for your client.
Use separate guides for an RTU controller accessing a TCP server, MQTT, BACnet, or a virtual COM/raw TCP connection. They use different roles or protocols even when the same physical connectors are involved.
1. Collect the information for one point
Have the field device's register map for its exact model and firmware. Choose a documented read-only value that you can compare with a display or another reliable measurement. There is no universal test register that all downstream devices support.
Record these settings:
- SB1000 firmware version and the client software/driver version.
- SB1000 IP address and the network interface you will use.
- RS485 Port 1 or Port 2, its operating mode, and its configured TCP port.
- Field device's Modbus address, also called Unit ID, unit address, server ID, or slave address.
- Baud rate, parity, data bits, and stop bits used by the field device.
- Register table: coil, discrete input, holding register, or input register.
- Register number exactly as printed in the manual, and the manual's numbering convention.
- Actual zero-based address sent in the request, and the quantity of bits or 16-bit registers to read.
- Value type, signedness, width, byte/word order, scaling, offset, and engineering unit.
- Any special value that means unavailable, invalid, over-range, or not fitted.
Keeping these together prevents confusion between an IP address, a TCP port, a Unit ID, and a register address. They identify different parts of the same request.
2. Choose the correct SB1000 service
Open the affected SB1000's web interface and inspect the settings for the physical RS485 port connected to your equipment. Select TCP → RTU operation for this workflow and save the required settings. The exact visible mode label can differ between firmware versions.
The defaults in the standard SB1000 configuration are:
- RS485 Port 1 gateway: TCP port 4001.
- RS485 Port 2 gateway: TCP port 4002.
- SB1000 Modbus Management Interface: TCP port 502, when enabled. This is a separate interface for the SB1000's own settings.
Always use the currently configured port. These numbers can be changed. The factory configuration disables the serial-port modes and the management interface, so a default port number is not proof that a listener is running.
Do not use the management register table when you intend to read a meter or actuator connected to RS485. Use that field device's register map through its gateway port.
If your external client only supports port 502, first check which SB1000 service currently uses it. Configure the required gateway to use an available port accepted by your client and move or disable a conflicting management listener. Two listeners cannot occupy the same address and TCP port. Record the change for other users of the installation.
Port 1 and Port 2 are separate buses. Two devices can use the same Unit ID on different buses; the TCP endpoint distinguishes them. Two devices on the same bus must not share a normal unicast address.
The standard TCP service number is 502, and the Modbus TCP Unit Identifier is used to reach devices behind a gateway. SB1000's configured endpoint determines which service and bus you actually reach.
3. Establish network access from the actual client
Confirm that the BMS/PLC computer can reach the SB1000 on the intended network. A successful connection from your phone or laptop does not establish the same route from a controller on another VLAN.
Check the destination IP, subnet/routing, and any firewall rule for the actual TCP port. With a static IP, check for duplicate addresses. With DHCP, arrange a stable address appropriate to the installation and use the address the device currently reports.
Opening the web page proves that the web service is reachable from that browser. A Modbus connection is a separate connection and can still be disabled, blocked, or directed at the wrong port. Conversely, a failed ping alone does not prove that TCP is unavailable.
If a TCP connection is refused, check the listener's mode/port and client capacity. If it times out before connecting, also check the network path and filtering. Neither result tells you whether the field device's register address is correct yet.
4. Verify the RS485 side
Match the serial settings to the field device's documented configuration. Check that the field device is powered and that its address matches the Unit ID you will request.
Check the bus wiring against both manufacturers' documentation. A/B labels are not used consistently by all equipment vendors. Keep the differential pair together, use the intended bus topology with short branches, and follow the equipment's signal-reference and shield/grounding instructions. Review end termination and biasing as separate functions; do not enable termination at every device or add bias indiscriminately.
There must be a deliberate bus-owner arrangement. An existing RTU master and SB1000 must not independently transmit on the same bus without a supported architecture. If the commissioning scanner reports another active master, investigate that traffic before scanning.
On firmware with the relevant tools, use the SB1000 web interface to establish whether the field device responds and whether the chosen point can be read. Live scanning and the RS485 self-test run on the affected SB1000; reading an article in the native app does not run those tools.
Commissioning mode temporarily takes over the serial ports. After testing, exit commissioning, verify the normal gateway mode and line settings, and reconnect the external client. A successful scan at a different baud/parity does not automatically establish that normal operation uses the discovered settings.
5. Set the Unit ID
For a field device behind this gateway, enter its RTU address in the external client's Unit ID/slave address field. Normal Modbus RTU unicast addresses are 1–247. Use the configured address of your equipment, not a guess based on its physical position.
Do not substitute the SB1000 serial number, its IP address's last octet, the TCP port, or the register number. Do not copy advice about ignoring the Unit ID on a direct TCP device into a TCP-to-RTU gateway configuration.
Address 0 is a broadcast address, not a way to read all devices. Do not use it for a first read or an exploratory write. Broadcast writes can affect multiple devices and do not provide individual replies.
6. Translate the register map into a request
The function and address together identify the data. The same numerical offset can exist independently in several tables.
- Coils: normally read with FC01.
- Discrete inputs: normally read with FC02.
- Holding registers: read with FC03.
- Input registers: read with FC04.
The address carried in the request is zero-based. A manual or client may instead present a one-based number or a traditional reference that includes the table. For example, when the manual explicitly uses the conventional 4xxxx holding-register scheme, reference 40001 means FC03 at offset 0; 40011 means FC03 at offset 10. A one-based client may ask for register 11 for that same offset 10.
Use this example to check the convention, not to assume that your equipment has the same point:
- Manual says conventional holding register 40011.
- Raw zero-based client: choose holding registers and enter 10.
- One-based register-number client: choose holding registers and enter 11.
- Traditional-reference client: enter 40011 using the driver's documented method.
- The request itself must contain start address 10, which is hexadecimal 0x000A.
Do not subtract one or 40001 without knowing the source convention. A manual that already states “protocol address 10” has already supplied the offset. A literal address 40001 can also be a valid raw offset when a manufacturer explicitly defines it that way. Six-digit reference notation must likewise be interpreted according to the driver/manual, not by stripping the first digit mechanically.
Check decimal versus hexadecimal. Decimal 10 is 0x000A; hexadecimal 0x0010 is decimal 16.
The requested quantity is a number of bits for FC01/02 and 16-bit registers for FC03/04. It is not a byte count or a count of engineering values. One float32 occupies two registers; one 64-bit integer occupies four. Start at the first register of the value, and read its complete width together.
7. Prove one read before adding a point list
The following is an illustrative device map, not an SB1000 or universal meter register definition:
- SB1000 IP: 192.168.10.50, used here only as an example.
- Gateway: Port 1, configured TCP port 4001.
- Field device: Unit ID 7.
- Point: temperature at conventional holding register 40011.
- Encoding: signed 16-bit integer, scale 0.1, offset 0, unit °C.
- Expected live value for this example: 21.5 °C.
Configure the client for Modbus TCP, address 192.168.10.50, port 4001, Unit ID 7, FC03, zero-based offset 10, quantity 1. Start with one outstanding read and a modest interval, such as two seconds for this manual test. That interval is a troubleshooting starting point, not a production setting for every device.
The successful data word for the example is hex 0x00D7, decimal 215. Signed decoding gives 215, and 215 × 0.1 gives 21.5 °C.
If your client shows the raw TCP telegram, one example request is “00 01 00 00 00 06 07 03 00 0A 00 01”. A matching example response is “00 01 00 00 00 05 07 03 02 00 D7”. The transaction identifier may differ in a real client. These are Modbus TCP frames with an MBAP header; do not append an RTU CRC or send these bytes to a raw serial bridge as if it were the same service.
Compare the raw word and the engineering value separately. If the word is correct but the displayed temperature is wrong, investigate the client's decoding and scaling. If the request is rejected or no data returns, establish the communication problem first.
Validate at more than one operating value. A coincidentally plausible value at one moment is weak evidence that the address or encoding is correct.
8. Choose the correct value type
A register contains bits. Its label or the presence of a decimal point on the equipment display does not identify its encoding.
- uint16: one register, 0 to 65,535.
- int16: one register, −32,768 to 32,767.
- uint32 or int32: two registers. The signed form interprets the upper bit as part of a signed two's-complement value.
- float32: two registers containing an IEEE 754 floating-point encoding. Interpreting those bits as an integer gives a different number.
- uint64 or int64: four registers; confirm the receiving system preserves enough precision.
- A status/enum/bitfield: interpret the specified bits or states using the device's map. A nonzero status word is not necessarily a simple ON value.
For example, raw 0xFF9C is 65,436 as uint16 but −100 as int16. With scale 0.1, the intended signed value is −10.0; unsigned decoding would show 6,543.6. Changing the wiring or polling interval cannot fix this decoding error.
Do not automatically treat 0xFFFF, 0x8000, a negative number, or NaN as a sensor fault. The manufacturer may define a sentinel, an ordinary value, or a special state. Apply that definition before scaling and before reporting the point as good quality.
Some products use BCD, strings, dates, separate exponent registers, or modulo-10,000 encodings. Those require their documented interpretation. Choosing the nearest-looking standard integer type is insufficient.
Large counters deserve an additional check. A receiving system that converts all numbers to binary64 floating point cannot represent every integer above 2^53 exactly. Re-reading the same raw words will not restore precision lost during conversion. Keep an exact integer representation where the application requires it.
9. Check byte order and word order
For a multi-register value, determine how its bytes and words are arranged. Labels such as “big endian”, “little endian”, and “swap” are not consistently descriptive across different clients; match the actual byte sequence.
For a 32-bit example, call the most-significant byte A, then B, C, and the least-significant byte D. The possible arrangements commonly presented by tools are ABCD, CDAB, BADC, and DCBA. These correspond to no swap, exchanging the two 16-bit words, exchanging the two bytes in each word, and reversing all four bytes.
In the SB1000 point-decoding tools, the 32-bit labels map as follows:
- 3210: interpret wire bytes as ABCD.
- 1032: interpret wire bytes as CDAB.
- 2301: interpret wire bytes as BADC.
- 0123: interpret wire bytes as DCBA.
This mapping is specific to those SB1000 labels. Do not copy the digits into another application unless it defines them identically. The SB1000 helpers do not apply this 32-bit byte mapping to 16-bit values, and their 64-bit handling rearranges whole registers. A separate 64-bit example is needed for a particular field device.
For a worked float32 example, 23.5 is encoded as 0x41BC0000. A high-word-first device returns registers 0x41BC and 0x0000. A word-swapped device returns 0x0000 and 0x41BC. Both can represent 23.5 with the matching decoder.
Changing SB1000's commissioning display order changes how that tool interprets a reply. It does not change the raw gateway data or configure your external client. Set the external client's decoder separately.
10. Apply scale, offset, and units once
For a linear definition, engineering value = decoded raw value × scale + offset. Decode the data type and order before applying the scale.
Example: raw 215 with scale 0.1 and offset 0 is 21.5. Another point with raw 200, scale 0.1, and offset −10 is 10.0.
Confirm whether the documentation says “multiply by 0.1”, “divide by 10”, or supplies a separate exponent. Also check the engineering unit: 1,500 W is 1.5 kW, and power is not the same quantity as accumulated energy.
Apply each conversion once. A scaled value produced by a mapping or client driver may already be in engineering units. The transparent TCP → RTU path still carries the field device's register data; it does not apply your MQTT/BACnet point definition to that traffic.
For a linear writable point, the inverse is raw = (engineering value − offset) / scale. Use only the documented writable range and representable increments. Confirm the client's write API expects raw data or engineering units before entering a value.
11. Add points without overwhelming the bus
Add a few points at a time after the first verified read. Compare the request/response error counts and update timing before adding more load.
Group only compatible contiguous registers supported by the device. A larger read can fail when it crosses an unimplemented gap or a device-specific block boundary. Some devices require complete 32-bit pairs. The protocol's maximum FC03/04 read is 125 registers, but the attached device may accept fewer. A compliant maximum is not a promise about that device.
SB1000 serializes communication on a bus. Several clients, retries, and absent devices all consume time. Ethernet speed does not make the RS485 devices respond faster. As a simple planning example, 20 sequential requests averaging 50 ms each already occupy one second before extra delays or failed-device timeouts.
Use conservative polling and one outstanding request while troubleshooting. Set the external client's timeout to allow for serial response time, SB1000's configured timeout, and queueing under the intended load. A client that retries before SB1000 finishes a previous request can worsen congestion. An extremely long timeout will not fix a wrong address or disconnected bus.
Keep only the clients needed for the test. Firmware with this feature shares a small Modbus TCP client pool across its listeners, and other networking services also consume resources. Check the capacity guidance for the installed release before designing a multi-client system.
12. Understand cached and stale values
If register caching is enabled, repeated reads can receive a recent cached response without another request on the wire. Firmware with this feature defaults to cache off; when enabled, its default lifetime is 5 seconds, configurable from 1 to 60 seconds in the supported modes.
Use the register-cache diagnostics, where available, to examine age, hits, and misses. For a deliberate fresh test, the Diagnostics one-shot Modbus request bypasses the cache on firmware with this feature. Confirm a meaningful field change and compare the raw reply with the BMS display.
A successful TCP response does not prove a new field measurement was taken at that instant. The field device also has its own measurement update rate. Choose an acceptable age for each use and configure data-quality/staleness handling in the receiving system.
Do not assume every frozen value is a cache issue. Check whether the client is still polling, the bus is healthy, a device is being retried, or a displayed value is simply the last successful value.
13. Follow the observed failure
If TCP cannot connect, work on the IP path, destination port, enabled mode, and client capacity. Register decoding is not involved yet.
If TCP connects but no reply arrives, use Diagnostics to see whether a request was transmitted on the expected bus. No request suggests the wrong listener/mode, commissioning state, request framing, or a cached read. A transmitted request with no valid response points toward Unit ID, device power, line settings, wiring, another master, or device-specific timing.
If a Modbus exception returns, record the complete code and request. Exception 01 means the operation is unsupported; 02 points to the requested address/range; 03 points to invalid request data. Check the device's map and constraints. A CRC error is a different event from a valid Modbus exception.
For exception 04 or 06, also inspect SB1000's configured timeout/CRC action and its bus diagnostics. The gateway can synthesize those responses when a downstream transaction fails. A client timeout can also be intentional when the policy is to send no exception. Do not infer the original fault from the client message alone.
If a valid reply arrives with the wrong value, compare raw bytes first, then check start address, width, type, order, scaling, units, sentinel values, and freshness. Do not start by rewiring a bus that is delivering the expected raw value.
If a scan reports A/B swapped, correct the data-line wiring identified by the test and scan again with normal polarity. The optional inverted scan is experimental and cannot detect all crossed-wire cases. No warning is not proof that polarity is correct, and its temporary inversion is not a saved repair.
14. Test writes separately
Begin writes only after the read path is proven and the intended equipment action is understood. Use a documented, reversible test with the installation in a suitable state. Record the previous value and how to restore it.
Confirm the point is writable, the required function, the complete value width, any unlock/remote-control requirement, and the permissible value range. FC05 writes one coil, FC06 writes one holding register, and FC16 writes multiple holding registers; the field device decides which are supported. Holding-register placement alone does not guarantee writable access.
For a multi-register value, use the manufacturer's complete-value write method rather than two unrelated single-register writes. Apply the correct encoding and any inverse scaling.
After the write, read back the documented feedback or setpoint and check the actual device behavior. A protocol acknowledgement does not prove an actuator moved. A local override, another controller, an interlock, or an operating-mode requirement can prevent or replace the intended action. Some devices require a separate apply/save step; follow their documentation.
Do not use broadcast writes, random register probing, or repeated permanent-setting writes to discover what a point does.
15. Complete the handover
Verify the normal operating mode after commissioning and record one successful request and response. Confirm at least one negative or boundary value when signedness matters, and more than one live value when validating order/scaling.
Record the actual IP/service port, bus, Unit ID, map revision, function, raw start address, width, type/order, scale/unit, polling interval, timeout, and cache setting. Include the firmware and client/driver versions. Preserve an appropriate configuration backup and the point list; an NFC template is a different artifact with a narrower set of supported settings.
If help is still needed, provide the exact failed request, raw reply or error, time of failure, topology, serial settings, and the result of a single-point test through the SB1000 tools and the external client. Include the field-device model/map and SB1000 version. Remove credentials from screenshots, connection strings, and exported evidence.
