A4A : Modbus RTU Esclave

Bonjour,

Voilà ! C’est fait !
Ada for Automation dispose d’un noyau Modbus RTU Esclave !

Pourquoi tant d’exclamation pour quelque chose qui peut sembler anecdotique au temps de l’Ethernet Temps Réel ?

Parce que après des années de procrastination c’est enfin fait !

Parce que, ça peut servir encore, par exemple pour tester l’application de démonstration du noyau Modbus RTU Maitre, App3, dont il a été question à l’époque dans cet article.

Mais aussi parce que cela reste encore aujourd’hui très utilisé car simple, disponible, pas cher, et suffisant dans bien des cas.
Et qu’avec une liaison en RS485 on peut tirer plus loin. N’est-ce pas ?

Parce que, comme libmodbus le permet, et que c’était prévu dès le départ, j’avais un trou dans ma raquette !

Donc, grosso modo c’est calqué sur le noyau Modbus TCP Serveur, le K0, et, poussé par une grande inspiration, j’ai nommé ce nouveau noyau : K0b.

Pour tester ce noyau, j’ai aussi dupliqué les applications de test du K0, celle avec l’interface en ligne de commande est ici et celle avec l’interface graphique, mettant en œuvre GtkAda, est .

Sur mon portable, il n’y a pas de port série et j’ai donc eu à utiliser des convertisseurs USB/Série.

Et pour pouvoir utiliser ces ports série en tant que simple utilisateur, sans droits élevés donc, j’ai ajouté cette règle dans :

/etc/udev/rules.d/mbed.rules

SUBSYSTEM=="tty", MODE:="0666"

Il me reste à réaliser la duplication de l’application de démonstration avec une interface Web, fondée sur Gnoga, je veux parler de celle-ci.
Qui tourne !

A dans quelques jours donc !

Pour patienter, voici une introduction à Gnoga en français !
Merci Monsieur Pascal PIGNARD.

EDIT : le 21 Avril 2020

Voilà, voilà !
C’est disponible dans le dépôt !

Souvenirs, souvenirs

C’est quand même drôle un esclave Modbus RTU avec une interface utilisateur Web. Ou quand l’ancien monde côtoie le nouveau.
Le Edge Computing donc !

Ada for Automation ou comment faire du neuf avec du vieux.

Cordialement,
Stéphane

A4A : AsciiDoc, PlantUML, MindMap

Bonjour,

Je m’adonne à la documentation de ma danseuse tandis qu’il fait beau et que je pourrais être dehors. Mais, cette fois, j’ai une bonne excuse puisque nous voilà confinés…

La documentation, ce n’est pas généralement la partie la plus intéressante pour un développeur et je suis sur ce projet un peu, voire très, en retard.

Cependant, avec de bons outils, cela peut devenir un peu plus fun.

J’utilise depuis un certain temps déjà le format AsciiDoc et j’ai migré vers AsciiDoctor pour la génération des documents HTML et PDF.

Ce format étant bien reconnu chez GitLab, mon README s’affiche correctement.

Comme un dessin vaut mieux qu’un long discours, j’y intègre du PlantUML pour obtenir quelques diagrammes en seulement quelques lignes de texte.

Et notamment, il y existe une syntaxe pour créer des cartes heuristiques ou mind maps ici. Et bien sûr je n’ai pu résister !

J’en ai ainsi créé une à propos des applications réalisables avec Ada for Automation :

et une autre qui présente le cadriciel lui-même :

Du coup, je me suis aussi mis à documenter les applications de démonstration comme ici ou .

Cordialement,
Stéphane

Raspberry pi : CODESYS & Al.

Bonjour,

Introduction

J’ai préparé une super démo que je devais présenter à des collègues et partenaires mais nous voici confinés et mes présentations devront attendre… Quoique… Quid d’un article ?

Les derniers articles traitaient de Raspberry Pi, de netPI Core / RTE et netIOT Edge « Connect », plateformes matérielles pour le marché industriel développées par Hilscher et basées sur le Raspberry Pi, de Docker, Node-RED, InfluxDB, Grafana et j’avais donc prévu de tester les SoftPLC (automates logiciels) CODESYS ou STRATON.

