Software Toolbox Technical Blog

When working with Modbus communication, understanding the key concept of function codes is essential for ensuring efficient and accurate data exchange. Sometimes a device manual might only refer to the supported Modbus function codes and the range of offsets available for those function codes. A solid understanding of function codes is critical in achieving optimized performance and resolving potential communication issues.

After reading this blog, you'll know how you can leverage TOP Server’s Modbus driver to automatically handle the appropriate function codes for your application – while also taking advantage of its flexibility and other advanced features – to enhance performance, ensure compatibility with your devices, and reduce troubleshooting time.

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.

Have you ever been confused on the difference between Modbus offsets and addresses? I’m sure you may have configured different Modbus devices from different manufacturers who follow different documentation standards, especially for memory mapping. As we all know, that can certainly increase implementation time. In this blog post, we are going to dive into how offsets and addresses compare and differ to hopefully provide a better understanding, cutting down that configuration time when using TOP Server. Before we start comparing offsets and addressing, let’s first get an understanding of what both are.

In the world of industrial automation and control systems, communication protocols play a crucial role in ensuring seamless data exchange between devices. Modbus started as a protocol used in Modicon, now Schneider Electric, PLCs in the 1970’s. It was adopted across the industry for its clarity and simplicity. With any protocol, including and especially with Modbus, there are areas where the parties to the communication, the client and server, can interpret the bit stream of data differently once exchanged because the Modbus protocol specification does not speak to those interpretations.

With Modbus having been around since 1979, I’m sure you have had some interaction with it or at least awareness of it if you work in the automation industry. Our TOP Server is very widely used for its Modbus TCP/IP Ethernet Driver and variety of Modbus serial drivers to enable users to connect to any Modbus devices that they have in the field. For that common use case, the device is the Modbus Server, and the TOP Server is the Modbus Client.

But what if you needed to configure TOP Server to be the Modbus TCP/IP Server (i.e. the “device”)? That is the purpose of this next post in our continuing Tech Support Corner blog series – to discuss and tell you how you can configure TOP Server to act as a Modbus server device, which is a common need for systems where either a device or other software application can only act as a Modbus Client and you have other systems that need connectivity to that Modbus client.

Modbus is one of the most widely used protocols around the world, implemented as the communications protocol by many different vendors for integration with other systems. If you're reading this, you likely have at least one Modbus device (whether it's a PLC, RTU or other device) being used in your industrial process and need to integrate data from that process.

In this video blog, I'll show you how to get started using our Modbus TCP Ethernet driver and it's flexible settings to connect and gather real-time process data from pretty much any Modbus Ethernet capable device for HMI, SCADA, MES and other client applications.

I'm sure you've all at least had some interaction with Modbus, working in the automation industry.  It's one of the most widely used protocols (if not the most widely used) in the world.  Which is both its blessing and its curse, to some extent.

Given how long Modbus has been around and in use as an "open" protocol (starting in 1979), there have been many different interpretations of Modbus throughout the years.  And with those different Modbus interpretations, much confusion about the different terminology for accessing data.

In this blog post, I will step through the basics of Modbus addressing including how offsets come into play, and how they affect what addresses to use in TOP Server for AVEVA applications.