The View menu in QModMaster does not change what your device sends — it changes how the same raw bytes are interpreted and displayed. Pick the wrong format and a perfectly healthy reading looks broken; pick the right one and half of all “wrong value” mysteries solve themselves. This page is the hub: what each format means, when to use it, and the exact switching sequence to run when a reading looks wrong.

What the formats actually do

Every Modbus register is 16 bits. The View menu decides how those bits (and groups of them) are decoded for display:

• Hex (16-bit): shows each register exactly as it arrived, e.g. 0x04D2. This is the ground truth — no interpretation, no surprises. Always start here when something looks wrong.
• Binary (16-bit): the same bits as 0s and 1s. Useful when you are debugging individual status flags / bit fields packed into one register.
• INT16 / signed 16-bit: interprets one register as −32,768…32,767. Right for counters and small signed quantities — wrong for anything that exceeds 32,767 (it will flip negative).
• UINT16 / unsigned 16-bit: interprets one register as 0…65,535. Right for raw ADC counts, status words, and protocol fields.
• INT32 / UINT32 (32-bit): combines two consecutive registers into one 32-bit integer. Right for energy totals and large counters — but sensitive to word order (ABCD vs CDAB).
• Float (32-bit): combines two consecutive registers and decodes them as an IEEE-754 floating-point number. Right for voltages, temperatures, and power with decimals — but sensitive to byte order (four possible orders).

Which format, when: the cheat sheet

• Debugging anything and unsure → Hex. Read raw first, interpret second.
• Status flags, alarms, bit-packed coil images → Binary or Hex.
• Small counters, setpoints, temperatures as integers → INT16/UINT16.
• Energy totals (kWh), large counters → INT32/UINT32, then check word order.
• Voltage, current, power, temperature with decimals → Float, then check byte order.

The “reading looks wrong” switching drill

Run this sequence top to bottom. Stop at the first step that explains the value — most cases resolve at step 2 or 3.

• Step 1 — Hex. Switch to Hex and read the raw register(s). If the raw words already look wrong (all 0xFFFF, all zeros, unchanging), the problem is upstream: wiring, address, or slave — not the format.
• Step 2 — match the documented type. Check the device’s register map: does it say this address is INT16, UINT32, or Float? Set the View format to match exactly. A UINT32 read as INT32 flips negative past 2,147,483,647; a Float read as INT32 is garbage.
• Step 3 — test word/byte order. If a 32-bit integer is ~65,536× off, the words are swapped → word-swap fix. If a float shows astronomical values, try the other byte orders → float byte-order fix.
• Step 4 — apply scale and offset. If the value is off by 10×/100×/1000× or a round constant, it is scaling or an offset → scale factor & offset guide.
• Step 5 — verify the address. If the value is plausible but belongs to a different measurement, you are reading the wrong register: check 0-based vs 1-based addressing in your device’s manual.

Common mistakes

• Reading a Float register as INT32 (or vice versa) — the two decodings of the same bytes look nothing alike, and both look “broken.”
• Reading an unsigned quantity as signed INT16 — values over 32,767 wrap negative.
• Forgetting that 32-bit formats consume two registers — if you request only one register and display INT32, the second half is missing.
• “Fixing” the format when the real problem is the address — always confirm raw Hex values against the device’s own display first.

Deep dives

• Modbus Float Shows a Wrong Value? Byte-Order Fix — four byte orders, Schneider’s official guidance, QModMaster workflow.
• Modbus 32-bit Integer Wrong? Word Swap (CDAB) Fix — the 65,536× signature and the EM24 little-endian trap.
• Modbus Values Off by 10x? Scale Factor & Offset — the Deye temperature offset-1000 example and 60-second mental-math check.

FAQ

Does changing the View menu change what QModMaster requests from the device?

No. The View menu only changes how received bytes are decoded for display. The Modbus request (function code, address, register count) is unaffected.

Which View format should I start with when debugging?

Hex. It shows the raw register contents with zero interpretation, so you can tell whether the problem is the data on the wire or merely how it is decoded.

Why does my float show a huge wrong number in QModMaster?

Almost always a byte-order mismatch: the device sends the four bytes in a different order than the Float decoder expects. See the float byte-order fix for the four orders and how to identify yours.

Related Guides

• Modbus Float Shows a Wrong Value? Byte-Order Fix
• Modbus 32-bit Integer Wrong? Word Swap (CDAB) Fix
• Modbus Values Off by 10x? Scale Factor & Offset
• Download QModMaster — free, open-source (LGPLv3) Modbus master.

Learning Modbus data encoding properly pays off on every device you touch: recommended Modbus protocol book.

They sound like the same thing — and that is exactly why this confuses everyone. Modbus TCP and RTU over TCP both travel over a TCP/IP network, but the bytes on the wire are different protocols. Mixing them up is one of the most common reasons QModMaster connects to a gateway yet reads nothing but timeouts.

