Archives par mot-clé : PROFINET

A4A : Raspberry Pi 3 / netHAT / PROFINET IO

Bonjour,

Je disais donc dans mon dernier article qu’il fallait que je vous fasse une petite démonstration de l’utilisation du netHAT Hilscher avec un Raspberry Pi 3 et « Ada for Automation ».

Voilà donc une copie d’écran montrant l’application piano connectée, via le netHAT configuré en PROFINET IO Device, à un automate SIEMENS S7 1500-PN PROFINET IO Contrôleur :

Raspberry Pi 3 Ada for Automation netHAT
Raspberry Pi 3 Ada for Automation netHAT

On reconnait dans cette vue de TIA Portal les valeurs d’E/S affichées dans la vue ci-dessus, les bits de poids faible sont à gauche dans la vue du piano (b0 .. b7) :

netHAT TIA Portal Visu
netHAT TIA Portal Visu

La vue d’état cifX montre donc l’état du netHAT puisque celui-ci partage avec celle-ci, comme la plupart des produits Hilscher, l’API cifX, la Dual Port Memory, les piles de protocoles et l’OS.

La seule subtilité que j’ai rencontrée, c’est que la version du pilote Linux livrée avec le netHAT est plus récente que celle que j’utilisais jusqu’alors (la V1.1.0.0) et que l’architecture en a été revue.
En substance, un plugin permet maintenant de gérer la connexion via SPI et il n’est plus nécessaire de le gérer côté application. Le netHAT est directement vu comme une cifX.

netHAT cifX Status
netHAT cifX Status

Bien sûr, tout baigne côté automate aussi !

netHAT TIA Portal Network
netHAT TIA Portal Network

Une petite formation ? 😉

Cordialement,
Stéphane

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 : Ada – Raspberry Pi – netRAPID

Bonjour,

Je continue mes expériences avec le Raspberry Pi qu’on m’a prété et dont il a déjà été question dans l’article mettant en scène le netHOST.

Avec le netHOST, la communication s’établissait via une connexion TCP/IP. Dans cet article, nous allons établir une connexion avec un netRAPID via l’interface SPI disponible sur le connecteur d’extension du Raspberry Pi.

On voit sur la photo suivante à gauche le Raspberry Pi et à droite une carte d’évaluation équipée d’un netRAPID, l’espèce de timbre au centre, le tout connecté via SPI, les cinq fils noirs.

2015-11-27 16.36.15

La famille de « System on Chip » netX qui équipe tous les produits de la société Hilscher s’est étoffée avec les successeurs du netX 50 que sont les netX 51 et netX 52.
Avec le netX 10, ces SoC possèdent entre autres une interface Fast SPI qui permet via un composant matériel dédié, la SPM – pour Serial Port Memory – d’accéder à la désormais fameuse Dual Port Memory via une interface sérielle plutôt que par les traditionnels bus d’adresse et bus de données.

Cela permet d’utiliser comme processeurs hôtes des puces de surface réduite, plus économiques, et conduit à des solutions plus compactes.

Les netX 51 et 52 se distinguent de leur prédécesseur le netX 50 par leur capacité mémoire interne étendue qui permet d’exécuter les piles de protocoles optimisées sans nécessiter de mémoire RAM externe. Le netX 52 dispose de la même architecture interne que le netX 51 à ceci près qu’on lui a ôté le bus mémoire externe afin de réduire son empreinte et son coût.

Ainsi le netX 51 équipe par exemple le comX 51-CA-RE qui permet d’exécuter toutes les piles de protocoles Ethernet Temps Réel en mode esclave avec une fonctionnalité complète.

Les netX 51 et 52 disposent de deux canaux de communication tandis que le netX 10 en possède un seul. Ils sont prévus pour exécuter les piles de protocoles en version esclave uniquement.

On trouve le netX 10 équipant les comX 10 pour l’exécution des piles PROFIBUS DP, CC-Link, DeviceNet et CANopen esclaves.