J’ai ainsi concocté une mixture de tout ceci, avec CODESYS cette fois car ma manipulation inclut le variateur INFRANOR qui se pilote via EtherCAT et que j’ai déjà évoqué ici.

Il se trouve que l’application de contrôle pour le Raspberry Pi dispose de EtherCAT Maitre, entre autres.

On montrera donc :

  • un automate CODESYS pilotant via EtherCAT un variateur INFRANOR,
  • un flow Node-RED avec un tableau de bord qui permet d’interagir avec le variateur via le serveur OPC de CODESYS,
  • ce flow renseigne également une base de données temporelles InfluxDB,
  • et une instance Grafana vient lire les données et les affiche.

Il est tout à fait possible de faire la même chose avec un Rasberry Pi mais par convenance je ferai ma démonstration avec un netPI RTE puisque c’est celui que j’ai sous la main.
Une version netPI Core suffit amplement à ma démo mais bien sûr j’aurais pu utiliser une version netPI Core / RTE ou netIOT Edge « Connect », cette dernière proposant une intégration native de Node-RED avec utilisation du protocole sécurisé HTTPS.

Le plan

Voici donc le plan d’ensemble, the big picture, de la solution envisagée :

CODESYS

J’ai donc suivi pas à pas les instructions pour la création du conteneur CODESYS et installé l’environnement de développement sur mon poste et les paquets runtime et gateway comme demandé.

J’utilise pour ma part l’interface WIFI (wlan0) pour accéder depuis mon PC de développement à la cible CODESYS.

Il est nécessaire d’importer le fichier ESI du variateur dans l’IDE CODESYS et l’on peut alors créer une configuration avec l’EtherCAT Master sur le port LAN (eth0).

On peut configurer les données échangées cycliquement entre l’automate et le variateur :

Mon programme en Structured Text ressemble à de l’Ada, c’est normal. 😉

J’ai défini quelques variables mappées côté EtherCAT :

Et d’autres remontant à l’IHM via le serveur OPC :

Jusque là, ça va :

Docker

Comme je veux que mon conteneur InfluxDB reste isolé du monde extérieur, je crée un réseau « myNet1 » auquel je vais connecter les conteneurs InfluxDB donc, le conteneur Node-RED qui va alimenter la base et le conteneur Grafana qui va y piocher :

J’ai donc créé mes conteneurs en suivant les instructions pour Node-RED, InfluxDB et Grafana en connectant les conteneurs sur mon réseau privé « myNet1 » :

Node-RED

Dans Node-RED, auquel on accède via le port 1880, j’ai ajouté quelques nœuds à ma palette comme node-red-dashboard, node-red-contrib-opcua, node-red-contrib-influxdb :

Puis j’ai développé ce flow qui d’une part communique avec CODESYS en OPC UA et d’autre part avec les composants du tableau de bord.
Il injecte également dans la base InfluxDB les échantillons de la vitesse.

On obtient un magnifique tableau de bord pour piloter le variateur INFRANOR :

On y voit le mode d’opération (3 : boucle de vitesse), la vitesse actuelle sous forme de jauge ou de diagramme, un curseur permettant de modifier la consigne, le mot d’état et pour finir le mot de contrôle.

0, 6, 7, 15… ça tourne ! 128 pour acquitter les défauts.

Et le menu hamburger permet d’accéder directement à la visualisation Grafana qui nous attend sur le port 3000 :

Le flow est disponible ici.

Puisque nous voilà confinés pour un moment, n’est-ce pas l’occasion rêvée de se mettre à l’autoformation ? 😉

Bien sûr, si vous ne disposez pas d’un variateur, tout autre esclave fera l’affaire étant donné que CODESYS supporte plusieurs technologies de bus de terrain sur Ethernet, CAN et liaison série.

Vous pourriez utiliser aussi le netHAT sur le Raspberry Pi, ou le netPI RTE / netIOT Edge « Connect », qui embarque un netX 51 permettant de gérer tous les protocoles sur Ethernet Temps Réel, ce qui autorise plein d’expériences amusantes.

Have fun comme disent nos collègues anglophones.

Cordialement,
Stéphane

A4A : netPI RTE 3

Le netPI RTE 3

Bonjour,