The core difference in one paragraph

Modbus TCP wraps the request in a 7-byte MBAP header (transaction ID, protocol ID, length, unit ID) and drops the RTU CRC, because TCP already guarantees delivery. RTU over TCP takes a complete, untouched RTU frame — address, function, data, plus its 2-byte CRC — and simply stuffs it inside a TCP connection as the transport pipe. No MBAP header, no transaction ID. Same network cable, different envelope.

Side-by-side: what’s on the wire

• Modbus TCP frame: [MBAP: transaction ID (2B) | protocol ID (2B) | length (2B) | unit ID (1B)] + [function code + data] — no CRC.
• RTU-over-TCP frame: [slave address (1B) | function code + data | CRC16 (2B)] inside TCP — no MBAP, byte-identical to what would travel over an RS-485 cable.

Practical consequences:

• In Modbus TCP, the transaction ID lets the master pair each response with its request — responses can even arrive out of order. RTU over TCP has no such mechanism; it behaves like a serial line (one request, one response, in order).
• In Modbus TCP, the unit ID byte in the MBAP header is what lets a TCP gateway route your request to one of several RTU slaves behind it. In RTU over TCP, the slave address lives in the first byte of the raw RTU frame itself.
• A device expecting Modbus TCP that receives a raw RTU frame (or vice versa) will simply ignore it — you get timeouts, not error messages. This is the signature symptom of a protocol mismatch.

When do you actually meet RTU over TCP?

You meet it at transparent gateways (also called serial servers or “transparent transmission” mode). These devices do not translate protocols at all — they take whatever bytes arrive on the RS-485 side and forward them raw over TCP, and back again. The widely used Waveshare serial gateways, for example, document two modes: a ModbusTCP conversion mode on port 502 (the gateway translates between Modbus TCP and RTU) and a transparent mode (raw RTU frames over TCP, commonly on port 8899). If your gateway is in transparent mode, the master software must speak RTU over TCP — plain Modbus TCP will not work, and vice versa.

Other places RTU over TCP shows up: Home Assistant’s rtuovertcp connection type for transparent bridges, USB-over-network serial servers, and TCP multiplexers that forward a serial port to several clients.

Which mode do you pick in QModMaster?

Here is the honest part: QModMaster only offers two modes — RTU (serial port) and TCP (Modbus TCP). There is no dedicated “RTU over TCP” option. What to do depends on your gateway:

• Gateway has a ModbusTCP conversion mode (e.g. Waveshare port 502): switch the gateway to that mode and use QModMaster’s TCP mode. The gateway translates MBAP ↔ RTU for you. This is the path of least resistance and what we recommend for debugging.
• Gateway is locked in transparent mode (raw RTU over TCP): QModMaster’s TCP mode will not work — it sends MBAP frames the transparent gateway forwards verbatim to a slave that expects a CRC-terminated RTU frame. Either reconfigure the gateway to conversion mode, or use a tool with explicit RTU-over-TCP support for that hop.
• Direct RS-485 via USB adapter: use QModMaster’s RTU mode — the frames are RTU either way, so there is no mismatch to worry about.

For the full walkthrough of the transparent-gateway scenario — including why QModMaster’s TCP mode times out against port 8899-style transparent servers — see QModMaster RTU over TCP Explained.

Quick diagnosis checklist

• TCP connects fine, but every read times out → suspect a Modbus TCP vs RTU-over-TCP mismatch. Check which mode your gateway port expects.
• Reads work through the gateway from one tool but not QModMaster → compare which protocol variant each tool sends (Wireshark with the modbus filter makes this visible in seconds).
• Multiple slaves behind one TCP gateway, only the first responds → check the unit ID handling; see our gateway guide linked below.

FAQ

Is RTU over TCP the same as Modbus TCP?

No. Modbus TCP uses a 7-byte MBAP header (with transaction ID and unit ID) and no CRC. RTU over TCP sends a complete RTU frame — including its CRC16 — inside a TCP connection, with no MBAP header. A device expecting one will ignore the other.

Does QModMaster support RTU over TCP?

Not as a dedicated mode — QModMaster offers RTU (serial) and TCP (Modbus TCP). If your gateway runs in transparent mode (raw RTU over TCP), switch the gateway to its ModbusTCP conversion mode (often port 502) and use QModMaster’s TCP mode, or use a tool with explicit RTU-over-TCP support.

Why does my transparent gateway time out with QModMaster’s TCP mode?

Because the gateway forwards QModMaster’s MBAP frames verbatim to the RS-485 slave, which expects a CRC-terminated RTU frame and silently discards the MBAP bytes. The signature symptom is a clean TCP connection with 100% read timeouts.

Related Guides

• QModMaster RTU over TCP Explained — the transparent-gateway scenario in depth.
• Download QModMaster — free, open-source (LGPLv3) Modbus master.
• Modbus TCP Wireshark Capture Analysis — see the MBAP header vs raw RTU bytes for yourself.