Les solutions modulaires comX conviennent lorsque l’on recherche une solution de connexion aux bus de terrain interchangeable. Avec leur connecteur Hôte commun à toutes les versions et leur API également commune, il est aisé de les installer en fonction du besoin d’autant qu’ils fournissent de surcroît l’interface au bus avec l’isolation galvanique et la connectique.

Il est possible également de développer des équipements intégrant les SoC netX en tant que coprocesseur de communication lorsque le volume devient important et que les objectifs de coût le nécessitent. Cela demande cependant autrement plus d’effort que pour la mise en oeuvre d’un module comX.

Afin de faciliter la tâche des électroniciens et diminuer le « Time to Market » la société Hilscher a développé le netRAPID, une solution de module à souder directement sur le PCB comme un composant CMS. Il est également possible de le souder à la main lors de la réalisation de prototypes.

Le netRAPID contient tous les éléments actifs, le chip netX lui-même, un netX 10 pour les versions bus de terrain classiques ou un netX 52 pour les versions Ethernet Temps Réel, la Flash nécessaire au stockage du firmware et éventuellement de la configuration, les composants générant les tensions pour le cœur processeur et celles pour le bus de terrain, l’isolation galvanique…

Pour l’interface avec l’hôte, le netRAPID dispose de la classique DPM accessible sur l’interface parallèle ou sur l’interface SPI, celle qui nous intéresse pour cet article.

Et voilà où je voulais en venir !

Du point de vue applicatif, que ce soit une cifX, un comX ou un netRAPID, c’est du pareil au même. L’interface applicative est identique.

Hilscher fournit les pilotes pour tous les systèmes d’exploitation du marché dont Linux. Avec ce pilote, il est possible d’accéder à tous les produits de la gamme, que ce soit au travers d’une interface ISA, PCI, PCIExpress, DPM ou SPI.

Il est également fourni des exemples d’utilisation, notamment pour SPI, dont je me suis plus que largement inspiré pour y connecter avec « Ada for Automation ».

Taaa taaan ! Voilà, c’est dit !
Il est à présent possible de connecter un netRAPID sur un Raspberry Pi via SPI et de développer une application esclave sur un bus de terrain avec « Ada for Automation ».

Sur cette vue on distingue au fond l’IDE GNAT Pro Studio, à droite le terminal d’où on a lancé l’application et la trace résultante et à gauche en bas l’interface graphique de l’application.

Vue globale du bureau
Vue globale du bureau

La vue d’état montrant l’exécution d’un firmware PROFINET IO Device sur le netRAPID.

netRAPID cifX Status
cifX Status

Bon, il est aussi possible de développer en C/C++ hein…

D’un point de vue pratique, la carte d’évaluation du netRAPID dispose de broches de test sur l’interface hôte que j’ai connectées directement avec celles en regard sur le port d’extension du Raspberry Pi. En tout et pour tout cinq petits fils.

Si vous cherchez le brochage du port d’extension du Raspberry Pi ne cherchez plus. Monsieur Christophe BLAESS en fournit ce qu’il faut pour notre besoin du jour :
http://www.blaess.fr/christophe/2012/11/02/spi-sur-raspberry-pi-1/#more-3043

A cela près que mon ami Marco Buffa de Hilscher Italy m’a bien aidé en me procurant les dits fils dont un, le MISO dispose d’une résistance de 120 Ohms car sinon il y a quelques perturbations sur la ligne. Il m’a également donné une carte d’évaluation comX de sa conception que je vous présenterai sans doute prochainement.

Il vous faudra acquérir auprès de Hilscher France le pilote Linux qui est fourni sous forme de code source et le compiler sur le Raspberry Pi avec les bonnes options pour activer les fonctions de lecture et écriture de la SPM.
C’est trivial et je suis là en cas de besoin. Ce pilote n’est à acheter qu’une fois.

Après, hormis les fonctions d’initialisation / dés-initialisation du pilote qui sont différentes, le reste de l’API est identique et l’on se sert du netRAPID comme d’un comX ou d’une cifX.

