Master or Slave? 

It is important to determine which instrument is acting as the Modbus Master when going through the troubleshooting process as it will direct you to the correct instrument that is causing the error. If the data controller is the Slave, then all you can do is make sure that you are using the correct bit or register address from the Modbus map (customer login req'd), and that you are writing to a Q-type (Modbus) controller channel. Should that be correct, then the source of the error is coming from the instrument acting as the Master. If the logger is the Master, then you can use the tools below to help identify the problem.

Client and Error Tables

When the logger is acting as a Master, data must first be transferred to the Client Table before it is either written to a channel or sent to another instrument. The Client Table registry is also called the holding registers, as it is essentially the holding place for data before it is assigned to a location. The Client Table can be accessed by remoting into the data controller and choosing S (Status Menu) > V (View Modbus Master Status) > T (View Modbus Client Table).

The holding register location is specified within the Modbus SERVER.CFG file configured in the data controller, and each holding register can be viewed in the Client Table to see the data being assigned in real time. Note that all data represented in the Client Table is in hexadecimal.

When reading data from an instrument to the data controller, it is always a good idea to check the Client Table to see if the data is getting to the controller. In addition, the Client Table also acts as the list of data transmission errors which can be accessed by looking at register 6000 within the Client Table.

Register 6010 corresponds with the error message for the first line in the SERVER.CFG file, with every register after that corresponding with the next consecutive line. Each different kind of error is represented as a hexadecimal number defined in the Modbus Exception Codes (customer login req'd). The most common Modbus error is ‘FFDF’, which indicates that the data controller and the instrument cannot communicate.

Server Table

The Server Table is the list of registers directly corresponding to a particular channel or set of digital lines. Using the data controller’s Modbus Map, these registers can be determined and used as an indication of the final placement of the data. If the holding register has been verified and has the correct number but the channel is still not reading correctly, then the incorrect register address may be referenced within the SERVER.CFG file.

Modbus TCPdump

In the upcoming 8864 controller firmware upgrade 5.02, the Modbus TCPdump feature has been added as a more direct way of seeing what kind of Modbus data is being transmitted to and from the controller. Choosing this option in the Modbus Master Status Menu pulls up the stream of Modbus going into and out of the data controller.

Each line shows the IP address of the instrument transmitting the data, the direction the data is transferred, the type of data (bit or register) that is being transferred, and the hexadecimal version of the data strings being transferred. The data shown on this screen can be written to a file within the logger and accessed over an FTP connection. This allows users to capture a large period of data being transferred over Modbus to help pinpoint irregular periods. Note that this is a new feature, and will not be available in an 8832 or an 8864 with firmware older than v5.02.

Fixing Data Transmittal Errors

Using the tools mentioned above can help find sources of error, but other action will need to be taken to fix any of those errors. Many issues arise due to a SERVER.CFG file that is configured incorrectly, but there are multiple sources of communication errors between instruments. Some examples of common issues are described below.

  • If there is a communication problem between the controller and an instrument, try to ping the instrument from the logger. The ping menu in the logger can be accessed by choosing S (Status Menu) > S (System Maintenance) > P (Connectivity Tests). If you are unable to ping the instrument from the logger, then there is something wrong with the network or Ethernet/Serial connection between the two instruments. If you ARE able to ping the other instrument, then there is likely some setting on the instrument that is preventing Modbus communication.
  • On current and older controller firmware versions, a communication problem with one instrument can cause problems with all other instruments transmitting data over Modbus. The controller will still try to pull data from the bad instrument, which slows down all other connections and causes some scans to be missed. Controller firmware 5.02 introduces parallel Modbus that allows each instrument to be on its own parallel connection. This will prevent a disconnected instrument from interfering with all other instruments.
  • Some instruments have problems if the interval between requests is too short, and some data loss might occur if the instrument cannot keep up. If this is the case, try raising the poll delay of the commands to that instrument within the SERVER.CFG file.
  • Make sure the vendor has provided you with the most recent Modbus map. Every so often, a manufacturer will update the Modbus map for an instrument, adding some new registers and sometimes shifting around the existing registers. Always make sure you have the most recent Modbus map for your instrument before trying to troubleshoot a problem.
  • Remember that integer numbers occupy a single register, while floating point numbers occupy two registers. Trying to read a floating point number with only a single register will give you incorrect data.
  • If you are dealing with integer numbers, ensure that the Modbus scaling factor on the channel is set up correctly. The default value is set to 0.01, so if the scaling factor on the instrument you are reading from is different, you will get a number that is off by some factor of 10.
  • The input scan interval on the channel determines how often the logger will update a channel’s value with new Modbus data. If you are only polling an instrument for data every 30 seconds, then there is no reason to update the logger channel any quicker than that. Setting the input scan interval to 0s will cause it to poll once per base interval, which is most commonly set to be one minute.
Contact the ESC support team if you need more help understanding your Modbus data.
 512-250-7901  •

Contact our sales team today to inquire about how our data loggers can work for you.
512-250-7902  •

Clint Anderson, System Implementation Engineer, ESC    Published: 10/19/2016 12:04:17 PM

Questions about the ESC DAS?

We'd love to answer your questions.

Contact Us

New to Data Acquisition Systems?

Check out our helpful animation that teaches the basics of

What is a DAS?