You opened QModMaster’s connection settings, looking for “RTU over TCP” — and found only two choices: Modbus RTU and Modbus TCP. It is not a missing feature or a bug. QModMaster simply has no RTU-over-TCP mode, and understanding why will save you a long afternoon of failed connections.

The confusion usually starts at the network gateway. Many RS485-to-Ethernet gateways (Waveshare, Elfin, and similar) can move Modbus over the network in two completely different ways — and only one of them is “Modbus TCP”. This page maps all three frame formats, shows which QModMaster mode matches each, and gives you honest workarounds for the case QModMaster cannot cover natively.

The Three Ways Modbus Frames Travel

Modbus defines the application message (function code + data). How that message is packaged on the wire differs between the three transports you will meet in the field:

Notice the key difference: Modbus TCP wraps the payload in an MBAP header (transaction ID, protocol ID, length, unit ID). RTU-over-TCP keeps the original serial frame — including its 2-byte CRC — and just carries it inside TCP packets. A device expecting one format will not understand the other.

What QModMaster Actually Offers

QModMaster — the free, open-source (LGPLv3) Modbus master simulator from the upstream project — ships with exactly two connection types:

• Modbus RTU — talks to a serial port (real or USB-to-serial).
• Modbus TCP — talks Modbus TCP with an MBAP header, default port 502.

There is no “RTU over TCP” option in the connection dialog, and the upstream project has never added one. This is not unique to QModMaster: the split is a framing choice every Modbus tool makes. For example, open-source Home Assistant integrations commonly expose both options explicitly — one project’s README notes “if you instead run the gateway in transparent mode (raw RTU over TCP, usually port 8899), set protocol: rtu_over_tcp“, while another documents framing as “rtuovertcp for transparent bridges, tcp for gateways doing MBAP ⇄ RTU conversion” (Solis-Local, ha-toshiba-modbus). QModMaster simply only implements the two mainstream choices.

The Real Source of Confusion: Your Gateway’s Two Modes

Serial-to-Ethernet gateways typically run in one of two modes, and the names vary by vendor:

So the fix is usually not in QModMaster at all — it is one checkbox in the gateway’s web configuration. If your gateway is in conversion mode, just pick Modbus TCP in QModMaster and point it at the gateway’s IP, port 502. If it is stuck in transparent mode on 8899, read on.

Workarounds When the Gateway Is in Transparent Mode

QModMaster cannot speak raw RTU-over-TCP, so you have two honest options:

Do not try the tempting shortcut of pointing QModMaster’s Modbus TCP mode at port 8899 in transparent mode: QModMaster will send MBAP-wrapped requests, the device behind the gateway will see garbage, and you will get timeouts — not useful error messages.

Spotting the Difference in QModMaster’s Bus Monitor

If you are unsure which format is on the wire, open QModMaster’s Bus Monitor and look at the raw bytes:

• Modbus TCP frames start with a 7-byte MBAP header: 2 bytes transaction ID, 2 bytes protocol ID (always 00 00), 2 bytes length, 1 byte unit ID — followed by the function code and data, with no CRC at the end.
• RTU frames start with the slave address byte and end with a 2-byte CRC — no MBAP header anywhere.

A read-holding-registers request to unit 1 for 2 registers starting at 0 shows the contrast clearly: over Modbus TCP you will see something like 00 01 00 00 00 06 01 03 00 00 00 02 (MBAP + PDU); over RTU-over-TCP the same logical request arrives as 01 03 00 00 00 02 C4 0B (address + PDU + CRC). See our Bus Monitor guide for a full walkthrough of reading these captures.

Related Guides

• Modbus RTU/TCP Gateway Setup Guide
• What Is a Modbus Master?
• Registers Returned Don’t Match? Fix It
• QModMaster Bus Monitor Guide

If your Home Assistant Modbus integration shows “unavailable” sensors, stop editing YAML for a minute. Prove the physical link works first with QModMaster — a free, open-source (LGPLv3) Modbus master simulator from the upstream project. This “verify with QModMaster first” workflow is exactly what IXON’s official support documentation recommends before configuring Modbus variables in IXON Cloud, and the same trick shows up in Home Assistant integration troubleshooting guides — for example the Sungrow SHx inverter integration’s help page tells users to check the connection with QModMaster before touching the integration config.

The Idea in One Paragraph

QModMaster talks to your device directly — no YAML, no integration layers, no polling engines. If QModMaster can read a register, your wiring, serial parameters, and device settings are correct, and whatever is broken lives in your Home Assistant configuration. If QModMaster can’t read either, the problem is below Home Assistant entirely: wiring, baud rate, parity, termination, or the wrong IP/port on a gateway. One test splits your debugging space in half.

Why Vendors Recommend This