Pour l’initialisation du pilote, il suffit de fournir le « device » qui va bien (i.e. « /dev/devspi0.0 » dans mon cas puisque j’ai connecté le Chip Select 0), et de spécifier la vitesse de transmission (le netX supporte jusqu’à 33 MHz en mode esclave, j’ai testé avec 16 MHz).

On aura au préalable activé la liaison SPI par exemple avec raspi-config dans les « Advanced Options ».

Et ça sert à quoi ?

On peut imaginer qu’en phase de prototypage cela permette de gagner du temps en disposant d’une cible plus ou moins proche de celle que l’on souhaite mettre en œuvre.

Ainsi, que vous projetiez de réaliser un module d’entrées / sorties, un codeur, un variateur, un appareil de mesure quelconque devant disposer d’une connectivité bus de terrain, vous pouvez commencer votre développement sur le Raspberry Pi.

Pourquoi pas une machine pilotée par un Raspberry Pi, avec une interface web et discutant avec un automate de ligne ?

Incrédules ? J’espère bien vous surprendre bientôt… 😉

Cordialement,
Stéphane

cifX : Siemens WinAC RTX – Application de test – Configuration OMB / PNS

Bonjour,

J’espère que vous avez passé de joyeuses fêtes et je vous adresse mes meilleurs vœux pour cette nouvelle année.

Comme le calme de cette période de fêtes était propice, j’ai augmenté l’application de test pour le pilote cifX pour WinAC RTX®, abondamment 😉 décrite ici déjà.

Les modifications et adjonctions portent sur l’aspect messagerie de l’API et sur la configuration des cartes cifX par programme.

Concernant ce dernier point, j’en ai fourni un exemple en C pour la configuration d’une carte en PROFIBUS DP Esclave .

La version de l’application de test libérée ce jour, et que vous pouvez vous procurer dès maintenant, montre la configuration d’une carte Hilscher cifX 50E-RE avec le firmware Open Modbus TCP en IO Server ou avec le firmware PROFINET IO IRT Device.

A cet effet, le FB36 « CIFX_CHANNEL_MSG » a été remanié afin de fournir la fonctionnalité suivante :

  • lecture des informations systèmes,
  • configuration du firmware Open Modbus TCP en IO Server ou avec le firmware PROFINET IO IRT Device selon le firmware sélectionné,
  • initialisation du canal

La gestion de la messagerie est opérée par une collaboration entre les blocs fonctions suivants :

FB36 CIFX_CHANNEL_MSG0_0 Hilscher cifX Channel Messaging
FB40 CIFX_CHANNEL_GET_PACKET Hilscher cifX Driver : Messaging / Getting Packets
FB41 CIFX_CHANNEL_PUT_PACKET Hilscher cifX Driver : Messaging / Putting Packets
FB42 CIFX_CNL_GSYSINFO0_0 Hilscher cifX Driver : Messaging / Get System Information
FB43 CIFX_CNL_SCNFOMB0_0 Hilscher cifX Driver : Messaging / Set Configuration Modbus TCP Slave
FB44 CIFX_CNL_INIT0_0 Hilscher cifX Driver : Messaging / Channel Init
FB45 CIFX_CNL_SCNFPNS0_0 Hilscher cifX Driver : Messaging / Set Configuration PROFINET Slave

C’est tombé en marche sans trop de souci, par exemple en PROFINET avec une CPU PN/DP IM151-8 :


Ainsi, vous pouvez aisément faire communiquer votre NanoBox Siemens avec un automate Schneider Electric par exemple, configuré en client Modbus TCP / IO Scanning, ou un autre automate Siemens configuré en contrôleur PROFINET.

Je tâcherai d’implémenter d’autres blocs fonctions pour la configuration des différentes piles de protocoles supportés par les cartes Hilscher cifX dans la mesure du possible.

Vous pouvez toujours nous solliciter pour obtenir un exemple de code convenant à votre besoin.

Cordialement,
Stéphane