Archives par mot-clé : Modbus

A4A : compilation de libmodbus avec GNAT GPS sous Windows

Bonjour,

Pour mon premier article concernant « Ada for Automation » j’ai choisi de mettre en exergue d’une part GNAT GPL, l’atelier de développement édité par AdaCore, et d’autre part la bibliothèque libmodbus que j’utilise pour développer des outils de test ou de démonstration par exemple et aussi dans « Ada for Automation ».

Je me propose donc de montrer une facette de GNAT GPL, que j’utilise bien évidemment pour développer en Ada, mais qui est également très capable pour développer dans d’autres langages dont le C, ce que je vais mettre à profit pour compiler libmodbus sous Windows® XP.

J’apprécie beaucoup libmodbus, une bibliothèque qui permet de réaliser très simplement une application Modbus, RTU Maitre ou Esclave / TCP Client ou Serveur, qui présente de nombreux avantages comme la disponibilité du code source, une licence LGPL, disponibilité pour plusieurs plateformes dont Linux et Windows®.

Comme je suis souvent sous Windows®, ainsi que bon nombre d’entre nous, et que cette bibliothèque n’est pas fournie sous forme binaire, il est nécessaire de disposer d’une chaine d’outils pour obtenir la DLL qui va bien pour nos projets.

En cherchant un peu sur la page de Monsieur Stéphane Raimbault on trouve que, pour compiler sa bibliothèque sous Windows®, on peut utiliser MinGW et MSYS. Il est également possible d’utiliser Microsoft Visual Studio®.

C’est très bien pour ceux qui ont une certaines expérience de ces outils mais c’est un peu complexe pour beaucoup, dont le public espéré pour « Ada for Automation ».

Or il se trouve que GNAT GPL est disponible sous Windows®, intègre MinGW et les outils nécessaires à cette compilation, et s’installe le plus simplement.

Moyennant un petit fichier définissant les chemins, les fichiers et quelques options de compilation, l’outil GPRbuild va gérer compilateur, linker…

Voici donc le contenu de ce fichier « lib_modbus32x86.gpr », que je trouve assez auto-explicatif :

library project Lib_Modbus32X86 is

   for Languages use ("C");
   for Library_Dir use "..\libmodbus-3.0.3\libs\x86";
   for Library_Kind use "dynamic";
   for Library_Name use "modbus";
   for Source_Dirs use ("..\libmodbus-3.0.3\src");
   for Source_Files use ("modbus.c", "modbus.h", "modbus-data.c", "modbus-private.h", "modbus-rtu.c", "modbus-rtu.h", "modbus-rtu-private.h", "modbus-tcp.c", "modbus-tcp.h", "modbus-tcp-private.h", "modbus-version.h");
   for Object_Dir use "..\libmodbus-3.0.3\obj";
   for Library_Options use ("-lws2_32");

   package Linker is
      for Linker_Options use ();
   end Linker;

end Lib_Modbus32X86;

J’ai donc téléchargé le code source de libmodbus et je l’ai désarchivé dans mon arborescence avec 7-Zip. J’ai créé les répertoires « libs » et « obj » parce que j’aime bien que tout ne soit pas mélangé.

Pour un projet en C utilisant cette bibliothèque, il suffit d’inclure le fichier projet de celle-ci dans le fichier de notre projet « c01.gpr » :

with "lib_modbus32x86.gpr";

project C01 is

   for Languages use ("C");
   for Source_Dirs use ("src");
   for Source_Files use ("unit-test-server.c", "unit-test.h");
   for Main use ("unit-test-server.c");
   for Object_Dir use ".\obj";
   for Exec_Dir use ".\exe";

   package Naming is
      for Spec_Suffix ("c") use ".h";
      for Body_Suffix ("c") use ".c";
   end Naming;

end C01;

Bien sûr, j’ai créé l’arborescence correspondante :

Pour ce projet de test je ne me suis pas embêté ; j’ai récupéré les fichiers sources dans le dossier « tests » de libmodbus.

En ouvrant le projet « lib_modbus32x86.gpr » avec GNAT GPL et en tentant de le compiler j’ai obtenu une erreur comme quoi le fichier « config.h » inclus dans les fichiers « modbus.c » et « modbus-private.h » n’existait pas. C’est normal car ce fichier est généré par les autotools que l’on n’utilise pas dans ce cas. J’ai donc commenté les lignes et « Build All » a réussi à générer la DLL.

