Archives par mot-clé : Modbus

Raspberry Pi 3 / SenseHAT / netHAT / netPi

Bonjour,

Je cherchais pour mes expériences une solution qui soit ludique, et aussi accessible à tout un chacun, et mes tribulations m’ont conduit à sélectionner un combo Raspberry Pi 3 + SenseHAT.

Hilscher France a donc fait l’acquisition de ces éléments chez KUBII :

Starter Kit Officiel Pi3
https://www.kubii.fr/fr/kits-raspberry-pi/1637-kit-demarrage-raspberry-pi3-3272496004207.html

Raspberry Pi Sense Hat
https://www.kubii.fr/fr/cartes-extension-cameras-raspberry-pi/1081-raspberry-pi-sense-hat-640522710799.html

Pourquoi donc un tel investissement me direz vous ?

Sans doute parce que depuis quelques temps cette plateforme économique et performante permet d’imaginer tout un tas d’utilisations dans ce qu’il est convenu d’appeler l’IoT, l’IIoT, Industry 4.0, etc…

Aussi, à l’instar de certains confrères, la société Hilscher a développé certains produits autour de cette plateforme comme le netHAT, le netPi et le Edge Gateway « Connect » :
https://www.netiot.com/interface/nethat/
https://www.netiot.com/netpi/industrial-raspberry-pi-3/
https://www.netiot.com/edge/

Hilscher innove en testant le canal de vente Amazon et l’on peut y acheter le netHAT et le netPi :
https://www.amazon.fr/Hilscher-NXHAT52-RTE-nethat-52-de-RTE/dp/B01MFH0FP9
https://www.amazon.fr/Industrial-Raspberry-Industry-Communication-4×1-2Ghz-Real-Time-Ethernet/dp/B0756XD2CN

Pour ces produits, Hilscher France n’assure pas de support.
Cependant, l’on peut vous proposer une formation !

Le netHAT est fourni avec un pilote Linux compilé, des firmwares en version limitée à 32 octets d’E/S pour EtherCAT, Ethernet/IP et PROFINET IO Device et bien sûr de la documentation.

Le tout s’installe sans encombre sur la Raspbian et ça tombe en marche comme sur le plan.

Vous pouvez donc vous familiariser avec la technologie Hilscher pour une quarantaine d’euros, ce qui est modique vous en conviendrez aisément.

Bien sûr, « Ada for Automation » peut tout à fait être utilisé avec le netHAT. J’y reviendrai bien sûr.

Avec un Raspberry Pi + un netHAT, on peut aussi tester le concept netPi et développer des applications qui tourneront sur le netPi sans modification.

Bref, je souhaitais monter une manipulation avec un Rasberry Pi 3, un SenseHAT pour des capteurs pas chers et un netHAT pour connecter ce bijou de technologie à votre automate préféré.

En fait, le SenseHAT et le netHAT ne peuvent pas se monter l’un sur l’autre comme on pourrait le penser de prime abord.

Je pensais développer un binding Ada pour le SenseHAT mais ce n’est pas si simple.
Le langage choisi par l’équipe Raspberry est plutôt le Python et la plupart des bibliothèques fournies pour les « HAT » sont en Python.
La bibliothèque disponible pour le SenseHAT est donc en Python aussi et utilise d’une part une bibliothèque en C++ qui gère nombre de capteurs et d’autre part le framebuffer pour les LEDs et un IO device pour le joystick.

Monsieur Phil Munts, que je remercie, m’a bien fait part de sa librairie :
http://git.munts.com/libsimpleio/ada/

Mais je voulais quelque chose de super vite fait et j’ai penché pour une solution mettant en œuvre un framework Modbus développé par un collègue, Monsieur Luc JEAN, que je remercie chaleureusement :
https://github.com/ljean/modbus-tk

Pourquoi donc ? « Ada for Automation » disposant de la fonctionnalité Modbus TCP Client et le framework permettant de réaliser très simplement un serveur Modbus TCP, il suffisait donc de raccrocher les données des capteurs dans les registres du serveur.

J’ai utilisé également ce bout de code qui m’a bien aidé, je remercie aussi son auteur :
https://frank-deng.github.io/python-kbhit.en.html

Le SenseHAT dispose d’une application de simulation avec interface graphique et il est possible d’utiliser celle-ci en lieu et place du matériel tel que dans l’exemple suivant.

SenseHAT Simu GUI
SenseHAT Simu GUI