La société Hilscher a conçu une déclinaison industrielle du Raspberry Pi 3, la gamme netPI, aujourd’hui constituée de deux produits, le netPI CORE 3 et le netPI RTE 3.

Ces deux produits partagent donc la même ascendance Raspberry Pi et le netPI RTE 3 apporte en sus une connectivité Ethernet Temps Réel car il dispose d’un système sur puce netX 51.

Le SoC netX 51 est connecté via une liaison SPI haute vitesse à la CPU du Raspberry Pi comme l’est le netX 52 qui équipe le netHAT dont il a déjà été question ici.

Ce même matériel est mis en œuvre dans le netIOT Edge Connect avec une distribution logicielle différente qui se veut plus simple d’utilisation avec Node-RED intégré de base.

Dans l’article précédent je présentais la technologie Docker, intégrée dans tous les produits de la gamme netIOT, avec un exemple « Ada for Automation » et je me propose d’étendre cette démonstration au netPI RTE 3.

Les exemples de code en C

On trouve sur le Hub communautaire une image contenant des exemples d’utilisation du netX 51 pour les protocoles de bus de terrain PROFINET, EtherNet/IP, EtherCAT, POWERLINK et Modbus/TCP.

Il faut noter que le netX 51 est conçu spécifiquement pour gérer des piles de protocoles industriels, cela uniquement en tant qu’esclave. Le cas particulier est celui de Modbus TCP puisqu’il peut être dans ce cas Client et / ou Serveur.

Les sources du Dockerfile sont disponible sur GitHub ici.

Cette image fournit, outre les exemples de code en C, les firmwares qui implémentent les piles de protocoles pour le netX 51 ainsi que le pilote pour Linux qui fournit l’interface applicative cifX. Et bien sûr la documentation qu’il vous faudra étudier avec soin avant de solliciter le support…

L’image de base « Ada for Automation »

Partons de cette image pour créer la notre comme dans ce Dockerfile qui ajoute les outils pour le développement en Ada, la libmodbus, récupère les sources et compile « Ada for Automation » et une application de test basique mettant en œuvre l’API cifX.

#use latest armv7hf compatible raspbian OS version from group balena as base image
#with cifX / netX driver and real-time ethernet programming examples
FROM hilschernetpi/netpi-netx-programming-examples

#enable building ARM container on x86 machinery on the web (comment out next line if built on Raspberry)
#RUN [ "cross-build-start" ]

#labeling
LABEL maintainer="slos@hilscher.com" \
      version="V0.0.1" \
      description="Debian(stretch) / Hilscher netX / Ada for Automation Development"

#version
ENV ADA_FOR_AUTOMATION_HILX_BASIS_DEV_VERSION 0.0.1
   
#install git, gnat and gprbuild
RUN apt-get update  \
    && apt-get install git gnat gprbuild

#install libmodbus
RUN apt-get update  \
    && apt-get install libmodbus5 libmodbus-dev

#install Ada for Automation
RUN mkdir --parents /home/pi/Ada \
    && cd /home/pi/Ada \
    && git clone https://gitlab.com/ada-for-automation/ada-for-automation.git A4A \
    && mkdir A4A/Hilscher

#copy some Hilscher files relating to netX Diag and remote access
COPY ./Hilscher/ /home/pi/Ada/A4A/Hilscher/

#and build some demo applications
RUN cd "/home/pi/Ada/A4A/demo/000 a4a-k0-cli" && make

#SSH port
EXPOSE 22

#the entrypoint shall start ssh
ENTRYPOINT ["/usr/sbin/sshd", "-D"]

#set STOPSGINAL
STOPSIGNAL SIGTERM

#stop processing ARM emulation (comment out next line if built on Raspberry)
#RUN [ "cross-build-end" ]

Construisons l’image :

docker build --tag=netpi-a4a-basis-dev:latest .

On peut tester sur le Raspberry Pi avec le netHAT mais cela demande quelques modifications car, si le pilote Linux fourni dans cette image convient au netHAT, il n’en est pas de même pour les firmwares,les produits étant différents.

Il est donc nécessaire d’adapter en fonction du matériel à sa disposition.

A la création du conteneur, il faut fournir le « device » qui permet la connexion en SPI.

