// ModbusManager Pro — Serial Logging

Modbus RTU Data Logger
for RS-485 Lines

Most plant data still arrives on two wires, not Ethernet. A serial Modbus logger has limits an Ethernet one does not — and those limits, not the software, decide how often you can actually sample. This page covers the arithmetic, the realistic intervals, and how to read the line when a device goes quiet.

Download Pro trial — free 14 days All logging features

Modbus RTU, ASCII and TCP · Windows 10/11 · One-time license

// why serial is different

One pair of wires, one conversation at a time

Modbus TCP lets a logger open a socket per device and read them in parallel. RS-485 does not. Everything on the line takes turns, and the turns cost time.

An RS-485 segment is half duplex with a single master. The logger sends one request, waits for the reply, then sends the next. There is no overlapping and no queueing on the device side. That single fact produces almost every surprise people hit when they set up serial logging:

A one-second logging interval on twenty devices may be physically impossible at 9600 baud, no matter which software you use.
One device that stops answering slows down every other device on the line, because the master has to wait out its timeout.
Reading 10 registers costs barely more than reading 1 — so how you group registers matters more than how many you read.

// frame timing

What one read actually costs

A Modbus RTU character is 11 bits on the wire: one start bit, eight data bits, one parity bit and one stop bit. From that, the cost of a read is arithmetic rather than opinion.

A Read Holding Registers request is always 8 bytes. The reply is 5 bytes of framing plus 2 bytes per register. Between frames the standard requires a silent interval of 3.5 character times. On top of that sits the device turnaround — the time the slave itself needs before answering, typically 5–20 ms on meters and drives.

The table assumes a 10 ms turnaround. Your devices may be faster or slower, but the shape does not change.

Baud	10 registers	25 registers	50 registers	125 registers
9 600	52 ms	86 ms	143 ms	315 ms
19 200	31 ms	48 ms	77 ms	163 ms
38 400	20 ms	29 ms	43 ms	86 ms
57 600	17 ms	23 ms	32 ms	61 ms
115 200	13 ms	16 ms	21 ms	35 ms

The useful conclusion

Reading 125 registers at 9 600 baud costs 315 ms; reading 10 costs 52 ms. Six times the data for six times the time — but one read of 50 registers is far cheaper than five reads of 10, because each read pays the framing and turnaround cost again. If your registers sit in a contiguous block, read the block.

// choosing an interval

A worked example: twenty meters on one line

Twenty energy meters, ten registers each, one RS-485 segment. How often can this be logged?

9 600

~1.0 s per cycle

A one-second interval has zero margin: any retry or slow device pushes the cycle past its own deadline. Set 2 s and the line stays healthy.

19 200

~0.6 s per cycle

One second becomes comfortable, with room for the occasional retry. For most metering work this is the sweet spot.

115 200

~0.3 s per cycle

Sub-second logging is available — if every device on the segment supports the rate and the cable run is short enough to carry it cleanly.

Raising the baud rate is almost always cheaper than re-cabling. But it is a segment-wide decision: every device on the line has to be reconfigured, and long or poorly terminated runs that worked at 9 600 can start producing CRC errors at 115 200. Change it, then watch the error count for an hour before trusting it.

Devices do not have to share one interval. In ModbusManager each poll window keeps its own, so a meter you only need every 30 seconds does not have to be read at the rate of the drive next to it. The scheduler runs whichever window is due first and serialises everything onto the one connection.

// when data goes missing

Reading the line when a device goes quiet

Gaps in a logged series almost always come from the line, not the logger. The failure mode tells you where to look — if you can see the raw bytes.

What you see	What it means	Where to look
No reply at all	The device never saw a frame it recognised.	A/B swapped, baud rate, parity and stop bits, wrong unit ID, device not powered.
CRC errors	Bytes arrive but corrupted — the frame is damaged in transit.	Missing 120 Ω termination, long stubs, no bias resistors, VFD noise on an unshielded run, or a baud rate the cable cannot carry.
Exception reply	The device answered correctly and refused the request.	Wrong register address, off-by-one base (40001 vs 0), unsupported function code, or too many registers in one read.
Intermittent gaps	The line works but the cycle overruns its interval.	Interval shorter than one full cycle, one slow device dragging the rest, or a retry storm from a marginal connection.
One device times out, all get slow	The master waits out the full timeout before moving on.	Remove the offender from the poll list or lower its timeout. A single 1000 ms timeout adds a whole second to every cycle.

The Serial Monitor shows the request and reply bytes as they go out and come back, with timing. That is the difference between knowing which of the five rows above you are in and guessing at it — and on a commissioning visit, guessing is expensive.

// getting started

Setting up an RTU logging run

Connect and confirm one device first. Pick the COM port, baud rate, parity and unit ID, and read a single known register. Get one reply before adding anything else — a working baseline makes every later problem easier to place.
Group registers into blocks. Contiguous registers in one read cost far less than several small reads. The table above is the reason.
Set an interval you can afford. Count the devices, multiply by the per-read cost, then leave headroom. If the number is uncomfortable, raise the baud rate before lowering the ambition.
Add the rest of the line. Each device gets its own poll window and its own interval. Watch the error counters for a few minutes.
Enable logging with a deadband. On steady signals the deadband is what keeps the database from filling with identical rows.
Let it run, then check the gaps. Come back to the trend and look for holes. A gap means the line dropped, and the failure table tells you which kind.

Once data is in the historian, the rest works the same as for Ethernet devices: trend charts, selectable time ranges, CSV export. See Modbus data logger software for the logging features, timestamps and export formats, or the Modbus scanner if you do not yet know which unit IDs are on the line. Two settings decide how much of it you keep: see logging interval and deadband. And when the run is done, logging Modbus data to CSV covers getting the file out without the Excel surprises.

// frequently asked questions

Modbus RTU logging — FAQ

How often can I log Modbus RTU data over RS-485?+

It depends on baud rate, how many registers each read covers and how many devices share the line. At 9600 baud a 10-register read takes about 52 ms including the device turnaround and the 3.5-character silent interval, so twenty devices need roughly one second for a full cycle — and a one-second interval leaves no margin. At 19200 baud the same cycle takes about 0.6 s. Raising the baud rate is usually the cheapest way to shorten the cycle.

Why does one device slow down the whole RS-485 line?+

RS-485 is half duplex with a single master, so requests happen in turn. If a slave does not answer, the master waits out its full timeout before moving on. One silent slave with a 1000 ms timeout adds a full second to every cycle. Removing it from the poll list, or lowering its timeout, restores the rest of the line.

Can I log devices at different rates on the same RS-485 line?+

Yes. Each poll window has its own interval, so a slow energy meter can be read every 30 seconds while a drive on the same line is read every second. The scheduler serialises all requests onto the shared connection and always runs whichever window is due first.

How do I tell a wiring fault from a wrong unit ID?+

The symptoms differ. No reply at all points to wiring, baud rate or framing, because the device never saw a valid frame. A CRC error means bytes arrive but corrupted, which points to termination, noise or a baud mismatch. An exception reply means the device answered and rejected the request, so the address or function code is wrong. The Serial Monitor shows the raw request and reply bytes so you can tell the three apart.

Does it also log Modbus TCP?+

Yes. The same application handles RTU and ASCII on a COM port and TCP over Ethernet, and stores all of them in the same local database. A serial meter and an Ethernet PLC end up in one exportable record, which matters when you are handing over a commissioning report.

Modbus RTU Data Loggerfor RS-485 Lines