On y démarre depuis un terminal :

python 3 sense-omb.py
python 3 sense-omb.py

Et on teste par exemple avec Modbus Poll :

Modbus Poll Example
Modbus Poll Example

En Python, c’est une vingtaine de lignes de code pour remonter température, pression, hygrométrie et cap :

#!/usr/bin/env python
# -*- coding: utf_8 -*-
"""
 Modbus TestKit: Implementation of Modbus protocol in python

 (C)2009 - Luc Jean - luc.jean@gmail.com
 (C)2009 - Apidev - http://www.apidev.fr

 This is distributed under GNU LGPL license, see license.txt
"""


import sys
import struct

import modbus_tk
import modbus_tk.defines as cst
from modbus_tk import modbus_tcp

from sense_emu import SenseHat

import kbhit, time;

sense = SenseHat()

def main():
    """main"""

    kbhit.init();
    running = True;

    logger = modbus_tk.utils.create_logger(name="console", record_format="%(message)s")

    try:
        #Create the server
        server = modbus_tcp.TcpServer(port=1502)
        logger.info("running...")
        logger.info("enter 'q' for closing the server")

        server.start()

        slave_1 = server.add_slave(1)
        slave_1.add_block('0', cst.HOLDING_REGISTERS, 0, 100)

        while running:
            if kbhit.kbhit():
                ch = kbhit.getch();
                if 'q' == ch:
                    running = False;

            slave_1.set_values('0', 0, struct.unpack('>HH', struct.pack('>f', sense.temp)))
            slave_1.set_values('0', 2, struct.unpack('>HH', struct.pack('>f', sense.pressure)))
            slave_1.set_values('0', 4, struct.unpack('>HH', struct.pack('>f', sense.humidity)))
            slave_1.set_values('0', 6, struct.unpack('>HH', struct.pack('>f', sense.compass)))

            time.sleep(0.1);

    finally:
        server.stop()
        kbhit.restore();

if __name__ == "__main__":
    main()

C’est naturellement pas très temps réel mais c’est très bien pour mon cas d’école.

Et en plus, on peut facilement imaginer de reproduire ce schéma avec d’autres HATs comme le « Automation HAT » par exemple :
https://shop.pimoroni.com/products/automation-hat

Vous pouvez donc remonter les données du SenseHAT vers votre automate préféré disposant d’une connectivité Modbus TCP Client.
Bon, en travaillant un peu, ça doit fonctionner dans les deux sens, hein !

Quid du netHAT ? Si on utilise l’application de simulation SenseHAT on peut bien sûr le mettre sur le même Raspberry Pi et se connecter en local.
Si l’on souhaite de vraies données physiques, il faudra l’installer sur un autre Raspberry Pi, et le faire communiquer avec le premier, toujours en Modbus TCP.
C’est trivial avec « Ada for Automation » et je vous le montrerai ce tantôt.

Cordialement,
Stéphane

Un portail de démo pour « Ada for Automation »

Bonjour,

Il a déjà été question dans ces pages de « Ada for Automation » dans le nuage et le site consacré à Gnoga montre un usage du serveur Apache configuré comme frontal (proxy) de démonstration.

J’ai donc marché dans les pas de Gnoga et créé également un portail de démonstration pour « Ada for Automation ».

Ainsi, ce portail présente quelques applications mettant en œuvre bien sûr les technologies web déjà mentionnées, du Modbus TCP en Client / Serveur grâce à libmodbus, et du PROFINET IO Contrôleur et Équipement (Device).

L’on pourra donc interagir avec :

  • une application basique Modbus TCP en Client / Serveur supervisant et contrôlant un « piano » Modbus TCP Serveur,
  • l’application historique App1, Modbus TCP en Client / Serveur, supervisant et contrôlant une application Modbus TCP Serveur simulant la partie opérante,
  • une application basique pilotant en PROFINET le fameux « piano ».

Les deux premières démonstrations ont lieu entièrement dans le cloud, comme évoqué dans les articles précédents.

Pour la troisième démonstration où l’on met en œuvre l’API Hilscher cifX, on utilise un PC industriel sous Debian Linux dans lequel une carte cifX est configurée en contrôleur PROFINET IO et un Raspberry Pi (Raspbian) connecté via une liaison SPI à une carte d’évaluation netRAPID configurée en PROFINET IO Device.