IXON (official support documentation). Their Modbus troubleshooting article states: “Before configuring Modbus variables in IXON Cloud, it is best to determine if the variables can be read out by a Modbus master simulator tool.” It also warns: “Reading out the addresses should not give an error. If it does, make sure to resolve this before configuring the Modbus variables in IXON Cloud.” QModMaster is one of the two tools they name, and their walkthrough uses it step by step — Options > Modbus TCP, IP address and port, Unit ID (which IXON calls “Slave ID”), Connect, Function Code, Start Address, Scan. Read the IXON article.

Sungrow SHx Home Assistant integration. Its troubleshooting help page, Check #3: “If you are using Windows you can check if the Modbus connection generally works using QModMaster” — mapping Slave IP, TCP port, and Unit ID straight onto the values the integration needs. Read the help page.

The 4-Step Workflow

• 1. Connect in QModMaster. Options → Modbus TCP: enter the device or gateway IP and port (usually 502). For a direct serial adapter, Options → Modbus RTU instead (COM port, baud, parity, stop bits). Set the Unit ID — note that IXON’s docs call this field “Slave ID”; it is the same thing. Press Connect.
• 2. Read one known register. Set the Function Code (Read Input Registers 0x04 or Read Holding Registers 0x03 — your device manual decides), a Start Address you know exists, and Number of Registers = 1–4 to start. Press Scan. Values back = the link is good.
• 3. Write down the exact working parameters. Every field that made the read succeed: connection type, IP/port or COM settings, Unit ID, function code, start address, register count. These numbers are now proven facts, not guesses.
• 4. Carry them into Home Assistant verbatim. Use the mapping table below — translate each QModMaster field to its HA key and you remove an entire class of config errors.

QModMaster Field → Home Assistant Config Mapping

The golden rule: the Start Address and Function Code that returned real data in QModMaster are the numbers you put in HA. Don’t “correct” for 1-based vs 0-based conventions afterwards — you already resolved that empirically the moment the Scan succeeded. Fill the table from your verified QModMaster values, not from memory.

Three Traps When QModMaster Works but HA Doesn’t

• Slave / Unit ID mismatch. QModMaster’s Unit ID field and HA’s slave: key must hold the same number. It is the single most common YAML mistake, and QModMaster proves the correct value in seconds — check this first.
• Wrong input_type. FC04 reads need input_type: input; FC03 needs input_type: holding. Mix them up and you get errors or nonsense values from a link that is actually fine.
• Too-aggressive polling. HA hammers the bus with retries and tight scan intervals; some inverters and gateways simply stop answering. If QModMaster reads fine but HA logs “No response received after N retries”, loosen scan_interval, raise the timeout, and read fewer registers per request.

FAQ

Why not debug directly in Home Assistant?

HA’s Modbus integration gives you one error for ten possible causes. QModMaster isolates the hardware link from the YAML config in minutes — that is the whole point of the workflow vendors recommend.

Do I need QModMaster on the same machine as Home Assistant?

No — but test from the same network path. If HA reaches the device through a TCP gateway, point QModMaster at that same gateway IP so you validate the real path, not a different one.

Which function code should I use?

Your device manual decides. Most inverters and energy meters expose live values as Input Registers (FC04) and settings as Holding Registers (FC03). When in doubt, try reading both in QModMaster and see which returns sane data.

An address worked in QModMaster but HA reads the wrong value.

You almost certainly miscopied something in translation. Re-check the mapping table: same Unit ID, same Start Address number, FC04 → input_type: input, FC03 → input_type: holding, and the right data_type for the value width.

Related Guides

• QModMaster Tutorial: First Connection Step by Step
• Modbus No Response / Timeout: Fix Guide
• Read Your Growatt Inverter with QModMaster (First Read)
• USB-to-RS485 Adapter Buying Guide
• QModMaster Bus Monitor Guide

QModMaster’s Bus Monitor shows you every frame your PC sends and receives — and that is enough for most day-to-day debugging. But sometimes the problem is not in your PC at all: it is on the wire, in a switch, in a gateway, or in a second master fighting you for the same device. That is when you graduate from the Bus Monitor to Wireshark.

Think of it this way: the Bus Monitor sees what your machine sent and got back. Wireshark sees everything that crosses the network interface — TCP handshakes, retransmissions, RST packets, and traffic from other masters you did not know were polling. This guide walks you through capturing and reading Modbus TCP in Wireshark, and the exact workflow for pairing it with QModMaster.

1. Capture Setup: Grab Modbus TCP Traffic

• Pick the right interface. Open Wireshark and select the network interface that is actually connected to your Modbus network (the Ethernet NIC facing the plant LAN, not a VPN or loopback adapter). If your PC has several, check which one carries the device’s subnet.
• Set a capture filter. In the capture options, enter tcp port 502 before you start. This tells Wireshark to record only Modbus TCP traffic, which keeps capture files small and analysis fast on a busy network.
• Capture at the master. The simplest and most useful capture point is the PC running QModMaster — you get the full picture of what the master sees.
• Let it run a full poll cycle. Start the capture, run your QModMaster poll for at least one full cycle (typically 5–30 seconds), then stop and save the file.
• Non-standard ports. Wireshark only auto-decodes Modbus on port 502. If your device uses a custom port (e.g. 1502 or 8502), the packets will show as raw TCP. Fix it with Decode As…: right-click a packet → Decode As → set the TCP port value → choose MBTCP. From then on, everything on that port decodes as Modbus.

