4 min read

How to Communicate Modbus Natively with ControlLogix

The Modbus protocol was originally published in 1979 by Modicon as a simple request-response protocol over serial communications. It was the first open protocol specifically designed to help device manufacturers publish data that could be read by PLCs. In 1999 this protocol was expanded to include communications over TCP/IP and UDP implementations, allowing it to be utilized in more complex situations. Its simplicity and maturity are what continue to drive its use by hardware manufacturers today. 


Rockwell Automation has published an Add-On Instruction (AOI) that can be imported into your program and enables your CompactLogix or ControlLogix PLC to act as a Modbus TCP Client or Server. 

This blog covers the steps to take, as well as limitations and design considerations, when setting up a Modbus TCP client AOI in Studio 5000.

Modbus TCP Client AOI

The Modbus TCP Client function block from Rockwell Automation provides a cost-effective solution for communicating over Modbus TCP using a ControlLogix or CompactLogix controller without the addition of a dedicated module when relatively low sampling frequency or fewer devices and transactions are required.

This AOI requires no third-party devices to communicate between PLCs and Modbus TCP servers and can be downloaded for free from the Rockwell website and implemented using the design considerations and best practices below.

Design Considerations & Limitations

When preparing to implement the block, you should take into account these design considerations:

  • Using this block requires controllers with Logix Sockets functionality (supported by these devices) as well as Logix Rev 20 or higher.
  • Non-consecutive datapoints may require data consolidation prior to transfer as there is a limit of five transactions per block.
  • Issues may be encountered if transaction count or poll interval is set too high. Various users have reported different limits for transaction count and poll interval, and this depends on server implementation and other system characteristics that are going to be unique in your application. More on this will be covered in the next section.
  • It is important to choose a poll interval that meets your data collection requirements without overloading the controller. In general, your poll interval measured in milliseconds will be many times greater than the periodic task rate in which the AOI resides. Below is an example of some recommended settings. Keep in mind there is a hard limit on the poll interval (or how often the AOI attempts to collect data) of 80ms. Any transaction with polling rate below 80ms will be polled at 1 second rate.

    ACE Modbus 1

    ACE Modbus2

  • Local registers are zero-based.

For each Modbus server you are communicating with, import an instance of the AOI using “import rung” command into a periodic task and don’t add anything to the rung. Choose a descriptive name when importing, as it is used for multiple data structures. Be sure to reference the design limitations mentioned above. For example, if the poll interval is too frequent for the task rate, you may get an overlap or overload errors depending on the severity of the overrun.

Implementation Example

Here is another example of a working system where the poll interval was set to 1000ms.

ACE Modbus 3

Most of the configuration will be done in the “YourBlockName_Parameters” data structure and “YourBlockName_Transactions” data structures that are created when you import the rung. Refer to the guide for further details.

ACE Modbus 4


Finally, byte and word order will depend on the Modbus implementation at the server. If the data coming across seems garbled, additional code will be required to swap the bytes and/or words as needed. Tools you may want to consider include the Swap Byte (SWPB) function or a custom AOI to condition the data.

For example, if the words in your data need to be swapped, you might consider a structured text routine within your configuration, such as:



Need Additional Support?

If you need additional guidance, a partner like Applied Control Engineering, who understands all aspects of control system design, engineering, and implementation, can help. We can assist you in identifying the best PLC communication options and solutions, saving you time and money throughout the development and deployment process.


Learn more about ACE's PLC and HMI services.