On a donc une application « Ada for Automation » sur le PC au-dessus de la cifX et une autre sur le Raspberry Pi au-dessus du netRAPID, communiquant via la même API.
Ne manquez pas de visiter depuis le menu de l’application les pages d’état où l’on reconnaîtra en particulier les informations du « Common Status » pour l’API cifX.

Cette POC (Proof Of Concept) ne demande qu’à être étoffée.
Faute de matériel plus divers, je pense par exemple à une démonstration tout aussi peu palpable avec l’implémentation Hilscher de PROFIdrive.
Il vous serait ainsi offert de piloter un variateur virtuel dans le cloud, ce qui, admettez, est un peu perché.

Il serait tout aussi possible d’envisager une démonstration avec l’une des nombreuses autres technologies de bus de terrain supportées par Hilscher.

Ouvert à toute forme de collaboration, n’hésitez pas à me faire part de vos besoins si vous souhaitez une manipulation avec un matériel quelconque de votre fourniture.

Cordialement,
Stéphane

A4A : Toujours dans les nuages

Bonjour,

L’article précédent était consacré à la mise en orbite basse de « Ada for Automation ».

Il me tenait à cœur d’obtenir rapidement une fonctionnalité identique à celle de cette même application de démonstration « App1 » munie de son interface en GtkAda.

J’ai donc rajouté, tant pour l’application « App1 » que pour l’application de simulation de la partie opérante « App1simu » les pages présentant l’état général de l’application, l’état du serveur Modbus TCP et, pour « App1 », l’état des clients Modbus TCP.

On a donc pour l’application « App1 » elle-même :

Et pour la simulation de la partie opérante :

Cela m’a permis de vérifier la pertinence de la solution Gnoga, que ce soit pour attacher des éléments déjà disponibles dans une page HTML + SVG à des objets de l’application écrite en Ada comme pour la vue synoptique principale ou les pages « état général » et « état du serveur Modbus TCP », ou pour créer des pages dynamiques comme pour la page d’état des clients Modbus TCP.

En effet, cette page s’adapte automatiquement en fonction de la configuration de la scrutation des serveurs Modbus TCP ou « IO Scanning » définie dans le code suivant :

------------------------------------------------------------------------------
--                            Ada for Automation                            --
--                                                                          --
--                   Copyright (C) 2012-2016, Stephane LOS                  --
--                                                                          --
-- This library is free software;  you can redistribute it and/or modify it --
-- under terms of the  GNU General Public License  as published by the Free --
-- Software  Foundation;  either version 3,  or (at your  option) any later --
-- version. This library is distributed in the hope that it will be useful, --
-- but WITHOUT ANY WARRANTY;  without even the implied warranty of MERCHAN- --
-- TABILITY or FITNESS FOR A PARTICULAR PURPOSE.                            --
--                                                                          --
-- As a special exception under Section 7 of GPL version 3, you are granted --
-- additional permissions described in the GCC Runtime Library Exception,   --
-- version 3.1, as published by the Free Software Foundation.               --
--                                                                          --
-- You should have received a copy of the GNU General Public License and    --
-- a copy of the GCC Runtime Library Exception along with this program;     --
-- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see    --
-- <http://www.gnu.org/licenses/>.                                          --
--                                                                          --
------------------------------------------------------------------------------

with A4A.MBTCP_Client; use A4A.MBTCP_Client;
with A4A.Protocols; use A4A.Protocols.IP_Address_Strings;
with A4A.Protocols.LibModbus; use A4A.Protocols.LibModbus;

