One Helpful Method to Diagnose a Modbus Communication Problem

by Paul Smart | Updated: 03/08/2017 | Comments: 0

Search the Blog


Subscribe to the Blog

Set up your preferences for receiving email notifications when new blog articles are posted that match your areas of interest.


Area / Application

Product Category

Activity

Corporate / News

Enter your email address:



Suggest an Article

Is there a topic you would like to learn more about? Let us know. Please be as specific as possible.

Leave this field empty

Modbus

Have you ever set up a Campbell Scientific datalogger as a Modbus slave and discovered that your data was not arriving at your SCADA system as you expected? You may have quickly realized two things: troubleshooting the communication problem is not an easy task, and there are many different approaches you can take. In this article, I’ll quickly share with you one method that I have found to be both helpful and a time-saver.

Campbell Scientific dataloggers provide measurement data to SCADA (supervisory control and data acquisition) systems throughout the world. This is often accomplished by configuring the datalogger as a Modbus TCP/IP slave, which we discussed in the “How to Access Live Measurement Data Using Modbus” blog article.  

Normally, the process of setting up the communication between your datalogger and SCADA system is smooth, but there are occasions when technicians in the field discover that the data is not arriving at the SCADA system as expected. At times like this, you may wonder: Where is the problem with the communication? Is the problem at the SCADA system (Modbus master), the datalogger (Modbus slave), or somewhere in-between?

In our last Modbus blog article, we used an example with a datalogger that was set up to make analog measurements and provide the data to the SCADA system through the Modbus TCP/IP protocol.

Modbus communication with analog measurement and datalogger to a SCADA system

We will use that same example here. Your SCADA system is set up to poll your datalogger every second for the contents of its Modbus registers. Your datalogger, in turn, makes analog measurements and then stores them in its Modbus Holding and Input registers every second.

But what if your SCADA system does not successfully receive data from your datalogger? What can you do now? You can use Campbell Scientific’s Device Configuration Utility (DevConfig) to monitor the incoming traffic to your datalogger. This helps determine if the polls from your SCADA system are arriving at your datalogger, and if your datalogger is responding.

Follow these steps to use DevConfig to see the Modbus polls:

  1. Open the Device Configuration Utility, and connect to your datalogger.
  2. Select the Terminal tab on the far right.

    Terminal tab selected in DevConfig

    Click the DevConfig screen for a larger image.

  3. Press the Enter key on your keyboard until you see a prompt on your screen.
  4. Type W, and press the Enter key.

    DevConfig screen

    Click the DevConfig screen for a larger image.

  5. To select TCP/IP, type 13 and press the Enter key.
  6. On your screen, you will be asked ASCII (Y)? Type N, and press the Enter key.
  7. If your datalogger is not receiving any Modbus polls, your screen will likely look something like this:

    DevConfig with ASCII question

    Click the DevConfig screen for a larger image.

Note that there is no Modbus traffic being detected over TCP/IP. The only message on the screen is “hit ESC to exit, any other key to renew timeout.” This scenario could indicate one or more of the following conditions:

  • The SCADA system is not polling the datalogger.
  • The SCADA system is polling a different IP address.
  • The datalogger has been assigned an incorrect IP address.
  • A cable is not plugged in.
  • Modbus traffic is being blocked by the network.

Your datalogger may be set up and programmed completely fine, but if it is not receiving the polls from the SCADA master, the data will not arrive where it is expected. At this point, focus your troubleshooting efforts on the SCADA network, master configuration, etc. (areas outside of the datalogger).

Special Note:  In instances like this, you may see traffic over TCP/IP that is not Modbus traffic, such as PakBus traffic from a LoggerNet Server if there is a LoggerNet-to-datalogger connection on the network.

After you’ve addressed your network or SCADA system problems, a successful trace looks like this:

A successful trace in DevConfig

Click the DevConfig screen for a larger image.

The easiest way to recognize the Modbus TCP traffic and distinguish it from other protocols is that the transmission from the master always starts with an identifier in the first two bytes. In our example, the first poll that was recognized in the trace started with 00 16. The datalogger, in turn, responded with this same unique identifier (00 16). The next time the master polled, it used an identifier of 00 17, and the datalogger responded with 00 17.

Special Note: There is a difference between Modbus TCP traffic and Modbus RTU traffic. The easiest way to recognize Modbus RTU traffic is to look for a transmission from the master that starts with the Modbus slave address and function code. The slave response will also start with its address and function code.

If you can see Modbus polls coming from the master (T), but no responses from the datalogger (R), it is time to check the configuration and programming of the datalogger. You may have an error in your setup such as:

  • The datalogger is not programmed as a Modbus slave.
  • The datalogger has been given a Modbus slave ID that does not match what the master is polling.

At this point, you’ll need to dig into your datalogger setup for further troubleshooting.

Conclusion

Using DevConfig to watch the TCP/IP traffic on your datalogger is a great way you can quickly check to see if things are working as expected. This method often saves a lot of time because you can more quickly identify the communication problem.

If you have any questions about this troubleshooting method, please post them below.


Share This Article



About the Author

Paul Smart manages the Renewable Energy Group at Campbell Scientific, Inc., which focuses on providing monitoring and communication solutions for researchers, consultants, and project developers working in wind and solar energy. Paul has a bachelor’s degree in Electrical Engineering and an MBA. Away from the office, Paul enjoys the outdoors, fly fishing, and spending time with his family.

View all articles by this author.


Comments

Please log in or register to comment.



We're now on Twitter!
Stay informed with our latest updates by following @CampbellSci