2. The Display Filters You Will Actually Use

Type these into Wireshark’s display filter bar. They are verified against Wireshark’s official display filter reference:

Combine them when you need precision: modbus.func_code==3 && mbtcp.unit_id==5 shows only FC03 traffic to unit 5. And modbus && ip.addr==192.168.1.100 isolates one device on a noisy network.

3. Pair Requests and Responses by MBAP Transaction ID

Every Modbus TCP frame starts with a 7-byte MBAP header, and its first field is the Transaction Identifier. The master assigns a transaction ID to each request; the slave echoes the same ID back in its response. In Wireshark’s packet list you will see pairs like:

This pairing is your single most powerful diagnostic tool:

• A Query with no matching Response = the request reached the wire but nothing came back. Check the TCP layer: did you get a SYN-ACK? If yes, the device accepted TCP but its Modbus service never answered. If you see a TCP RST instead, the device (or a firewall) actively refused.
• A Response whose transaction ID matches an older Query = delayed or out-of-order delivery. Sort the packet list by transaction ID and the misalignment jumps out immediately.
• Two Queries in a row before any Response = the master fired the next request too early (overlapping requests), which can desync response matching.
• Response arrives hundreds of milliseconds late = the device is slow or overloaded. Add a delta-time column (frame.time_delta) and filter modbus && frame.time_delta > 0.5 to find every slow response in one pass.

4. Spot Exception Frames (Function Code + 0x80)

When a slave cannot fulfill a request, it answers with an exception frame: the function code comes back with 0x80 added (so FC03 becomes 0x83), followed by a one-byte exception code. In the Wireshark packet list these stand out immediately, and the filter modbus.func_code>=128 isolates them. The most common exception you will meet is code 02 (Illegal Data Address) — it almost always means the requested register does not exist on the device, typically an off-by-one in your address mapping. For a full breakdown of all exception codes, see our exception codes guide.

5. The Practical Workflow: QModMaster + Wireshark Together

• Step 1 — Reproduce in QModMaster. Set up the failing poll exactly as it happens in production: same slave ID, same function code, same registers. Confirm the symptom (timeout, wrong values, exception).
• Step 2 — Capture in Wireshark. Start a capture with tcp port 502 on the right interface, run the failing poll once, stop the capture.
• Step 3 — Cross-check against the Bus Monitor. Open QModMaster’s Bus Monitor side by side. Do the raw frames match what Wireshark captured? If the Bus Monitor shows a response that Wireshark does not, something between the socket and the capture layer is off — rare, but this comparison is how you prove it either way.
• Step 4 — Pinpoint with filters. Now work the capture: pair transaction IDs, hunt exception frames, measure response times, look for retransmissions (tcp.analysis.retransmission && tcp.port==502) and resets (tcp.flags.reset==1 && tcp.port==502). Each pattern points at a different cause — network loss, a dead Modbus service, a competing master, or a slow device.

One honest boundary: everything above covers Modbus TCP, where Wireshark is free and excellent. If your problem is on the serial RTU side, Wireshark cannot see it — there are no packets on a serial line. For that, step up to a hardware logic analyzer that captures the actual RS-485 waveforms:

Frequently Asked Questions

Related Guides

• QModMaster Bus Monitor Guide (start simple, then come back here)
• Modbus Exception Codes Explained
• Modbus No Response / Timeout Fix
• Registers Returned Don’t Match the Device Display

When you configure a Siemens S7-1200 or S7-1500 as a Modbus TCP server, QModMaster is a fast way to verify the setup: connect as a Modbus TCP client, read a few holding registers, and confirm the PLC is really serving data. This guide covers the QModMaster side plus the setup pointers and verification steps — for the TIA Portal configuration itself, follow Siemens’ official documentation for your firmware version, since dialog layouts differ between versions.

PLC Side: Enable the Modbus TCP Server

S7-1200/1500 PLCs support Modbus TCP server functionality through Siemens’ Modbus instructions in TIA Portal. The general flow is:

1. Add the Modbus TCP server instruction to your program per Siemens’ documentation for your firmware version.
2. Assign it a data block / memory area to serve as the holding-register map.
3. Download the program to the PLC and put the CPU in RUN.
4. Note the PLC’s IP address (e.g. 192.168.1.10) — you’ll need it below.

Because Siemens changes instruction parameters and dialog details between TIA Portal versions, we deliberately don’t reproduce screenshots here — use the current Siemens documentation as the reference, and treat QModMaster as the test client below.