Ta ! Tan ! Yeah !

So far, so good…

Voyons avec le projet de test.

Ça compile d’un coup de « Build All » et je trouve mon exécutable là où il est censé se trouver. J’y colle avec la DLL car le chemin de celle-ci n’est pas dans mon %PATH%.

Je peux lancer mon programme de test obtenu et il attend la connexion d’un client :

Comme client, je vais utiliser l’utilitaire « Modbus Poll« .
Je définis une connexion vers le PC exécutant mon programme de test. Le port est le « 1502 », celui qui est défini par défaut dans le programme de test car sous Linux le port « 502 » nécessite des droits administrateur.

Et le compteur qui s’incrémente est de bon augure.

Tandis que côté programme de test Modbus TCP Server, qui a été compilé avec l’option « Debug » sur « On », on observe les traces de nos échanges.

N’est-ce pas merveilleux ? 😉

Cordialement,
Stéphane

cifX : Mise en œuvre – Modbus TCP Serveur

Bonjour,

Mon précédent article présentait la mise en œuvre des cartes Hilscher cifX de manière générale.

Dans celui-ci nous allons détailler la configuration d’une carte cifX au format PCI, disposant de deux ports Ethernet, la cifX 50-RE, avec un firmware Modbus TCP, ce firmware pouvant être configuré en Client ou en Serveur, (voire les deux simultanément mais c’est plus sportif ;-)).

J’ai déjà évoqué l’application cifXSetup qui est installée en même temps que le pilote cifX et qui est accessible depuis le panneau de configuration de Windows®. Lorsque l’on exécute cette application sans avoir procédé à une quelconque configuration, on trouve une carte non configurée évidemment :

On y voit notamment le numéro de produit et le numéro de série. Comme ma carte est un peu ancienne, elle ne dispose pas de la roue codeuse pour régler le numéro d’emplacement (ou slot). Comme il n’y en a qu’une dans cette machine de test elle est identifiée « cifX0 ».

L’on voit également qu’elle dispose de deux ports Ethernet et qu’aucun fichier de firmware ni de configuration n’est affecté à cette carte pour l’instant.

Comme on souhaite configurer la carte en tant que serveur Modbus TCP, il est possible de le faire avec « netX Configuration Tool », l’outil dédié à la configuration des versions esclaves.

L’outil détecte la carte cifX qui a le numéro de série 20951, qui ne dispose pas de firmware et encore moins de configuration. Comme la carte est équipée de ports Ethernet, l’outil ne propose que les protocoles Ethernet / Ethernet Temps Réel que sont PROFINET, EtherCAT, Ethernet/IP, Modbus TCP, Sercos III, POWERLINK et VARAN.

En cliquant sur le bouton Modbus TCP, on obtient la vue de configuration Modbus TCP comme de bien entendu, avec une configuration par défaut :

On y apporte les modifications que l’on souhaite, ici j’ai remplacé l’affectation des paramètres par serveur DHCP par une affectation statique et j’ai coché l’option « Map FC1 and FC3 ».

Voilà, voilà, ma configuration est terminée et je télécharge et le firmware et la configuration en cliquant sur « Apply ».

Le chargement s’est bien passé, c’est le cas en général, et le message dans la barre de status l’indique.

J’ai branché le câble Ethernet et la communication a démarré toute seule (l’option « Bus Startup » est sur « Automatic ») et l’on attend la connexion du Client Modbus TCP.

Comme client, je vais utiliser l’utilitaire « Modbus Poll » qui ne va pas mal :

Bien sûr, cela fonctionne aussi avec n’importe quel autre client Modbus TCP.
S’il y a de la demande, je veux bien vous établir un exemple avec un automate M340 de Schneider Electric.

Je définis donc une connexion avec ma carte cifX.

Et la communication démarre avec la FC3 qui est la fonction de lecture de registres définie par défaut.
On voit le compteur s’incrémenter, c’est plutôt bon signe…

ModbusPoll04

Côté « netX Configuration Tool », ça s’anime :

On peut jouer avec nos entrées et sorties depuis la vue « IO Monitor » :