docker container create --publish 22:22 --privileged=true --device=/dev/spidev0.0:/dev/spidev0.0 netpi-a4a-basis-dev:latest

On peut jouer avec le conteneur et, si tout baigne, on tague :

docker tag netpi-a4a-basis-dev soloist/netpi-a4a-basis-dev:latest

Puis on se connecte et on pousse :

docker push soloist/netpi-a4a-basis-dev

L’image « Ada for Automation » Web

Comme dans l’article précédent, l’image suivante rajoute Gnoga et ses dépendances et compile une application de test disposant d’une interface web.

#use latest Ada for Automation Basis Development as base image
FROM soloist/netpi-a4a-basis-dev:latest

#enable building ARM container on x86 machinery on the web (comment out next line if built on Raspberry)
#RUN [ "cross-build-start" ]

#labeling
LABEL maintainer="slos@hilscher.com" \
      version="V0.0.1" \
      description="Debian(stretch) / Hilscher netX / Ada for Automation Web Development"

#version
ENV ADA_FOR_AUTOMATION_HILX_WEB_DEV_VERSION 0.0.1
   
#install Gnoga and dependencies (Simple Components, ZanyBlue)
RUN mkdir --parents /home/pi/Ada/Gnoga \
    && cd /home/pi/Ada/Gnoga \
    && git clone https://git.code.sf.net/p/gnoga/code gnoga \
    && cd /home/pi/Ada/Gnoga/gnoga \
    && make release \
    && make install

#build some Ada for Automation Web demo applications
RUN cd "/home/pi/Ada/A4A/demo/052 a4a_hilscherx_piano" && make

#install the PROFINET IO Device firmware for example
RUN cd "/home/pi/firmwares" \
    && dpkg -i netx-docker-pi-pns-3.12.0.2.deb

#SSH port
EXPOSE 22

#the entrypoint shall start ssh
ENTRYPOINT ["/usr/sbin/sshd", "-D"]

#set STOPSGINAL
STOPSIGNAL SIGTERM

#stop processing ARM emulation (comment out next line if built on Raspberry)
#RUN [ "cross-build-end" ]

Je recommence la séquence en plus condensé…

docker build --tag=netpi-a4a-web-dev:latest .
docker container create --publish 22:22 -p 8090:8090 --privileged=true --device=/dev/spidev0.0:/dev/spidev0.0 netpi-a4a-web-dev:latest
docker tag netpi-a4a-web-dev soloist/netpi-a4a-web-dev:latest
docker push soloist/netpi-a4a-web-dev

Voilà mes images dans les nuages chez Docker Hub.

Portainer

Avec le Raspberry Pi on a accès au système Linux qui fait tourner Docker et on peut donc interagir avec ce dernier en ligne de commande comme nous l’avons fait jusqu’ici.

Sur les cibles netIOT Edge, le système Linux de base est sécurisé et il n’est pas possible d’y accéder. Aussi ces cibles, disposant toutes de Docker, disposent également d’une interface web qui permet l’interaction avec Docker, j’ai nommé Portainer.

On y accède via le portail :

Edge Gateway Manager

Portainer permet entre autres de créer et de gérer images et conteneurs.

Portainer

Mon conteneur créé et démarré, je me connecte en SSH, par exemple avec PuTTY.

Je lance l’application et… ça tombe en marche !

Hilscher fournit le fichier GSDML qui convient pour la configuration du réseau PROFINET avec TIA Portal et on peut visualiser les données échangées dans une table de variables :

TIA Portal

Que l’on peut manipuler depuis l’interface web de l’application :

Piano

L’état de l’application nous montre un comportement temps réel plutôt satisfaisant, ce qui ce conçoit car le système de base est un Linux avec patches PREEMPT_RT et que Docker ne détruit pas les propriétés temps réel.

Piano Status

On peut aussi s’intéresser à la vue d’état cifX :

cifX Status

Ou se connecter avec SYCON.net, l’outil de configuration standard Hilscher car « Ada for Automation » embarque le protocole de diagnostic et accès distant.

SYCON.net Diagnostic

Conclusion

