Une méthode simple pour diagnostiquer un problème de communication Modbus

par Paul Smart | Mis à jour le : 03/08/2017 | Commentaires : 4

Mots clés :

DevConfig Modbus SCADA TCP/IP

Les thèmes principaux du Blog


Recherche sur le Blog


Langages du blog

English
Français (French)


Abonnez-vous au Blog

Recevez un courriel lorsqu'un nouvel article est posté. Choisissez les sujets qui vous intéressent le plus.


Entrez votre adresse courriel :



Suggérer un article

Y a-t-il un sujet que vous souhaiteriez nous voir aborder ? Laissez-nous un message.

Leave this field empty

Modbus

Avez-vous déjà installé une centrale de mesure de Campbell Scientific en tant qu'esclave 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 qu'esclave 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 (maître Modbus), la centrale d'acquisition de données (esclave 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

Communication Modbus avec des mesures analogiques d'une centrale de mesure pour un système SCADA

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 :

  1. Ouvrir le Device Configuration Utility, et connectez-vous à votre centrale de mesure.
  2. Sélectionner l'onglet Terminal sur votre droite.

Terminal tab selected in DevConfig

Cliquer sur l'image DevConfig pour agrandir la copie d'écran.

  1. Appuyer sur la touche Entrée de votre clavier jusqu'à ce qu'un caractère apparaisse sur votre écran.
  2. Taper W, et appuyer sur la touche Entrée.

    DevConfig screen

    Cliquer sur l'image DevConfig pour agrandir la copie d'écran.

  3. Sélectionner TCP/IP, le numéro 13 et appuyer sur la touche Entrée.
  4. Sur votre écran, on vous demandera ASCII (Y)? Taper N, et appuyer sur la touche Entrée.
  5. Si votre enregistreur de données ne reçoit pas d'information Modbus, votre écran ressemblera probablement à ceci :

    DevConfig with ASCII question

    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 :

A successful trace in DevConfig

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 maître 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 maître 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 maître qui commence par l'adresse esclave 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 maître (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 esclave Modbus.
  • La centrale de mesure a reçu un identifiant esclave Modbus qui ne correspond pas à ce que le maître 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.


Partagez cet article



A propos de l'auteur

paul smart 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.

Voir tous les articles de cet auteur.


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.

Please log in or register to comment.