When working with Modbus devices and TOP Server, one critical factor that can significantly influence communication efficiency is the concept of block sizes. Optimizing block sizes for your application ensures smooth data transfer between your Modbus device and TOP Server, improving overall system performance.
In this blog, we’ll talk about what Modbus block sizes are, why they matter, and how to configure them effectively in TOP Server for the best results. We’ll also cover what happens when a block request includes non-contiguous addresses or undefined memory, causing potential issues with valid data. Additionally, it is important to note that other drivers/protocols may utilize block sizes as well, so these concepts could apply to other protocols beyond just Modbus.
What Are Modbus Block Sizes?
In Modbus communication, block sizes refer to the number of input or output coils (binary points) or registers (numeric values) that can be accessed within a single request. When configuring Modbus communication in TOP Server, the block size you set determines how much data can be read from or written to the Modbus device in a single transaction. Understanding these range limits is key to ensuring efficient communication which we will discuss throughout this blog.
TOP Server’s range of block sizes are driven by Industry Standard Modbus specifications which state:
- Coils (Discrete/Binary Outputs and Inputs): The block size can range from 8 to 2000 coils (bits) per request.
- Registers (Holding and Input/Internal): The block size can range from 1 to 120 registers per request.
Devices on the other hand are not required to support the full ranges of the standard, and there is no enforcement mechanism in the industry. In devices that are older, have lightweight CPUs and memory, they often do not. Depending on the device, it may support maximum request sizes much smaller than industry standard. Devices are also not required to return a 0 for unused memory locations! Some devices view requests for invalid memory locations as invalid requests and reject them. Conversely there are devices that allow larger transmission sizes, specifically in Oil & Gas specific controllers, which TOP Server handles through its Oil & Gas specific drivers which is outside the scope of this blog.
Why Do Block Sizes Matter?
Setting the correct block size directly affects the number of requests made between TOP Server and the Modbus device by modifying the size of each individual request. If block sizes are too small, TOP Server will need to make more frequent requests to read or write the required data, which increases network traffic and overhead. On the other hand, if the block sizes are too large, they might exceed the device’s memory or processing capabilities, leading to timeouts or errors.
Balancing block sizes ensures that the data is transferred efficiently and reduces unnecessary communication, which is crucial for systems that need fast response times or have high volumes of data to manage.
How Block Sizes Effect Communication
Consider this example: You need to read 100 holding registers from a Modbus device. With a block size limit of 120 registers in TOP Server, you could theoretically retrieve all 100 registers in a single request. You can see this behavior in the TOP Server Communication Diagnostics below:
One request with a quantity of 100 registers (Hex 64)
Now, let’s explore a scenario where you’re reading 100 registers using a block size of 25. In this case, TOP Server would make multiple requests to retrieve the full data set:
4 requests, each with a quantity of 25 registers (Hex 19)
- The first request reads registers 1 to 25.
- The second request reads registers 26 to 50.
- The third request reads registers 51 to 75.
- The fourth and final request reads registers 76 to 100.
Now that we know what Block Sizes are and how they are used in communicating with devices, this brings us to the next important point: what happens when a block includes addresses from both valid and invalid memory?
What Happens When a Block Encompasses Undefined or Non-Contiguous Memory?
When you configure TOP Server to read data from a Modbus device in blocks, all the addresses within a block must be valid for the device to respond successfully. If any part of the requested block includes undefined or non-contiguous memory (i.e., addresses the device does not recognize), the Modbus device can reject the entire block request, including all valid addresses within that request. It can also return 0’s for unused spaces. Every device is different, though Schneider (Modicon) PLCs tend to return 0’s.
Let’s break this down with another example. Suppose you need to read 100 registers from a device, but these registers are not stored in a continuous block of memory. Instead, they might be grouped like this:
- Registers 1 to 50 are valid and contiguous.
- Registers 51 to 60 are undefined or nonexistent.
- Registers 61 to 100 are valid and contiguous.
If you set a block size of 32 registers, TOP Server would attempt to read:
- Registers 1 to 32 (successful, since all registers are valid).
- Registers 33 to 64 (unsuccessful, since the request spans across both valid and invalid register ranges).
- Registers 65 to 96 (successful, since all registers are valid).
- Registers 97 to 100 (successful, since all registers are valid; only the last 4 registers are read since nothing after offset 100 was requested).
Here, the second request would fail because it includes addresses in the undefined memory range (registers 51 to 60). Consequently, if the request failed, the entire block would be invalidated, and TOP Server will not return any data for that request because the device will return an exception code, even for the valid addresses in the range, like registers 33 to 50. Below is what you can expect to see in the TOP Server Event Log in this situation.
This issue becomes more pronounced as your requested blocks increase in size or as you deal with devices where memory is non-contiguous. Because Modbus reads and writes data in blocks, even a single invalid address in a block causes the whole request to fail, resulting in data loss. When you see errors like this, you could test with individual tags addressing single memory locations to explore how the device behaves at boundaries of unused locations. This can help with troubleshooting efforts, which we will explore further later on.
Configuring Block Sizes in TOP Server
Ideally, your PLC is configured to have contiguous memory addresses, but that cannot always be the case. Therefore, to avoid issues with Block Sizes, it’s important to configure them correctly in TOP Server to match your device’s capabilities and memory layout. In the Modbus channel configuration of TOP Server, you can adjust the block size for each data type (coils, registers) to fit within the limits supported by your Modbus device.
For example, if you’re working with a device that has non-contiguous memory regions as the example above, you may need to manually reduce the block size or split requests into multiple smaller blocks. As mentioned before, you could test individual tags reading a single address to determine where the unused location is. Alternatively, the device documentation may also provide an answer to how your device is configured, but in our experience they often do not. By doing so, you ensure that each request only covers valid, contiguous memory ranges, which prevents the device from rejecting the entire request.
TOP Server also offers diagnostic tools (such as Communication Diagnostics and Event Log) that can help you monitor communication and identify issues related to block sizes, such as invalid responses. If you notice errors or failed requests, reviewing your block size configuration is an excellent first troubleshooting step.
Using Block Sizes for Troubleshooting
To show how Modbus Block sizes can be a valuable tool for troubleshooting Modbus communication issues, particularly when it comes to identifying invalid addresses, I have put together a quick example. Let’s say I am reading the following tags below with a block size of 30:
This means all addresses between 40001 and 40030 will be requested even though I am asking for those 10 tags because my first tag address (40001) and last tag address (40030) can fit within the same block of 30 registers. Now let’s say that our initial read request with a block size of 30 returns an error indicating a “Bad address in block … 40001 to 40030” shown in the image below. This message suggests that somewhere in that range, an address is invalid, but it doesn’t specify which one. It also could potentially be an address I am not even requesting such as 40015, but remember, it gets grouped into the request due to my block size of 30. To narrow down the problematic address, I can reduce the block size to 1, allowing TOP Server to request each address individually. After adjusting the block size, the error message below now specifies “Bad address in block … 40002 to 40002,” pinpointing that address 40002 is the invalid one.
By isolating individual addresses, reducing block size effectively helps identify exactly where an invalid address is located, enabling faster resolution of configuration issues.
Using Block Sizes for Performance
When configuring Modbus communication in TOP Server, the size of the block requests has a direct impact on performance, particularly when dealing with large volumes of data. Let's explore a real-world example where 2000 tags, each with valid addresses, are monitored. We’ll compare the performance of two different block sizes: 2 registers and 100 registers and analyze the resulting time it takes to complete all requests.
Block Size of 2 Registers
- 1000 separate requests with 3000 total communication events (1 Tx and 2 Rx each)
- Time of first request: 4:07:08.533
- Time of last request: 4:07:12.588
- Total time to complete a single read of all 2000 tags = ~4 seconds
Block Size of 100 Registers
- 20 separate requests with 60 total communication events (1 Tx and 2 Rx each)
- Time of first request: 4:01:55.334
- Time of last request: 4:01:55.485
- Total time to complete a single read of all 2000 tags = ~150 milliseconds
This example highlights how block sizes can drastically affect the performance of Modbus communication in TOP Server. By increasing the block size from 2 to 100 registers, the total time retrieving data from all 2000 tags was reduced from 4 seconds to just 150 milliseconds! That’s 26 times faster just from one setting! This difference in performance could be even more drastic on a higher scale with varying levels of network reliability. This consideration is critical in applications where fast data retrieval is essential for process monitoring and control.
Optimizing block size is a key factor in establishing efficient and timely communication, especially when dealing with large data sets. The fewer the requests and communication events, the faster the data can be retrieved, improving overall system performance. Every situation and needs can be different, so it is important to optimize your block sizes for your device and your needs specifically.
Other Scenarios
In practical use, you might find that certain address ranges within your device require different block sizes. There could be a range of addresses in your PLC that is non-contiguous, so a smaller block size would be needed to avoid the “Bad address in block” error. However, if there was a larger set of tags configured in this device that were contiguous, using the same small block size for all the remaining tags would be inefficient and could introduce performance delays because of all the additional requests.
To address this, you can simply configure multiple devices in TOP Server, all pointing to the same physical device. Each device in TOP Server can have distinct block sizes that cater to the specific requirements of each register range, assuming your physical device does not limit the number of simultaneous connections to the device. This is a particular concern if you are using serial to Ethernet converters. If you can’t get a second connection to work, consult your device documentation and setup software as it may clearly show a limit of 1 simultaneous connection, which may be adjustable or not.
If your device supports it, this multi-connection approach helps you maintain efficiency and troubleshooting accuracy while ensuring different block sizes are tailored to specific needs. Balancing block sizes in this way optimizes your data retrieval, minimizes error messages, and improves overall system performance.
Conclusion
Optimizing Modbus block sizes is essential for ensuring smooth communication between TOP Server and your Modbus devices. Setting block sizes too large or allowing them to cover undefined or non-contiguous memory ranges can result in request failures, where even valid data is lost.
By understanding your device’s memory layout and configuring TOP Server to avoid undefined memory regions, you can prevent data loss and ensure reliable communication. Always refer to your Modbus device’s documentation and use TOP Server’s diagnostic tools to fine-tune your block size settings for optimal performance.
If you run into any problems or have any questions regarding block sizes for your device, please feel free to contact our technical support team.
Don't forget to subscribe to our blog to find out about the latest updates to TOP Server and for other useful tutorials and resources as well as take a look at our other Modbus related Technical Blog posts.
Ready to get started using TOP Server with your Modbus devices? Download the free trial today.