QModMaster Side: Connect as Modbus TCP Client

1. In QModMaster, select the TCP mode.
2. Enter the PLC’s IP address and port 502 (the standard Modbus TCP port).
3. Set Function Code to 03: Read Holding Registers, Start Address 0, Number of Points 10.
4. Click connect/read — you should see the values of the data block you assigned on the PLC side.
5. Change a value in the PLC (e.g. in a watch table) and re-read: the QModMaster grid should reflect the change. That confirms the full chain.

Unit ID (Slave ID) with Siemens

Modbus TCP includes a Unit Identifier field that plays the role of the Slave ID. Most Siemens Modbus TCP server implementations accept Unit ID 1 (or 255 for “this unit” in some stacks). If reads fail while the connection itself succeeds, try Unit ID 1 first, then check Siemens’ documentation for your instruction’s expected unit identifier.

Troubleshooting

Connection refused / timeout

Check: is the PLC’s CPU in RUN? Is your PC on the same subnet as the PLC (e.g. 192.168.1.x)? Is a firewall on your PC blocking outbound TCP 502 or the PLC’s port? Windows Firewall is a frequent culprit — allow QModMaster through it.

Connects but no data / exception 02

The server is running but you asked for registers it doesn’t serve. Confirm which data block area the Modbus server instruction is mapped to, and that your Start Address falls inside it. See our address offset guide and exception codes guide.

Frequently Asked Questions

Does QModMaster work as a Modbus TCP client for any PLC brand?

Yes — Modbus TCP is a standard protocol. QModMaster connects to any Modbus TCP server (Siemens, Allen-Bradley, Schneider, etc.) as long as you know the device’s IP, port 502, and which registers it serves.

Which Siemens PLCs support Modbus TCP server mode?

S7-1200 and S7-1500 support it via the Modbus TCP instructions in TIA Portal. Check Siemens’ documentation for your exact CPU and firmware, since instruction availability and parameters vary by version.

Do I need to write to the PLC from QModMaster?

For a basic connectivity test, no — an FC03 read proves the server works. If you want to test writes too, use FC06/FC16 against registers your PLC program explicitly exposes for that purpose, and be aware of what the PLC does with those values.

Can QModMaster scan the PLC automatically?

Yes — QModMaster’s Scan feature polls a register range repeatedly, which is handy for watching PLC values change in real time. See the user manual for scan setup.

Related Guides

• How to Read Holding Registers (FC03): Step-by-Step
• Modbus Function Codes Explained
• Modbus No-Response Timeout Fix
• Download QModMaster

A variable frequency drive (VFD) usually speaks Modbus RTU out of the box, which makes it one of the most common devices QModMaster users debug. This guide shows how to connect a VFD to QModMaster, read its status word, and write a frequency reference — the standard first test when commissioning or troubleshooting a drive.

Important: every VFD brand uses its own Modbus register map. All register addresses below are examples only — check your drive’s manual for the real status-word and frequency-reference registers. Never write to a register unless your manual confirms what it does; writing the wrong address can change drive behavior.

Step 1: Configure the Drive as a Modbus Slave

Before QModMaster can talk to the drive, set these parameters on the VFD itself (usually via its keypad or config software):

• Modbus slave address — pick a free address on the bus (commonly 1) and note it down.
• Baud rate — 9600 is the typical default; confirm against your drive.
• Data format — commonly 8N1 or 8E1; must match on both ends.
• Enable Modbus control source — many drives ignore Modbus commands until you switch the control/reference source to the communication port.

The exact parameter numbers differ per brand — your drive’s manual is the only authority here.

Step 2: Connect in QModMaster

Wiring: connect your USB-to-RS485 adapter’s A/B terminals to the drive’s RS485 terminals (mind polarity). Need an adapter? See our USB-to-RS485 adapter buying guide (adapter deals).

1. In QModMaster, select Serial (RTU) and your adapter’s COM port.
2. Set baud rate, parity and stop bits to match the drive (e.g. 9600 / None / 1 — verify against your drive).
3. Set Slave ID to the address you configured on the drive.
4. If replies are garbled, try toggling RTS control (RTS control guide).

Step 3: Read the Status Word (FC03)

Most drives expose a status word register (running/stopped, faulted, direction) that you read with function code 03:

1. Set Function Code to 03: Read Holding Registers.
2. Set Start Address to your drive’s status-word address (example only — check your drive’s manual) and Number of Points to 1.
3. Read the value and decode the bits using your drive’s manual (e.g. bit 0 = ready, bit 2 = running).

If the read returns exception 02, you’re asking for an address the drive doesn’t have — re-check the manual and the address offset guide.

Step 4: Write the Frequency Reference (FC06)

Once status reads work, the classic next test is commanding a frequency:

