Bonjour,

Préambule

J’ai eu une demande pour une solution passerelle réalisant une conversion EtherCAT Esclave vers Modbus TCP Client pour connecter donc un maître EtherCAT avec un ou des serveurs Modbus TCP.

Naturellement, j’ai proposé une passerelle netTAP NT 151-RE-RE qui permet de réaliser cette conversion par simple configuration.

Cependant, mon interlocuteur est productif en C. Il s’est montré particulièrement intéressé par la netPI-RTE3.

Celle-ci est bien sûr plus évolutive puisque, mettant en œuvre Linux dans un environnement Docker, elle est programmable dans le langage de son choix.

Vous pouvez aussi consulter cette page pour plus d’information :
https://www.netiot.com/netpi/industrial-raspberry-pi-3/

Discussion

Node-RED est la solution préconisée pour réaliser toutes sortes de connexions entre les technologies opérationnelles (OT) et les technologies informatiques (IT) mais cela ne lui semblait pas très adapté pour l’échange de données demandant un certain niveau de performance.

Aussi, nous avons évoqué la possibilité de réaliser son application un peu dans l’esprit de ce que j’avais décrit dans cet article :
https://slo-ist.fr/ada4automation/a4a-netpi-rte-3-docker-container

En couplant les exemples C fournis par Hilscher et la bibliothèque libmodbus elle-même écrite en C, la solution s’écrit presque toute seule dans ce langage !

Je n’ai bien sûr pas pu résister… Nous avons également discuté de « Ada for Automation ». Cela lui a rappelé des souvenirs en Pascal.

Il était tout à fait pensable de proposer une solution en Ada.
Confiné que je suis, j’y ai bien sûr pensé très fort.
Ainsi c’est disponible !

Il existait bien le noyau 3 qui fournit un Serveur Modbus TCP couplé à un canal cifX, et le noyau 4 qui fournit en plus le Client Modbus TCP mais pas de noyau Client Modbus TCP couplé à un canal cifX.

Le noyau 4 aurait sans doute pu convenir mais il est constitué d’une tâche gérant le Serveur et le Client Modbus TCP et d’une seconde gérant le canal cifX car, pour une application de contrôle – commande, il peut être souhaitable que les temps de cycles de ces tâches soient différents.

Pour une application passerelle, cela complique un peu les choses car il faut faire communiquer ces tâches au travers d’un objet protégé.

Solution

Ainsi, pour le besoin de cette solution, un nouveau noyau a vu le jour, le kernel7.

Ce noyau gère donc un Client Modbus TCP d’un côté et un canal basé sur l’API cifX Hilscher de l’autre. Ce dernier supporte par conséquent tous les protocoles standard du marché, dont EtherCAT Esclave.

L’application de démonstration 132 a4a-k7-wui établit la correspondance des données de part et d’autre et une interface utilisateur Web permet le diagnostic.

En fait, on dispose déjà d’un couple d’applications de démonstration communicant grâce au protocole Modbus TCP, le couple 022 a4a-k1-wui / 010 a4a_piano, et un second qui communique en Ethernet Temps Réel via des interfaces Hilscher, le couple 062 a4a-k3-wui / 052 a4a_hilscherx_piano.

On peut combiner les applications de démonstration ainsi :
062 a4a-k3-wui / 132 a4a-k7-wui / 010 a4a_piano

Bien sûr, il est nécessaire de disposer de matériel Hilscher.

Le code source étant ouvert, il peut être étendu comme bon vous semble.

Test

Pour tester cette application, il faut bien sûr un Serveur Modbus TCP et un Maitre EtherCAT.

Plusieurs possibilités se sont offertes à moi dont le Raspberry Pi équipé d’un netHAT ou le netPI-RTE3.

CODESYS fournit le Maitre EtherCAT et on a déjà présenté l’image Docker pour le netPI-RTE3 ici.

Il me faut mettre à jour cette image, ce qui sera fait prochainement j’espère dès que j’en trouve le temps…
Mais vous pouvez bien sûr créer votre propre image à titre d’exercice !

Avec donc CODESYS dans son conteneur et « Ada for Automation » dans le sien, voilà une démonstration compacte.

Perspectives

CODESYS fournit aussi d’autres possibilités de communication comme PROFINET RT Contrôleur, Ethernet/IP Scanner, CANopen Maître, et aussi Modbus TCP Client et Serveur, Modbus RTU Maître et Esclave…

En combinant CODESYS avec « Ada for Automation », via une liaison Modbus TCP en local ou en distant, on peut envisager toutes sortes d’applications passerelles ou gérant des automatismes.

Les applications passerelles pourraient notamment prendre en charge des conversions évoluées avec gestion des communications acycliques.

Mais CODESYS pourrait bien sûr gérer une partie de l’application relative aux équipements connectés.

J’ai en mémoire par exemple une application disposant d’un Maître EtherCAT et ayant à gérer des équipements Esclaves CANopen pour lesquels il est nécessaire d’utiliser les SDO pour le paramétrage.

Plutôt que de réaliser une conversion complexe et remonter au niveau de l’application principale des tâches qui peuvent être déléguées, on peut les confier à CODESYS et définir une interface bien plus simple.

Cordialement,
Stéphane