Cette vue nous permet d’affecter des valeurs à nos sorties – qui sont donc les entrées pour Modbus Poll – et de visualiser l’état de nos entrées – les sorties de Modbus Poll.

Un, deux et trois :

Ça marche dans ce sens !

Je lis donc avec la fonction FC3 les entrées, ce qui est vrai car j’ai coché l’option « Map FC1 and FC3 » lors de la configuration. Sinon, je relirais les sorties, ce qui peut présenter un avantage s’il y a plusieurs clients Modbus TCP qui pilotent les sorties.

Je peux modifier mes définitions de fonctions pour les lectures / écritures :

Fonction FC3 ou Lecture de multiples registres internes :

Ou fonction FC4, Lecture de multiples registres d’entrées :

Fonction FC16 ou Écriture de multiples registres internes :

Testons l’écriture…

Onze, douze, treize… Envoi !

Et pendant ce temps sur « netX Configuration Tool » :

Donc cela fonctionne, mais personne n’en doutait.

Si l’on exécute à nouveau cifXSetup, on voit que maintenant les espaces firmware et configuration sont renseignés.

On trouve dans l’arborescence les dossiers et fichiers destinés au pilote cifX :

Et dans la base de registres les clés sont bien présentes :

Cordialement,
Stéphane

netTAP : firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT

Bonjour,

Hilscher propose avec ses passerelles netTAP 100, netTAP 50 et netBRICK et les firmwares standard disponibles, environ 300, un éventail de solutions pour la conversion de protocoles particulièrement large.

Cependant, si les firmwares standard couvrent très bien les besoins pour les données échangées cycliquement, comme les PDO pour CANopen, les communications acycliques ne sont à ce jour pas supportées.

Ces échanges acycliques sont utilisés pour la configuration, le paramétrage et le diagnostic précis des équipements connectés.

En visant l’exhaustivité en matière de combinaisons protocolaires, il n’est pas aisé de concevoir un mécanisme générique susceptible de supporter l’ensemble des fonctions quel que soit le protocole. Les concepts sont bien similaires mais les disparités sont irréductibles, volume, type de données, adressage…

D’où la nécessité de concevoir spécifiquement un mécanisme permettant cet échange acyclique. C’est ce que nous avons réalisé avec ce firmware.

Le produit standard Hilscher NT 100-RE-CO possède les interfaces physiques nécessaires et Hilscher France fournit le firmware spécifique.

Les outils de configuration standard Hilscher sont utilisés.

Ce firmware permet les fonctions de lecture / écriture de SDO et la commande NMT CANopen via Modbus TCP.

Le manuel utilisateur pour ce firmware est disponible ici :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/Manuel%20Utilisateur%20Passerelle%20NetTAP%20Modbus%20TCP%20CANopen%20V01.pdf

Un projet de configuration exemple SYCON.net est également fourni :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/Hilscher/NT-OMBCOM-ACYC%2020121123.zip

Enfin, le projet de test avec un automate Schneider Electric M340 est téléchargeable là :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/SchneiderElectric/nt-ombcom-acyc.sta

Il est à noter que le principe retenu pour la gestion des échanges acycliques dans ce firmware peut être aisément transposé à d’autres combinaisons protocolaires et nous pouvons donc réaliser chez Hilscher France la combinaison dont vous auriez besoin comme :

  • PROFINET Maitre ou Esclave – CANopen SDO + NMT
  • Ethernet/IP Maitre ou Esclave – CANopen SDO + NMT
  • PROFIBUS Maitre ou Esclave – CANopen SDO + NMT
  • DeviceNet Maitre ou Esclave – CANopen SDO + NMT

N’hésitez pas à solliciter Hilscher France si besoin.

Cordialement,
Stéphane

netTAP : Protocoles série – ASCII – 3964R – Modbus RTU – Lua

Bonjour,

J’ai déjà présenté la famille de passerelles Hilscher netTAP dans mon introduction.

Dans cet article je me propose de développer les différentes options permettant la gestion des protocoles série, supportés sur les ports RS232, RS422 et RS485, configurable avec SYCON.net, des passerelles des gammes NT 100 et NT 50.

ASCII

Ce mode permet la gestion de tout protocole ASCII simple, comme celui d’un lecteur de code à barre par exemple.

