Modbus Polling Configuration

October 26th, 2021

Configuring Modbus Polling

When choosing a poll period for a Modbus data source, understanding the following is important. Modbus data sources will poll all of their data points each poll by sending multiple requests to the slave device for the values. Depending on the configuration Modbus4J will choose to break up the requests into requests. The following settings will define how the messages are chosen:

  1. Contiguous batches only - can be used to specify that the modbus implementation should not attempt to optimize disparate value requests into a single request. Checking this field will cause the implementation to only make requests for multiple values when those value form contiguous register space.
  2. Max read register count - the number of registers to read within a single request
  3. Max read bit count - the number of Coils or Inputs to read within a single request
  4. Timeout

When determining if the data source can make all the requests within the poll period it is very helpful to look at the IO Log. This log shows the O (Output from Mango) messages and the I (Input to Mango) messages with timestamps. This allows one to see what messages are being sent and if they can be completed within the poll period. Enable IO logging using the checkbox on the data source settings and looking in the logs folder for the modbusIO-<data source id>.log file.

One thing to consider when setting the timeout is the number of requests made during a poll. The timeout applies to each request (I/O pair in the log) so if the data source is making 10 requests with a timeout of 1000ms the data source will take over 10s to poll a device that doesn't respond. If you were to choose a poll period of 5s then the next poll will be aborted if the device is timing out.


The I/O Log contains the raw data coming in (I) and going out (O) of the data source. These are the exact messages that are being sent. For a Modbus data source the library chooses how to bundle the requests for the registers. In this regard the log is very helpful to see if all the values are being bundled in one request/response or multiple. Additionally, it has a timestamp on each line allowing you to see how long it takes the device to respond.

The filename is formatted modbusIO-<data source id>.log.

In your modbus IO log, if you can see that it is perpetually making requests, then it is NOT bundling them into larger requests. In a well tuned Modbus data source you can expect to see a request (or a few) made for each poll, and the poll period to be well defined in the log by tightly grouped timestamp entries (on the poll interval) that are periodic in the grouping. Seeing a constant stream of requests indicates that the settings are not correct for the poll period you have set and the data source is working 100% of the time to get its requests made.

If polls are being aborted the next polls are dropped until the current poll finishes. Once the current poll finishes the next poll will start on the computed poll time based on when the data source was started NOT the finish time of the next poll.

To fix this problem in the log you have two options:

  1. change settings to bundle the requests so they can finish within the poll period
  2. break the points out into more data sources.

Copyright © 2024 Radix IoT, LLC.