1. Set Function Code to 06: Write Single Register.
2. Set Start Address to your drive’s frequency-reference register (example only — check your drive’s manual).
3. Enter the value in the drive’s units (many drives use 0.01 Hz steps, so 2500 = 25.00 Hz — confirm in the manual).
4. Verify with another FC03 read of the status word or output frequency register.

Frequently Asked Questions

What register address is the status word on my VFD?

There is no universal answer — every brand and series uses different addresses. This is why the examples above are marked “example only.” The status-word address is in your drive’s Modbus/communication appendix.

The drive reads fine but won’t accept writes — why?

Most drives have a “control source” or “command source” parameter that defaults to the keypad. Until you switch it to the Modbus/communication port, writes are ignored or rejected. This is the single most common cause.

Can I damage the drive by writing wrong registers?

Yes — writing an unknown register can change motor parameters or behavior. Only write to addresses your drive’s manual documents for the purpose you intend, and keep the motor unloaded during first tests.

Do I need a special cable for VFD Modbus?

You need an RS485 interface — a USB-to-RS485 adapter is the standard choice. Cheap unbranded adapters are a common source of flaky VFD connections; our buying guide covers what to look for.

Related Guides

• USB-to-RS485 Adapter Buying Guide
• How to Read Holding Registers (FC03): Step-by-Step
• Modbus No-Response Timeout Fix
• Download QModMaster

Function codes are the “verbs” of Modbus: they tell the slave what to do. QModMaster supports the eight most-used ones. Here is what each does, when to use it, and where it shows up in QModMaster’s dialog.

Function Codes at a Glance

Where Function Codes Appear in QModMaster

In QModMaster’s main window, the Function Code dropdown lists these codes by number and name. Select the code, then set Slave ID, Start Address, and Number of Points (for reads) or the value to write (for writes). The Bus Monitor shows the function code of every request and response, so you can confirm the device answered the exact code you sent (Bus Monitor guide).

Frequently Asked Questions

What is the difference between FC03 and FC04?

FC03 reads holding registers (read/write, e.g. setpoints); FC04 reads input registers (read-only, e.g. sensor measurements). The data may look identical — the difference is whether the slave allows you to write to that address.

What is the difference between FC05 and FC15, or FC06 and FC16?

FC05/FC06 write a single coil/register; FC15/FC16 write a block of them in one request. Use the block codes when a value spans multiple registers (32-bit integers, floats) or when several outputs must change at the same time.

Does QModMaster support all Modbus function codes?

QModMaster supports the eight common codes: 01, 02, 03, 04, 05, 06, 15 and 16. These cover the vast majority of debugging and testing work with Modbus RTU and TCP slaves.

I sent FC03 but got an exception response — what does that mean?

The slave answered with an error code instead of data. The most common is 02 (Illegal Data Address — you asked for registers that don’t exist). See our exception codes guide for the full list and fixes.

Related Guides

• How to Read Holding Registers (FC03): Step-by-Step
• Modbus Exception Codes Explained
• Modbus Register Address Offset Guide
• Download QModMaster

Holding registers are the read/write data locations in a Modbus slave — setpoints, configuration values, measured values you need to check. Function code 03 (FC03) is how a Modbus master reads them. This guide walks you through reading holding registers in QModMaster, register by register.

What QModMaster Needs to Read Holding Registers

QModMaster acts as the Modbus master (client). Before you can read anything, four fields in the main window have to match your slave device:

• Slave ID — the Modbus address of your device (1–247). Must match the device’s configured address.
• Function Code — set to 03: Read Holding Registers.
• Start Address — the first register you want to read. QModMaster uses 0-based addressing, so a device manual that says “register 40001” is entered as 0 here.
• Number of Points — how many consecutive registers to read in one request.

If the physical link isn’t up yet (RTU serial port or TCP connection), see our no-response timeout fix guide first.

Step-by-Step: Read 10 Holding Registers

Here is the complete walkthrough. It assumes your connection already works and your slave ID is 1.

1. Select the interface. Serial (RTU) — choose the COM port, baud rate, parity, stop bits exactly as the device is configured. TCP — enter the device IP and port 502.
2. Set Slave ID to 1 (or your device’s Modbus address).
3. Set Function Code to 03: Read Holding Registers.
4. Set Start Address to 0. This reads device register 40001 (first holding register) in 1-based notation.
5. Set Number of Points to 10. QModMaster will request registers 0–9 (40001–40010 in 1-based notation).
6. Click Connect / read — the values appear in the result grid, one row per register.
7. Watch Bus Monitor if you want to see the actual request/response frames on the wire (Bus Monitor guide).

Interpreting the Values: Data Formats

Raw register values are 16-bit integers, but your device may be sending temperatures, floats, or bit fields. QModMaster lets you switch how the grid displays each value — hex, signed/unsigned int, float — so change the display format before assuming the data is wrong. A “weird” reading of 17223 might be a perfectly good value shown in the wrong format.

Troubleshooting: When the Read Fails

1. Values are shifted by one register