Dans ce mode, la passerelle gère un tampon en émission et un en réception.
La passerelle peut travailler en réception seule, émission seule, client (émission / réception) ou serveur (réception / émission).

Depuis le bus de terrain, le contrôleur ou l’automate dispose les trames à émettre dans le tampon d’émission et commande l’émission via un registre de synchronisation dans sa zone de sorties.
Cette trame peut être complétée automatiquement par l’adjonction de caractères de début / somme de contrôle / fin de trame et l’émission peut être réitérée en cas d’erreur. Tout ce traitement est paramétrable avec l’outil de configuration SYCON.net.

A la réception d’une trame, les caractères de contrôle peuvent être traités selon le paramétrage effectué, les données sont déposées dans le tampon de réception et le contrôleur en est informé via le registre de synchronisation dans sa zone d’entrées.

Bien sûr, les erreurs sont signalées.

3964R

Ce mode permet la gestion du protocole 3964R, bien connu dans le monde Siemens.

Le fonctionnement de ce mode s’apparente à celui de l’ASCII.
Je ne vais pas le détailler plus avant.

Modbus RTU

Ce protocole est encore très répandu.

La pile de protocole Modbus RTU embarquée dans les passerelles peut être configurée soit en Maitre, soit en Esclave.

Lua

C’est là où je voulais en venir ! 😉

Lua est un langage de script puissant, léger et rapide :
http://www.lua.org/

Il est possible d’étendre Lua, ce que Hilscher a réalisé en rajoutant des fonctions spécifiques pour la communication, d’une part sur le port série, et d’autre part vers le bus de terrain choisi.

Lors de la configuration de la passerelle NT 100, il est possible de sélectionner un firmware embarquant un interpréteur Lua / netSCRIPT.
On choisit un bus de terrain primaire parmi (Maitre / Esclave) CANopen, DeviceNet, PROFIBUS, EtherCAT, Ethernet/IP, Modbus TCP, PROFINET, Sercos III ou POWERLINK (Esclave) et netSCRIPT côté réseau secondaire.

Avec ce langage, il est possible d’effectuer tout type de traitement sur les trames et de gérer l’émission et la réception selon le besoin.
Cela permet de pré-digérer les trames au niveau de la passerelle et de ne présenter au contrôleur que les données utiles à celui-ci.

Il découle de cette architecture où la passerelle assure l’intégralité de la gestion du protocole ASCII plusieurs avantages :

  • Le programme du contrôleur se trouve soulagé d’autant.
  • On peut utiliser le même script avec un contrôleur d’un autre fabricant et / ou un bus de terrain différent.

De nombreux exemples et des squelettes de code sont disponibles sur le DVD ainsi que des présentations et tutoriels.

– Et ça ressemble à quoi ?
– A ceci :

---------------------------------------------------------------------
-- Hello World
--
-- A minimal script which prints "Hello World" to the RS232 interface.
--
-- Requirements:
-- netTap with netSCRIPT firmware,
-- serial console connected via RS232, 115200 Baud 8N1
--
--
-- Author     Date          Change
-- =================================================
-- S. Lesch   Sep 16, 2009  removed German comments
-- S. Lesch   Aug 27, 2009  added comments
--

-- We only want to execute the following block once.
if not run_once then

    -- configure serial port
    p = PortOpen({
        interfacetype = port.INTERFACE_TYPE_RS232,
        baudrate = 115200,
        databits = 8,
        stopbits = 1,
        paritymode = port.PARITY_NONE
        })

    -- Print "Hello World"
    p:PortSend("Hello World" .. string.char(10, 13))

    -- Remember that the script has executed
    run_once = true
end

– Trop cool ! C’est vraiment super mais je ne souhaite pas investir pour l’instant de ressources pour l’apprentissage de Lua / netSCRIPT.
– Nous pouvons prendre en charge le développement de vos scripts si vous nous fournissez la spécification du protocole série et celle de l’interface applicative que vous souhaitez. Cf. notre offre de services.

C’est ce que nous avons réalisé par exemple pour l’un de nos clients utilisant les pompes LEVITRONIX avec contrôleur LPC-200.3 (RS232) :
http://www.levitronix.com

Nous l’avons également réalisé pour le protocole des débitmètres GEMÜ C38 SonicLine :
http://products.gemue.de/fr/produits-high-purity/debitmetre/

Cordialement,
Stéphane