Le netPi est au départ un produit conçu pour connecter les technologies de l’information avec l’opérationnel, soit IT/OT, et gérer localement des données pour les trier, les agréger, les mettre en forme, etc…

Ainsi l’on a l’embarras du choix pour acquérir et traiter ces données.

Au niveau acquisition avec les différents interfaces (LAN, WiFi, RTE, RS 432/422/485…) et protocoles de communication disponibles comme au niveau traitement avec Node-RED, tous les langages disponibles dans Linux (C, Python, Java…), des standards de l’automatisme comme CODESYS ou STRATON, et bien sûr « Ada for Automation », l’éclectisme est de mise à tous les étages et la liberté offerte par cette plateforme la rend propice à toutes les expérimentations et réalisations industrielles.

Cordialement,
Stéphane

A4A : Conteneur Docker

Bonjour,

Docker

J’indiquais dans l’article précédent que, sur les solutions netIOT Edge de Hilscher, Docker permet d’intégrer toutes sortes d’applications pour traiter les données acquises depuis le terrain ou le process avant de fournir celles-ci digérées aux applications hébergées dans le fameux nuage d’où doit pleuvoir la manne.

C’est aussi valable pour le netPI comme pour le Raspberry Pi sur lequel il est tout à fait possible d’installer Docker.

Il est bien sûr indispensable de se familiariser avec Docker puis de consulter la documentation pour comprendre les concepts.

Avec Docker, une application est empaquetée avec l’environnement nécessaire à son exécution dans une image que l’on va pouvoir instancier en conteneur(s) que Docker va exécuter.

On peut voir cela comme une approche composant où l’on isole chaque application et son environnement.

Pour le netPI, Hilscher offre nombre d’images prêtes à l’emploi sur le Hub communautaire où figurent également la plupart des projets  open source.

Ces images sont construites à partir de recettes, les docker files, et tous les fichiers pour les images fournies sont disponibles sur GitHub.

Dockerfile

Afin de me former sur ces technologies bien attirantes il m’est apparu que j’avais un projet candidat à la conteneurisation, Ada for Automation bien sûr !

J’ai donc installé Docker sur mon Raspberry Pi et, en m’inspirant des Dockerfiles de mes collègues, j’en ai écrit un basique que je vous présente ci-dessous.

#use latest armv7hf compatible raspbian OS version from group balena as base image
FROM balenalib/armv7hf-debian:stretch

#enable building ARM container on x86 machinery on the web (comment out next line if built on Raspberry)
#RUN [ "cross-build-start" ]

#labeling
LABEL maintainer="slos@hilscher.com" \
      version="V0.0.1" \
      description="Debian(stretch) / Ada for Automation Development"

#version
ENV ADA_FOR_AUTOMATION_BASIS_DEV_VERSION 0.0.1

#install ssh, gcc, create user "pi" and make him sudo
RUN apt-get update  \
    && apt-get install -y openssh-server build-essential \
    && mkdir /var/run/sshd \
    && useradd --create-home --shell /bin/bash pi \
    && echo 'pi:raspberry' | chpasswd \
    && adduser pi sudo
   
#install git, gnat and gprbuild
RUN apt-get update  \
    && apt-get install git gnat gprbuild

#install libmodbus
RUN apt-get update  \
    && apt-get install libmodbus5 libmodbus-dev

#install Ada for Automation and build some demo applications
RUN mkdir --parents /home/pi/Ada \
    && cd /home/pi/Ada \
    && git clone https://gitlab.com/ada-for-automation/ada-for-automation.git A4A \
    && cd "/home/pi/Ada/A4A/demo/000 a4a-k0-cli" && make

#SSH port
EXPOSE 22

#the entrypoint shall start ssh
ENTRYPOINT ["/usr/sbin/sshd", "-D"]

#set STOPSGINAL
STOPSIGNAL SIGTERM

#stop processing ARM emulation (comment out next line if built on Raspberry)
#RUN [ "cross-build-end" ]

Celui-ci, à partir d’une debian stretch, installe SSH, GCC, Git, les outils pour Ada GNAT, GPRBuild, et la librairie libmodbus.

Pour finir, il tire « Ada for Automation » depuis gitlab et compile la plus simple des applications qui implémente un serveur Modbus TCP et recopie quelques registres en entrée sur quelques registres en sortie.

