The PortDock web tool «Industrial pcap Analyzer» pairs Modbus TCP requests and responses in a capture by transaction ID and measures response times. This guide is the order to read its tables in. MC protocol traffic appears in the same tables, paired by the 4E serial number (3E by send order).
1. What the response time measures
From the moment the last byte of a request frame was captured to the moment the last byte of the response with the same transaction ID was captured. It includes the device's processing time and the network round trip, and for a serial device behind a gateway also the serial transfer time. The value depends on where you captured: on the client PC it is that PC's view, on a mirror port it is closer to the time between the devices.
2. Reading the summary
| Field | Meaning | What to look at |
|---|---|---|
| Median | The middle value of all response times | The usual speed. Is it well below the polling interval? |
| 95% | 95% of replies arrive within this | The floor for a timeout. A timeout below it means occasional missing replies even on a good day |
| Max | The slowest reply | One spike or many? Check the time chart |
| No response | No matching reply within the limit (1000 ms by default) | May be capture loss — see section 4 |
| Unmatched response | A reply with no request, or one that arrived after the limit | The device did answer, late — the client timeout may be too short |
| Capture ended | Last requests the capture ended too early to judge | Not counted as a problem |
You can change the no-response limit on the page. Set it to the timeout of the HMI, PLC or program in use and you count the same requests that side treated as timed out.
3. Which table first
- By connection: does the client open several connections to the same server, and do the request interval (polling) or response time differ per connection? Many retransmissions or gaps point to the network first (cables, switches, congestion).
- By device (station): with several unit IDs behind one gateway, is one station slower or missing replies? Check that station's serial wiring, address and baud rate.
- By function code: some devices read (03, 04) quickly but write (06, 10) slowly. Also see whether requests for many registers are the slow ones.
- Exception codes: 02 (no such address) and 03 (bad value) mean fix the request; 04, 06 and 0B point at the device or gateway state. Click a row to open that frame in the Modbus decoder field by field.
4. Is «no response» really the device?
- If the notes above the results mention missing bytes, the capture itself lost packets. Busy or slow mirror ports cause this.
- If other connections or stations go silent at the same moment, the network or gateway is more likely than one device.
- An unmatched response with the same transaction ID right after a missing reply means the device answered, just later than the limit.
- After a missing reply, clients often close and reopen the connection (connection closed, new connection) — devices that accept few connections may refuse the new one.
5. Serial devices behind a gateway
For a device behind a Modbus TCP-to-RTU gateway, the serial transfer time adds directly to the response time. At 9600 bit/s and 11 bits per character (8 data bits plus start, stop and parity), reading 10 holding registers takes an 8-byte request plus a 25-byte reply = 33 characters, about 37.8 ms of transfer alone (33 × 11 ÷ 9600). Device processing and the 3.5-character gaps come on top. Use the «Serial Timing Calculator» for other baud rates and counts. With several stations on one gateway, requests are served one after another, so waiting grows with the number of stations.
6. Choosing settings from the numbers
- Timeout: look at the 95% and max and leave room above the max, so the one or two spikes on the time chart do not all become missing replies.
- Polling interval: if a connection's request interval (median) is too close to the median response time, requests pile up. Keep it above number of devices × response time.
- After changing settings, capture again and compare the same tables. To create slow or missing replies on purpose without a device, use PortDock Modbus Slave's fault injection (response delay, no response).
Wireshark is a trademark of the Wireshark Foundation; PortDock is not affiliated with Wireshark or Microsoft.
Sources
- Modbus Messaging on TCP/IP Implementation Guide V1.0b — MBAP header — transaction ID pairs requests and responses; unit ID
- Modbus Application Protocol Specification V1.1b3 — §7 exception codes
- Wireshark Wiki — CaptureSetup/Ethernet — capture loss on mirror ports
Published 2026-10-31