netTAP : Schneider Electric meets Siemens

Bonjour,

Après avoir présenté d’une manière générale les passerelles Hilscher netTAP, je souhaite vous fournir un exemple emblématique de leur utilisation.

Dans ce qui suit je vais donc m’attacher à démontrer que les mondes Schneider Electric et Siemens ne sont pas si étanches qu’il y parait.

Étant donnée la diffusion des équipements de ces fabricants on conçoit qu’il soit nécessaire de temps à autre de les faire communiquer ensemble. Ce qui n’est pas automatique car les protocoles de communication supportés en standard par ces équipements ne sont pas directement compatibles.

Parmi les protocoles disponibles dans les automates Schneider Electric figure en bonne place Modbus, en version série (Modbus RTU) ou en version Ethernet TCP/IP (Open Modbus TCP).

Récemment Ethernet/IP, protocole développé par le consortium ODVA que Schneider Electric a rejoint, a fait son entrée dans le monde Schneider Electric.

Côté Siemens PROFIBUS est disponible depuis la gamme S5 et PROFINET, son descendant sur Ethernet est présent sur la plupart des CPU récentes.

S’il existe des solutions intégrées comme les coupleurs PROFIBUS pour automates Schneider Electric ou Modbus RTU / TCP pour les automates Siemens, elles ne sont pas nécessairement faciles à mettre en œuvre ou très économiques.

Aussi, la solution passerelle Hilscher netTAP peut-elle tirer son épingle du jeu en proposant toute sorte de combinaison protocolaire adaptée au besoin. Chaque camp conserve sa technologie, outils et licences optionnels ne sont plus requis.

On trouve dans la gamme Hilscher netTAP les solutions suivantes :

  • PROFIBUS / Modbus RTU
  • PROFINET / Modbus RTU
  • PROFIBUS / Modbus TCP
  • PROFINET / Modbus TCP
  • PROFIBUS / Ethernet/IP
  • PROFINET / Ethernet/IP
  • Etc…

L’exemple proposé met en œuvre une combinaison Open Modbus TCP côté Schneider Electric et PROFIBUS DP côté Siemens.

D’un côté nous avons donc une configuration automate Modicon M340 composée de :

  • BMX P34 1000 / CPU 340-10 Modbus
  • BMX NOC 0401 / Coupleur Ethernet/IP et Modbus TCP

De l’autre, une CPU S7 315-2DP Siemens équipée donc d’un port PROFIBUS que nous configurerons en maitre :

  • 6ES7 315-2AG10-0AB0

Au milieu, une passerelle Hilscher netTAP disposant d’une connectivité Ethernet et d’une connectivité PROFIBUS :

  • NT 100-RE-DP

Le programme exemple pour l’automate Schneider Electric M340 contient :

  • la configuration de l’automate avec la fonction IO Scanning montrant les requêtes suivantes :
    • lecture seule de 32 mots (FC3),
    • écriture seule d’un mot (FC6),
    • écriture seule de 64 mots (FC16),
    • lecture de 32 mots / écriture de 32 mots combinées (FC23).
  • une table d’animation présente les variables relatives aux requêtes.

Il est disponible ici.

Le programme de la CPU Siemens S7 contient :

  • la configuration de la CPU, on aura pris soin d’importer le fichier GSD de la passerelle dans le catalogue matériel.
  • le programme principal OB1 utilise les fonctions DPRD_DAT (Read Consistent Data of a Standard DP Slave) et DPWR_DAT (Write Consistent Data to a Standard DP Slave).
  • une table de variables affiche les données des modules définis.

Il est à votre disposition .

Enfin, la configuration de la passerelle :

  • après avoir chargé le firmware qui va bien, NTOMBDPS.NXF, comme évoqué ici,
  • on configure les paramètres côté Open Modbus TCP,
  • puis côté PROFIBUS DP. Ce n’est pas obligatoire mais on a inséré un module PROFIBUS pour chaque requête Modbus TCP, c’est plus cohérent, et on a intégré les états (status) de chaque côté dans les données de l’autre.
  • on termine par l’affectation (le mapping) des données,
  • et on n’oublie pas de transférer la configuration dans le netTAP.

La configuration de la passerelle peut être obtenue en suivant ce lien.

I can help…

Cordialement,
Stéphane