The most common FC03 issue. Device manuals usually number holding registers from 40001 (1-based), while QModMaster takes the 0-based offset. If your manual’s “40005” returns data for the wrong point, subtract 1: enter 4 in QModMaster. Full explanation in our register address offset guide.

2. Wrong Slave ID

No response at all — or a response to a different device on the bus — usually means the Slave ID field doesn’t match the device’s configured address. Double-check the device’s address setting (DIP switches, config menu, or manual).

3. Exception code 02 (Illegal Data Address)

The slave answered but refused the address — your Start Address / Number of Points range extends beyond the registers the device actually has. Shorten the range or move the start address. See our exception codes guide for the other codes you may see.

Frequently Asked Questions

Can I read holding registers while another program is using the port?

No — a serial port can only be opened by one program at a time on Windows. Close the other tool (or disconnect QModMaster) before retrying. On Linux, the same rule applies to the /dev/tty* device node.

Why do I get the same value in every register?

Often the device genuinely mirrors one value across a range, but first check the display format: a value shown in the wrong format can look “stuck.” Re-read with a different format selected before concluding the device is misbehaving.

How many registers can I read in one FC03 request?

Modbus limits an FC03 request to 125 registers. In practice, keep reads short (10–50) while debugging — large reads multiply the chance of crossing into an unmapped address and getting exception 02.

Related Guides

• Modbus Register Address Offset Guide
• Modbus Exception Codes Explained
• QModMaster Tutorial
• Download QModMaster

When Modbus misbehaves, opinions don’t help — bytes do. QModMaster’s bus monitor shows every byte sent and received in raw hex, timestamped. Learn to read it and you can distinguish “my request never left the PC” from “the device answered but the frame was corrupt” from “the device refused on purpose” in seconds. (QModMaster is free, open-source, LGPLv3 — upstream is the upstream SourceForge project.)

Opening the bus monitor

The Bus Monitor panel is docked in the main window — usually along the bottom. If it’s hidden, re-enable it from the View menu. Each line shows the direction (TX/RX), a timestamp, and the raw hex bytes of the frame.

Anatomy of a Modbus RTU frame

Here is a complete, real request — read 10 holding registers starting at protocol address 0 from slave 1 (illustrative example):

01 03 00 00 00 0A C5 CD

And a matching response carrying ten registers with values 100–1000:

01 03 14 00 64 00 C8 01 2C 01 90 01 F4 02 58 02 BC 03 20 03 84 03 E8 DB 70

Note the request is 8 bytes and the response is 25 — the request carries only an address and a count, while the response carries the actual data.

Three debugging patterns

Pattern 1 — Request goes out, nothing comes back

You see the TX line in the monitor but no RX. The PC side works; the fault is downstream: wiring, slave ID, baud rate, or RTS timing. Work the no-response checklist.

Pattern 2 — Reply arrives but fails CRC

RX bytes appear and QModMaster flags a CRC error. The frame was corrupted in transit — noise, baud mismatch, missing termination. See the CRC error guide.

Pattern 3 — Reply is an exception

The response function code is the request code + 0x80 — e.g. 0x83 answering an FC 03 read — followed by one code byte. Example: request 01 03 00 64 00 01, exception reply 01 83 02 C0 F1 → code 02, illegal data address. Decode it with the exception code guide.

When the monitor isn’t enough

The bus monitor shows what QModMaster’s serial driver saw — but a USB logic analyzer shows what’s electrically on the wire. When the two disagree, the adapter or its driver is lying to you. Capturing both sides is the fastest way to settle “is it the PC or the bus”.

Frequently asked questions

Does the bus monitor show Modbus TCP traffic too?

Yes. For TCP each line shows the MBAP header (transaction ID, protocol ID, length) followed by the unit ID and the PDU. The request/response logic is identical — there is just no CRC field to decode.

Can I copy frames out of the monitor?

Yes — select the hex text and copy it. Pasting a suspect frame into a CRC calculator (or recomputing it by hand) is the fastest way to confirm whether corruption happened on the wire or in software.

Why is the response longer than the request?

The request only carries an address and a quantity (8 bytes in the example); the response carries every register value (25 bytes for ten registers). Longer responses are normal — truncated ones are not.

The monitor shows garbled or partial bytes. What now?

Garbled bytes almost always mean a baud-rate or framing mismatch — both sides must agree on baud, parity, data bits, and stop bits. Fix the serial settings first, then look at the CRC error guide if corruption persists.

Related Guides

• QModMaster ‘No Response’ Timeout: 9 Fixes — pattern 1: silence on the bus
• Modbus CRC Errors: Causes and Fixes — pattern 2: corrupted replies
• Modbus Exception Codes 01–04 Explained — pattern 3: the device refuses
• QModMaster Tutorial: Your First Poll in 10 Minutes — from install to live data
• Download QModMaster — free, open-source (LGPLv3), Windows and Linux