Bonjour,

Introduction

Comme convenu, cet article présente un conteneur Docker gérant une carte Hilscher cifX avec le pilote récemment libéré (délivré !) et le binding Python cifX déjà évoqué.

Il présente également un cas d’utilisation avec un tableau de bord Grafana.

Les cartes cifX permettent aux applications de communiquer sur les principaux bus de terrain, classiques (PROFIBUS, DeviceNet, CANopen…) ou sur Ethernet Temps Réel (PROFINET, EtherCAT, EtherNet/IP…). Ceci en tant que maître ou en tant qu’esclave pour employer un terme générique, chaque technologie ayant spécifié sa propre terminologie.

Hilscher met à disposition le pilote cifX Device Driver pour Linux ici :
https://github.com/HilscherAutomation/nxdrvlinux

Il contient un exemple d’utilisation de l’API en C ainsi que le cifX TCP Server.

Celui-ci permet d’accéder à la carte via TCP/IP et d’utiliser les outils de configuration standards Hilscher SYCON.net et Communication Studio.

Le binding Python permet quant à lui d’utiliser une petite partie de l’API cifX.
Suffisante néanmoins pour le besoin de beaucoup d’applications puisqu’elle offre l’accès à l’image process de la carte.

Conteneur Docker cifX-DrvTest

Vous trouverez le Dockerfile et quelques instructions dans le projet dédié :
https://gitlab.com/ada-for-automation/python/cifx/cifx-drvtest

Les passerelles dédiées à l’IIoT Hilscher telles la netFIELD On Premise intègrent une carte cifX Ethernet Temps Réel.

Ce conteneur est donc tout particulièrement adapté pour expérimenter sur cette plateforme !
Tout PC sous Linux équipé d’une cifX fera l’affaire néanmoins.

netFIELD OS, le système d’exploitation Linux durci qui gère celle-ci, dispose d’une interface web basée sur Cockpit intégrant un terminal.

Il suffit donc de cloner le dépôt dans le dossier de votre choix et de lancer la commande de build indiquée.

Le Dockerfile contient toutes les instructions pour créer une image Debian avec le pilote cifX et le binding Python.

Le README fournit les instructions pour la création du conteneur tout comme celle pour le démarrer.
L’interface web permet également la création et le démarrage du conteneur.

Une fois le conteneur démarré, on peut s’y connecter en SSH par exemple ou directement depuis le système hôte et on peut exécuter les exemples dont le cifX TCP Server.

Ce conteneur disposant des outils de compilation est donc indiqué pour tester et développer des applications. Cependant il n’est pas adapté pour être déployé, en cause notamment son poids.

Aussi, il va servir de base pour créer d’autres conteneurs ne contenant que le strict nécessaire pour le déploiement des applications.

Conteneur cifX TCP Server

Ce conteneur est également basé sur Debian et directement dérivé du conteneur précédent dans lequel on récupère uniquement les bibliothèque (libcifx) et application (cifx_tcpserver).

Ainsi, on démarre ce conteneur pour la configuration et le diagnostic de la carte cifX, il permet l’utilisation des outils standards Hilscher.

Conteneur cifX-MQTT

Enfin, le projet cifX-MQTT contient le script Python définissant l’application passerelle ainsi que le Dockerfile permettant la création du conteneur idoine.

L’image de ce conteneur est de même basée sur Debian, on récupère la libcifx et le binding Python depuis l’image du cifX-DrvTest et on installe le script application.

Configuration Telegraf

Je réutilise pour cette démonstration l’infrastructure déjà en place.

Et je modifie juste la liste des topics MQTT de Telegraf pour récupérer celui que j’expédie depuis la cifX.

Ma pauvre démo utilise la cifX configurée en maître EtherCAT connecté à une carte NXIO-RE qui ne dispose que de deux octets en entrée et autant en sortie.

Aussi, je ne remonte qu’un mot et par ailleurs l’application souscrit à un topic émis depuis l’automate S7 qui est recopié dans les deux octets de sortie de la NXIO-RE.

  ## Topics that will be subscribed to.
  topics = [
    "ps7/s7-315-2dp/db1.dbw0",
    "ps7/s7-315-2dp/ew0",
    "ps7/s7-315-2dp/aw0",
    "ps7/s7-315-2dp/mw0",
    "OMB/server0/My_Uint",
    "OMB/server0/My_Int",
    "cifX/Word0",
  ]

Tableau de bord Grafana

Je récapitule :

• la carte cifX communique avec un équipement d’E/S,
• l’application cifX-MQTT accède à l’image process via le binding cifX et transmets les données vers le broker MQTT,
• Telegraf récupère les topics MQTT et les envoie à la base de données InfluxDB,
• Grafana pioche dans InfluxDB pour alimenter ses tableaux de bord.

Et voilà !

Conclusion

On sait donc utiliser les cartes cifX, configurées en maître ou en esclave pour toutes les technologies de bus de terrain supportées, depuis une application en Python.

J’ai présenté dans les derniers articles un cas d’utilisation avec les tableaux de bord, et encore en utilisant qu’une des possibilités en vogue – InfluxDB et Grafana.

Et il y a bien d’autres cas qui pourraient faire l’objet de démonstrations.

Par la suite, j’envisage d’expérimenter avec Apache Superset :
https://superset.apache.org/

D’autant qu’il est tout à fait possible de l’utiliser avec InfluxDB :
https://www.influxdata.com/integration/apache-superset/

On peut aussi faire des rapports, par exemple avec le susdit Apache Superset.
Cependant j’ai déjà eu l’occasion de me faire la main sur Streamlit et je lorgne sur Mercury.

Et bien d’autres choses encore !

Cordialement,
Stéphane