Image

Construire l’image est trivial. Depuis le répertoire contenant le Dockerfile, il suffit de saisir la commande :

docker build --tag=rpi-a4a-basis-dev:latest .

Cette commande construit donc une image ayant pour nom « rpi-a4a-basis-dev » et taguée « latest » depuis le répertoire courant.

La commande suivante permet de lister les images produites :

docker image ls -a

Conteneur

On peut bien sûr créer aussitôt un conteneur à partir de cette image avec la commande suivante :

docker container create --publish 22:22 -p 1503:1503 --privileged rpi-a4a-basis-dev:latest

On publie le port 22 pour SSH et le port 1503 pour Modbus TCP Serveur et on octroie le privilège de pouvoir tourner avec une priorité temps réel si nécessaire.

Notre conteneur est créé comme nous pouvons le constater avec la commande qui nous donne le nom qui lui a été affecté automatiquement :

docker container ls -a

Et on peut s’en servir dès à présent :

docker container start <nom_du_conteneur>

Un ssh en local ou distant permet de se connecter à notre conteneur, de naviguer en ligne de commande dans l’arborescence et de démarrer l’application de démonstration.

Empiler

Notre conteneur basique permet de réaliser des applications avec une interface en ligne de commande, sans interface graphique basée sur GtkAda ou Gnoga.

Avec Docker, il est facile d’empiler une nouvelle couche pour étendre la fonctionnalité.

Ainsi, le dockerfile suivant ajoute à l’image de base Gnoga et ses dépendances, SimpleComponents et Zanyblue, et compile l’application A4A_Piano qui dispose d’une interface web.

#use latest Ada for Automation Basis Development as base image
FROM rpi-a4a-basis-dev:latest

#enable building ARM container on x86 machinery on the web (comment out next line if built on Raspberry)
#RUN [ "cross-build-start" ]

#labeling
LABEL maintainer="slos@hilscher.com" \
      version="V0.0.1" \
      description="Debian(stretch) / Ada for Automation Web Development"

#version
ENV ADA_FOR_AUTOMATION_WEB_DEV_VERSION 0.0.1

#install Gnoga and dependencies (Simple Components, ZanyBlue)
RUN mkdir --parents /home/pi/Ada/Gnoga \
    && cd /home/pi/Ada/Gnoga \
    && git clone https://git.code.sf.net/p/gnoga/code gnoga \
    && cd /home/pi/Ada/Gnoga/gnoga \
    && make release \
    && make install

#build some Ada for Automation Web demo applications
RUN cd "/home/pi/Ada/A4A/demo/010 a4a_piano" && make

#SSH port
EXPOSE 22

#the entrypoint shall start ssh
ENTRYPOINT ["/usr/sbin/sshd", "-D"]

#set STOPSGINAL
STOPSIGNAL SIGTERM

#stop processing ARM emulation (comment out next line if built on Raspberry)
#RUN [ "cross-build-end" ]

On construit l’image de la même façon que la précédente :

docker build --tag=rpi-a4a-web-dev:latest .

Puis on crée le conteneur avec un port supplémentaire pour le serveur web intégré :

docker container create --publish 22:22 -p 1504:1504 -p 8081:8081 --privileged rpi-a4a-web-dev:latest

On démarre le conteneur :

docker container start <nom_du_conteneur>

Un ssh en local ou distant permet de se connecter à notre conteneur, de naviguer en ligne de commande dans l’arborescence et de démarrer l’application de démonstration.

Et en pointant un navigateur sur l’adresse du site on trouve les pages attendues !

Tandis qu’on peut jouer avec :

Il ne me reste plus qu’à y envoyer dans mon espace du Hub Docker.

Taguons nos images :

docker tag rpi-a4a-basis-dev soloist/rpi-a4a-basis-dev:latest
docker tag rpi-a4a-web-dev soloist/rpi-a4a-web-dev:latest

Connectons nous :

docker login

Et poussons :

docker push soloist/rpi-a4a-basis-dev
docker push soloist/rpi-a4a-web-dev

C’est prêt pour une utilisation avec votre Raspberry Pi ou le netPI !

Cordialement,
Stéphane