How to Log Modbus Data: Traffic Capture, CSV Export, and Trending
"The value looks wrong" is where most Modbus debugging starts, and it is the least useful observation in the world. Was it misread? Scaled wrong? Never sent at all? You cannot know from one number on a screen. You need three layers of evidence: values over time, the actual requests and responses, and any exceptions the device returned. Here is a workflow that captures all three and ends with files you can attach to a ticket.
Capture the values, not just the snapshot
Set up your poll blocks over the registers you care about and let them run. A single reading tells you the state now; a stream of readings tells you the behavior. A sensor railing at full scale, a counter that wraps, a value that only dips under load: each is obvious in a trend and invisible in a snapshot. In Modbus Poll, mark registers to watch and the trend panel plots them live next to the table while the connection stays open.
Log the traffic: who asked, what answered
Values alone cannot separate a device fault from a client fault. The traffic log can. Every request frame and every response gets recorded with a timestamp: you see the poll rate you configured, the latency the device actually delivered, and any exception responses the device returned instead of data. When a value changes at 14:32:07, the traffic log tells you whether that was a real register write from someone else or your own read cycle arriving late.
Export to CSV: evidence that outlives the session
The traffic log exports as a timestamped CSV: one click, and you have a file that opens in any spreadsheet. TCP-level events export separately when you are debugging the connection layer. Two uses pay for themselves immediately:
- Vendor disputes. "Your meter returns garbage" gets a shrug. "Here is the request frame, here is the response, at this timestamp" gets an engineer. A CSV of raw transactions moves the conversation from opinions to bytes.
- Baselines. Before you change a working system, export what normal looks like. When the change gets blamed for a regression next month, you compare against the file instead of against memory.
Make the setup itself portable
A capture is only useful if it is repeatable. Modbus Poll's register blocks (addresses, names, data types, scaling) import and export as CSV, so the poll configuration you verified on site becomes a file you reload before the next visit. Pair it with the built-in device templates (Schneider PM5560, SMA inverter, Endress+Hauser flowmeter, ABB analyzer) and a return trip starts from a known-good configuration instead of a blank table.
Reading the CSV when the number is wrong
| What the CSV shows | What it means |
|---|---|
| Response matches request, value differs from expectation | Scaling or byte-order problem on the client side; see float byte order |
| Exception responses instead of data | The device refused the request: wrong function code, address, or quantity |
| Requests sent, no responses, gaps in the log | Timeouts: wiring, unit ID routing, or device overload |
| Values change with no write in the log | The device (or another master) changed them; check for a second client on the network |
For reading and interpreting the frames themselves, start with how to read holding registers and the function code reference.
Capture, Trend, and Export Modbus Data
MacTools Modbus Poll for macOS: live traffic log with CSV export, block import/export, and trend plots beside the register table. $19 one-time.
Get Modbus Poll: $19Frequently Asked Questions
What should I capture when debugging Modbus?
Three layers, cheapest first: register values over time (what changed), the traffic log of requests and responses with timestamps (who asked, what came back), and exception responses (what the device refused and why). Values alone cannot tell you whether a wrong number was misread, scaled wrong, or never sent.
How do I export Modbus traffic to CSV?
Modbus Poll keeps a live traffic log of every request and response. One click exports it as a timestamped CSV for spreadsheets or a ticket attachment, and TCP-level events export separately. Register blocks also import and export as CSV, so a verified setup becomes a file you can re-load before the next site visit.
How do I prove a vendor's device returned bad data?
Capture the raw transaction: the exact request frame, the exact response bytes, and the timestamp. A traffic CSV from a neutral master tool is evidence a vendor can act on, unlike a screenshot of a number that disagrees with their HMI. Attach the CSV, name the register addresses, and the conversation moves from blame to bytes.
Can I watch Modbus register values change over time?
Yes. Mark registers to watch and Modbus Poll plots them as a live trend alongside the table, so you can see noise, drift, and stuck values while the connection is open. Trends catch what a single reading cannot: a sensor railing at full scale, a counter that resets, or a value that only misbehaves under load.
What is a Modbus baseline capture?
Before you change anything on a working system, export the traffic and values as they are. When a later change is blamed for a regression, you compare against the baseline: same addresses, same frames, same values. It takes two minutes during commissioning and settles arguments months later.
Logging forever is a different job:
Voltrus SCADA logs Modbus plus OPC-UA, S7, EtherNet/IP and BACnet to history with dashboards and alarms. Lifetime license from $49.