Une méthode simple pour diagnostiquer un problème de communication Modbus
par Paul Smart | Mis à jour le : 03/08/2017 | Commentaires : 6
Avez-vous déjà installé une centrale de mesure de Campbell Scientific en tant que serveur Modbus et découvert que vos données n'arrivaient pas à votre système SCADA comme prévu ? Vous avez peut-être découvert rapidement deux choses : résoudre le problème de communication n'est pas une tâche facile, et il y a beaucoup de différentes approches pour arriver à résoudre ce problème. Dans cet article, je vais vous indiquer une méthode que j'ai trouvée à la fois utile pour vous faire gagner du temps.
Les centrales d'acquisition de données de Campbell Scientific fournissent des données de mesure aux systèmes SCADA (supervisory control and data acquisition - Contrôle de supervision et d'acquisition de données) dans le monde entier. Ceci est souvent réalisé en configurant une centrale d'acquisition de données en tant que serveur Modbus TCP/IP, dont nous avons parlé dans l'article du blog ''Comment accéder en direct aux données de mesure en utilisant le ModBus”.
Normalement, le processus de mise en place de la communication entre votre centrale de mesure et le système SCADA est fluide, mais il arrive parfois que les techniciens sur le terrain découvrent que les données ne sont pas arrivées au système SCADA comme prévu. À ce moment-là, vous pouvez vous demander : Où est le problème avec la communication ? Le problème est-il sur le système SCADA (client Modbus), la centrale d'acquisition de données (serveur Modbus) ou quelque part entre les deux ?
Dans notre dernier article Modbus, nous utilisons un exemple avec une centrale d'acquisition de mesure qui effectue des mesures analogiques et qui envoie les données au système SCADA à travers le protocole Modbus TCP/IP
Nous utiliserons le même exemple ici. Votre système SCADA est configuré pour interroger votre centrale de mesure toutes les secondes pour le contenu de ses registres Modbus. Votre centrale de mesure, à son tour, effectue des mesures analogiques, puis les stocke dans ses registres Modbus ''Holding'' et ''Input'' à chaque seconde.
Mais que se passe-t-il si votre système SCADA ne reçoit pas correctement les données de votre datalogger ou centrale de mesure ? Que pouvez-vous faire maintenant ? Vous pouvez utiliser le logiciel utilitaire de Campbell Scientific Device Configuration Utility (DevConfig) pour surveiller le trafic entrant vers votre centrale de mesure. Cela permet de déterminer si les informations de votre système SCADA arrivent à votre centrale d'acquisition de données et si votre centrale de mesure y répond.
Suivez ces étapes afin d'utiliser DevConfig pour afficher les sondages Modbus :
- Ouvrir le Device Configuration Utility, et connectez-vous à votre centrale de mesure.
-
Sélectionner l'onglet Terminal sur votre droite.
Cliquer sur l'image DevConfig pour agrandir la copie d'écran.
- Appuyer sur la touche Entrée de votre clavier jusqu'à ce qu'un caractère apparaisse sur votre écran.
- Taper W, et appuyer sur la touche Entrée.
Cliquer sur l'image DevConfig pour agrandir la copie d'écran.
- Sélectionner TCP/IP, le numéro 13 et appuyer sur la touche Entrée.
- Sur votre écran, on vous demandera ASCII (Y)? Taper N, et appuyer sur la touche Entrée.
- Si votre enregistreur de données ne reçoit pas d'information Modbus, votre écran ressemblera probablement à ceci :
Cliquer sur l'image DevConfig pour agrandir la copie d'écran.
Notez qu'aucun trafic Modbus n'est détecté sur le TCP/IP. Le seul message affiché à l'écran est ''appuyer sur Echap pour quitter, ou toute autre touche pour renouveler le délai d'attente.'' Ce scénario pourrait indiquer une ou plusieurs des conditions suivantes :
- Le système SCADA ne recherche pas la centrale de mesure.
- Le système SCADA recherche une adresse IP différente.
- Une adresse IP incorrecte a été attribuée à la centrale de mesure.
- Un câble n'est pas branché.
- Le trafic Modbus est bloqué par le réseau.
Votre centrale de mesure peut être configurée et programmée complètement, mais si elle ne reçoit pas les informations du maître SCADA, les données n'arrivent pas là où elles sont attendues. À ce stade, concentrez vos efforts de dépannage sur le réseau SCADA, la configuration du maître, etc. (zones en dehors de la centrale de mesure).
Note spéciale : Dans des cas comme celui-ci, vous pouvez voir le trafic sur le TCP/IP qui n'est pas le trafic Modbus, tel que le trafic PakBus à partir d'un serveur LoggerNet s'il existe une connexion LoggerNet à une centrale d'acquisition de données sur le réseau.
Une fois que vous avez résolu vos problèmes de réseau ou du système SCADA, une trace réussie ressemble à ceci :
Cliquer sur l'image DevConfig pour agrandir la copie d'écran.
La façon la plus simple de reconnaître le trafic TCP Modbus et de le distinguer des autres protocoles, est que la transmission à partir du client commence toujours par un identificateur dans les deux premiers octets. Dans notre exemple, le premier sondage qui a été reconnu dans la trace a commencé avec 00 16. La centrale de mesure, à son tour, a répondu avec ce même identificateur unique (00 16). La seconde fois que le client a interrogé, il a utilisé l'identifiant 00 17 et la centrale de mesure a répondu par 00 17 et ainsi de suite.
Note spéciale : Il existe une différence entre le trafic Modbus TCP et le trafic Modbus RTU. La manière la plus simple de reconnaître le trafic Modbus RTU consiste à rechercher une transmission à partir du client, qui commence par l'adresse du serveur Modbus et le code de fonction. La réponse de l'esclave commencera également par son adresse et son code de fonction.
Si vous pouvez voir les informations Modbus provenant du client (T), mais pas de réponses de la centrale de mesure (R), il est temps de vérifier la configuration et la programmation de la centrale de mesure. Vous pouvez avoir une erreur dans votre configuration comme :
- La centrale de mesure n'est pas programmée comme serveur Modbus.
- La centrale de mesure a reçu un identifiant serveur Modbus qui ne correspond pas à ce que le client recherche.
À ce stade, vous aurez besoin de vérifier la configuration de votre centrale de mesure pour dépanner.
Conclusion
L'utilisation de DevConfig pour surveiller le trafic TCP/IP sur votre centrale d'acquisition de données est une excellente façon de vérifier rapidement, si les choses fonctionnent comme prévu. Cette méthode économise souvent beaucoup de temps parce que vous pouvez identifier plus rapidement le problème de communication.
Si vous avez des questions sur cet article, veuillez les poster ci-dessous.
A propos de l'auteur
Paul Smart est le vice-président des ventes et du marketing de Campbell Scientific, Inc. Sa première expérience avec les équipements Campbell a eu lieu peu de temps après avoir été diplômé de l'université, alors qu'il travaillait à une série d'expériences de culture de plantes conduites sur la Station spatiale internationale. Paul aime utiliser la technologie unique de Campbell Scientific pour résoudre des problèmes de mesure complexes. Paul est titulaire d'un baccalauréat en génie électrique et d'un MBA. Loin du bureau, Paul aime le plein air, la pêche à la mouche et passer du temps avec sa famille.
Commentaires
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.