Método para diagnosticar problemas en las comunicaciones Modbus

por Paul Smart | Actualizado: 03/08/2017 | Comentarios: 6

Temas Blog


Buscar en el Blog


Suscribirse al Blog

Configure sus preferencias para la recepción de notificaciones por email cuando se publiquen nuevos artículos en el blog que coincidan con sus áreas de interés.


Entre su dirección email:



Sugerir un Artículo

¿Hay algún tema sobre el cual desea saber más? Háganoslo saber. Por favor sea lo más específico que pueda.

Leave this field empty

Modbus

Have you ever set up a Campbell Scientific data logger as a Modbus server 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 data loggers provide measurement data to SCADA (supervisory control and data acquisition) systems throughout the world. This is often accomplished by configuring the data logger as a Modbus TCP/IP server, 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 data logger 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 client), the data logger (Modbus server), or somewhere in-between?

In our last Modbus blog article, we used an example with a data logger 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 data logger every second for the contents of its Modbus registers. Your data logger, 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 data logger? What can you do now? You can use Campbell Scientific’s Device Configuration Utility (DevConfig) to monitor the incoming traffic to your data logger. This helps determine if the polls from your SCADA system are arriving at your data logger, and if your data logger is responding.

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

  1. Open the Device Configuration Utility, and connect to your data logger.
  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 data logger 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 data logger.
  • The SCADA system is polling a different IP address.
  • The data logger has been assigned an incorrect IP address.
  • A cable is not plugged in.
  • Modbus traffic is being blocked by the network.

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

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-data-logger 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 client 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 data logger, in turn, responded with this same unique identifier (00 16). The next time the client polled, it used an identifier of 00 17, and the data logger 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 client that starts with the Modbus server address and function code. The server response will also start with its address and function code.

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

  • The data logger is not programmed as a Modbus server.
  • The data logger has been given a Modbus server ID that does not match what the client is polling.

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

Conclusion

Using DevConfig to watch the TCP/IP traffic on your data logger 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.


Compartir este artículo



Acerca del autor

paul smart Paul Smart is the Vice President of Sales and Marketing at Campbell Scientific, Inc. His first experience with Campbell Scientific equipment came soon after graduating from college while working on a series of plant-growing experiments conducted on the International Space Station. Paul enjoys leveraging unique Campbell Scientific technology to solve challenging measurement problems. He has a bachelor’s degree in electrical engineering and an MBA. Paul also enjoys the outdoors, fly fishing, and spending time with his family.

Ver todos los artículos de este autor.


Comentarios

smile | 04/05/2017 at 01:16 PM

Dear Paul, basically I do not understand, the reasons because with a commercial RS232 868Mhz radio-modem on port COM4 of a CR1000 OS31, the connection does not work with MODBUS protocol.
The strange situation is:
1) on the RS232 port with the commercial radio-modem all works fine (modbus and pakbus)
2) on the COM4 port with the commercial radio-modem pakbus works fine
3) on RS232 port and COM4 with your RF416 radio (trasparent mode) all works fine (modbus and pakbus).
Before spending time with sniffer on serial port and investigate with oscilloscope, these situations can suggest to you some idea?
Unfortunately for local issues (distance, vegetation and other) can not use the your radio RF416.
During the tests (in our office) that I have mentioned above, nothing changes, only:
- the program instruction “MODBUSSLAVE” and “SERIALOPEN” between the RS232 Vs COM4
- DB9 cable for RSR232 Vs cable with individual pins (TX, RX and GND) for the COM4
These are the lines that use in program.
SerialOpen(COM4,9600,0,5000,1000)
ModbusSlave (Com4,9600,1,modln(),modbus_port,0)

I can say that, when it does not work (commercial radio-COM4-MODBUS), the data arrives at the remote radio, in fact I can see the green LED RX that lights up, but the CR1000 does not respond and the red LED TX remains off.

I tried to increase the delay, even up to 5 seconds,
“SerialOpen(COMRS232,9600,0,5000000,1000)”
“ModbusSlave (ComRS232,9600,1,modln(),modbus_port,0)”
but I see that the CR1000 always immediate answer, of course, the working situation 1 (Commercial radio, RS232 MODBUS).

I hope that this series of tests can give you some suggestions, of course I am available in case of questions.

Thanks in advance

Regards

Smile

smile | 04/05/2017 at 01:21 PM

Sorry Paul, this was a premise that I forgot to put in my previous post.

Dear Paul, perhaps you are the person that can help me a real headache. I've already opened a discussion on this subject in the forum and I also wrote to Franco Casule UK. Let's see who is able to help me before :-), unfortunately I have some urgency. What I'm writing is a synthesis of the two messages that I already wrote in the forum and Franco.

smile | 04/05/2017 at 01:24 PM

Of course, I am available for other information useful for diagnosis

Paul Smart | 04/10/2017 at 10:36 AM

Sorry for the delay in responding.  It looks like JDavis has answered your question in the forum already concerning the potential issue with timing delays coming from the radio.  Good luck going forward and thanks for reading.

Haidar | 03/01/2023 at 04:11 AM

I'm working on my senior project at the NED University of Engineering and Technology in Karachi, Pakistan. It is our responsibility to create a data acquisition card that will gather the data and transmit it to the cloud platform. Data from the Campbell CS215, NRG 40H anemometer, NRG 200, and Campbell CS100 must be retrieved from the Campbell Scientific data logger CR-1000, which also served as a storage device for other instruments.
Our attempt to retrieve the data using an Arduino Mega and MAX3232 to RS232 converter has been unsuccessful. With respect to this, I have the following queries:
1. Which method of communication is being employed? Is it possible to do it using MODBUS TCP or MODBUS RTU?
2. What are the register addresses and where are sensor values typically stored?
3. How can a command be sent to the Data Logger using Arduino (using MODBUS or another Library) to inform it of the
password, after which we can retrieve the data.
And what kind of password is necessary to complete the task? either Level 1 or Level 2 or Level 3
If you have any documents with register addresses, please provide them.
Please assist me in solving this issue.

Seth Berger | 03/07/2023 at 04:25 PM

Hi Haidar,

For application questions like this one, we recommend using our "Ask a Question" section of the website to get in touch with one of our technical support, system implementation, or application engineers. This will ensure we can gather all the information necessary about your system and your goals to provide the best solution. You can find our "Ask a Question" web form at the link below.

https://www.campbellsci.com/questions?qtype=2

Please log in or register to comment.