package A4A.Application.MBTCP_Clients_Config is

   --------------------------------------------------------------------
   --  Modbus TCP Clients configuration
   --------------------------------------------------------------------

   --  For each Modbus TCP Server define one client configuration task

   Config1 : aliased Client_Configuration :=
     (Command_Number    => 11,
      Enabled           => True,
      Debug_On          => False,
      Task_Period_MS    => 10,
      Retries           => 3,
      Timeout           => 0.2,

      Server_IP_Address => To_Bounded_String ("127.0.0.1"),
      --  127.0.0.1 / 192.168.0.100

      Server_TCP_Port   => 1504,
      --  502 Standard / 1502 PLC Simu / 1504 App1Simu

      Commands =>
        (
         --                                Period              Offset Offset
         --               Action Enabled Multiple Shift Number Remote  Local
         1 =>
           (Read_Input_Registers,   True,      10,    0,    10,     0,     0),
         2 =>
           (Read_Registers,         True,      20,    0,    10,     0,    10),
         3 =>
           (Write_Registers,        True,      30,    0,    20,    20,     0),
         4 =>
           (Read_Bits,              True,      30,    1,    16,     0,     0),
         5 =>
           (Read_Input_Bits,        True,      30,    2,    16,     0,    32),
         6 =>
           (Write_Register,         True,      30,    3,     1,    50,    30),
         7 =>
           (Write_Bit,              True,      30,    4,     1,     0,     0),
         8 =>
           (Write_Bits,             True,      30,    5,    15,     1,     1),

         9 => (Action              => Write_Read_Registers,
               Enabled             => True,
               Period_Multiple     => 10,
               Shift               =>  5,
               Write_Number        => 10,
               Write_Offset_Remote => 40,
               Write_Offset_Local  => 20,
               Read_Number         => 10,
               Read_Offset_Remote  => 10,
               Read_Offset_Local   => 20),
         10 =>
           (Read_Registers,         True,      50,    0,    10,   100,   100),
         11 =>
           (Read_Registers,         True,      50,    1,    10,   110,   110)
        )
     );

   Config2 : aliased Client_Configuration :=
     (Command_Number    => 2,
      Enabled           => False,
      Debug_On          => False,
      Task_Period_MS    => 100,
      Retries           => 3,
      Timeout           => 0.2,

      Server_IP_Address => To_Bounded_String ("127.0.0.1"),
      Server_TCP_Port   => 1503, -- My own MBTCP server

      Commands =>
        (
         --                                Period              Offset Offset
         --               Action Enabled Multiple Shift Number Remote  Local
         1 =>
           (Read_Registers,         True,      10,    0,    10,     0,     0),
         2 =>
           (Write_Registers,        True,      30,    1,    10,     0,     0)
        )
     );

   --  Declare all clients configuration in the array
   --  The kernel will create those clients accordingly

   MBTCP_Clients_Configuration : Client_Configuration_Access_Array :=
     (1 => Config1'Access,
      2 => Config2'Access);

end A4A.Application.MBTCP_Clients_Config;

Ainsi, pour chaque serveur scruté, une tâche cliente est créée qui va exécuter cycliquement les commandes renseignées dans le tableau de configuration.

La page sera donc automatiquement ajustée en créant dynamiquement les sections relatives aux tâches clientes avec une table d’état des commandes tout aussi adaptée.

Et comme l’on utilise que du HTML5, du SVG et des feuilles de style CSS3, l’application peut changer de « look » sans avoir besoin de recompiler celle-ci.

D’ailleurs, comme je n’ai aucune prétention concernant mes talents en design, j’accepte bien volontiers toute suggestion dans ce domaine.

En éternel débutant, tous vos commentaires et / ou suggestions sont bien sûr les bienvenus.

Cordialement,
Stéphane

« Ada for Automation » in the cloud !

Bonjour,

J’évoque ça et là le projet « Ada for Automation » mais seuls le code source et les articles sur ce blog, dans lesquels figurent quelques copies d’écran et photos, ainsi qu’une documentation incomplète, étaient disponibles jusqu’alors.

J’étais bien présent au JDLL mais pas vous (ou nous nous sommes ratés…) et / ou vous n’avez pu assister aux démonstrations et conférence…

Pour ceux intéressés, qui souhaiteraient y voir fonctionner mais sans passer trop de temps en téléchargement, installation d’outils, compilation et mise en œuvre, ainsi que pour les tests et démonstrations, j’ai installé dans le nuage une machine virtuelle, qui exécute une Debian Jessie 64 bits, et une paire d’applications très simples avec une interface web fondée sur Gnoga dont il a déjà été question notamment ici.

"Ada for Automation" in the cloud !
« Ada for Automation » in the cloud !

Merci à ceux qui rendent cette chose possible, je pense notamment aux auteurs et contributeurs du logiciel libre.

Voici donc l’application 1 :
http://ada4automation.slo-ist.fr:8080

Et vu qu’on est dans le virtuel une simulation de la partie opérante :
http://ada4automation.slo-ist.fr:8081

Ces deux applications échangent leurs données via le protocole Modbus TCP grâce à libmodbus.

Chacune intègre son propre serveur web auquel on a affecté un port différent du port standard (le port 80).
On accède donc aux pages en spécifiant l’adresse et le port comme dans les liens fournis.

Normalement, si l’application de simulation est correctement pilotée, tout est en Auto et l’eau arrive toute seule de la vanne.
En fonction des seuils sur le niveau, la vanne s’ouvre et se ferme et la pompe tourne ou s’arrête.

En mode Manu, il est possible de piloter les actionneurs directement depuis l’interface.

En survolant les éléments, ceux qui peuvent être manœuvrés disposent d’une infobulle, sont mis en évidence et le curseur change également.
La documentation n’est plus trop à jour malheureusement, j’y travaille.
Au cas où vous souhaiteriez quelques explications, une aide en ligne est disponible.

C’est juste une démonstration. Cela devrait s’étoffer. On est à Lyon tout de même…
J’apprends encore Ada, les technologies web, linux…, bref, tout, donc ne soyez pas méchants.

Commentaires et suggestions bienvenus !

Cordialement,
Stéphane

A4A : Modbus TCP Server + Web HMI = A4A_Piano

Bonjour,

J’évoquais ce tantôt en fin d’article une application mêlant un serveur Modbus TCP et une IHM Web pour constituer un « piano » pour mes essais et démonstrations.

Cette application s’appuie donc sur le framework Gnoga qui permet de réaliser des IHM Web entre autres. Gnoga, de Monsieur David Botton, intègre également les Simple Components de Monsieur Dmitry Kasakov qui fournissent entre autres le serveur web embarqué dans l’application.

Gnoga permet la création dynamique de contenu web et l’animation des pages depuis une application écrite en Ada.

En ce moment je joue beaucoup avec Inkscape qui permet plein de fantaisie dans l’édition au format SVG de graphiques vectoriels.
C’est bien sûr intéressant pour dessiner des synoptiques que l’on pourra animer relativement facilement et cela permet aussi de faire un beau schéma :

Structure de l'application A4A_Piano
Structure de l’application A4A_Piano

L’application « A4A_Piano » met en œuvre le noyau « kernel0 » qui intègre seulement un serveur Modbus TCP, fourni par libmodbus, et une tâche principale ainsi qu’une tâche périodique.
Le noyau gère les échanges entre les tâches et le serveur Modbus TCP, la tâche principale appelle la fonction principale du programme utilisateur, la tâche périodique appelle la fonction périodique du programme utilisateur.
Le programme utilisateur est en charge de la gestion des échanges entre les zones mémoire E/S et les objets utilisateur ainsi que du traitement de ces objets.
C’est de l’histoire ancienne.

L’IHM Web est composée d’une part des vues affichées dans le / les navigateurs, ces vues étant constituées naturellement de technologies Web telles HTML 5, CSS, SVG et JavaScript, et d’une contrepartie en Ada fondée sur le patron de conception Modèle-Vue-Contrôleur un peu bricolé.

Tel que réalisé dans « A4A_Piano », le code HTML est juste une amorce, le SVG et le CSS ont été écrits à la main, je vous conseille la lecture des tutoriels de Monsieur Jenkov, courts et efficaces.
Avec un peu d’habitude on arrive à faire de belles choses avec SVG et Inkscape et on peut alors penser plus grand.

En fait, plutôt que de tout piloter d’un côté ou de l’autre, j’ai pris le parti de laisser l’aspect graphique côté technologies Web et de n’agir que sur un attribut d’état. En fonction de l’état, le CSS fait le reste pour l’animation.

Chaque objet de synoptique HTML ou SVG que l’on souhaite animer dispose d’un identifiant dont on pourra se servir pour le connecter à un pendant « View », un objet dérivé des objets fournis par Gnoga.
Pour chaque connexion on va instancier une collections d’objets « View » ainsi qu’une tâche gérant le rafraîchissement.

Ces objets « View » gèrent la mise à jour des objets HTML ou SVG auxquels on les a connectés à la création de la connexion ainsi que l’interaction avec l’utilisateur, c’est à dire les « Cliques » souris par exemple.
D’un autre côté on les a également connectés avec un objet « Controller » dont le rôle est d’une part de servir de proxy aux objets « View » et de gérer l’accès en lecture / écriture des données utilisateur.
La tâche « Scanner » va piloter elle le rafraîchissement des « Controllers ».

Le code n’est sans doute pas optimal mais il est quand même disponible dans le dépôt comme d’habitude.

Pour information, j’espère bien vous voir à ces 17èmes Journées du Logiciel Libre…
D’autant plus que les Gentils Organisateurs ont bien voulu m’accorder la faveur insigne d’un stand pour la présentation du projet « Ada for Automation » !

JDLL2016

Cordialement,
Stéphane