Archives de catégorie : netIC

Nouvelles – Octobre 2014

Bonjour,

En ce moment je délaisse un peu Ada pour le web et les technologies associées.

Si ce n’est pas d’aujourd’hui que je m’y intéresse, l’actualité Hilscher me pousse à réactualiser mes vieilles connaissances en HTML / CSS, réactualisation d’autant plus nécessaire avec HTML5, et surtout à me mettre au JavaScript que je snobais jusqu’alors. Ajoutons à cela une pincée de SVG et le tableau est bientôt brossé.

Ainsi, les dernières versions de firmware pour les modules Hilscher au format DIL 32 netIC pour les protocoles basés sur Ethernet intègrent un serveur web.

J’ai déjà évoqué ces modules dans quelques autres articles :
http://slo-ist.fr/sujet/hilscher/netic

Ce serveur web permet, comme pour d’autres produits de la gamme, d’identifier le composant, de mettre à jour le firmware, régler certains paramètres, etc… mais, dans le cas du netIC, il est également possible d’intégrer ses propres pages web et d’accéder aux données du module via la table Modbus.

Pour la création des pages web, des exemples sont fournis, mettant en œuvre JavaScript, et il vous faut utiliser les outils standards pour l’édition de vos pages.

La famille netSCADA s’agrandit avec un nouveau rejeton disposant d’une connectivité Modbus RTU que l’on peut configurer en Maitre ou en Esclave, le netSCADA Modbus.

Je n’ai pas eu encore l’occasion d’évoquer son aîné, le netLINK SCADA, qui dispose lui d’une connectivité MPI / PROFIBUS pour la supervision d’automates SIEMENS®, mais j’y pense.

Ces deux produits intègrent la technologie atvise® de la société CERTEC EDV GmbH et sont fournis avec l’éditeur qui va bien pour créer vos pages intégrant vos synoptiques en SVG et le JavaScript pour l’animation de ceux-ci sans que vous ayez à maîtriser ces technologies.

Cependant vous avez accès au code source SVG / JavaScript généré et vous avez la possibilité de créer de toutes pièces vos propres composants si ceux fournis ne répondent pas exactement à vos souhaits.

Ayant goûté à ces technologies, je me suis demandé comment les mettre à profit dans « Ada for Automation » comme vous ne pouviez en douter.

En effet, avec Ada Web Server, il est possible d’ajouter un serveur web à votre application Ada, et à fortiori à votre application « Ada for Automation ».

J’avais déjà expérimenté avec Inkscape les graphismes en SVG et le projet MBLogic m’a servi de tutoriel pour ce qui est d’animer ces graphismes.

Bien sûr, j’ai croisé avec atvise et les techniques sont similaires comme on pouvait s’y attendre. C’est également le cas avec AWS pour ce qui est de AJAX.

Pour ce qui est de l’accès aux données process, CERTEC EDV GmbH fournit un SDK en C qui permet l’intégration dans un produit embarqué d’un serveur de données, ce qui est utilisé dans les netSCADA, Hilscher disposant par ailleurs des piles de protocoles et du serveur web qui vont bien.

MBLogic met en œuvre un serveur web écrit en Python, multiplateforme donc, ce serveur accède aux données process en étant décliné en client / serveur Modbus TCP ou Maître / Esclave Modbus RTU.

Je me suis amusé avec et ça donne ceci :
http://linuxfr.org/users/slos/journaux/mblogic-supervision-web-et-plus

Les dernières versions de AWS intègrent WebSocket, pour la communication bidirectionnelle entre l’application de supervision web dans votre navigateur et votre application « Ada for Automation », et toutes les pièces sont donc en place… Il ne reste plus qu’à intégrer tout ça.

N’est-ce pas merveilleux ? 😉

Cordialement,
Stéphane

netIC : Communication acyclique

Bonjour,

Quel que soit le bus de terrain utilisé on retrouve des principes communs.

La communication a pour but d’échanger différents types de données, des données procédé, des données de configuration ou de paramétrage, des données d’alarme ou de diagnostic, etc.

Selon le type de données, certaines doivent être échangées cycliquement, les données procédé, comme les consignes ou les commandes, les mesures et les états, les autres seront échangées suivant la nécessité.

Ainsi des données plus ou moins structurées, – table de registres pour Modbus, enregistrements pour PROFIBUS ou PROFINET, dictionnaire d’objets pour CANopen, EtherCAT, POWERLINK, SERCOS, Ethernet/IP… – sont accessibles en lecture ou écriture selon deux mécanismes distincts, l’un cyclique pour lequel il est nécessaire de garantir un temps de cycle borné et répétable, l’autre acyclique grâce à des méthodes implémentées sous la forme de requêtes.

J’ai déjà présenté la passerelle au format DIL32 Hilscher netIC. Cette passerelle permet donc d’interfacer un équipement nativement Modbus RTU avec les principaux bus de terrain du marché, qu’ils soient classiques ou Ethernet Temps Réel.

Vous pouvez vous procurer la documentation la plus importante pour la compréhension de cet article ici :
netIC – Real-Time Ethernet and Fieldbus Gateways User Manual

Si l’on examine le modèle de données implémenté dans les firmwares standard du netIC, on y remarque les zones de données cycliques ou image procédé et les deux boites aux lettres qui permettent de poster les requêtes acycliques.

Ces requêtes acycliques sont fonction de la pile de protocole mise en œuvre et sont documentées dans le manuel correspondant.

Le dictionnaire d’objet standard implémenté par défaut dans les piles de protocole CANopen, EtherCAT, POWERLINK, SERCOS, Ethernet/IP, etc. convient dans la plupart des cas, mais il peut s’avérer nécessaire de l’étendre afin de rajouter des objets spécifiques à l’application ou à un profil d’équipement, ce qui correspond à une classe d’équipements. C’est possible via la messagerie Hilscher. Vous disposez des services nécessaires pour créer ces objets, les configurer pour recevoir les indications de lecture et écriture et répondre à ces indications.

Bien sûr, cela implique de gérer tous ces messages du côté Hôte, ce qui peut s’avérer plus ou moins délicat si l’hôte ne dispose pas d’une capacité de traitement importante ou si l’on veut gérer plusieurs protocoles avec un même firmware.

Aussi il peut être plus judicieux de réaliser un firmware spécifique gérant ce dictionnaire d’objet en interne. Il suffit alors de mettre en place une table Modbus adaptée à votre application que l’hôte vient interroger à son rythme.

Vous pouvez confier à Hilscher France votre besoin et obtenir une offre raisonnable pour ce service. Que cette gestion soit réalisée côté Hôte ou côté netIC, il faudra réaliser le développement correspondant.

La solution « développement spécifique netIC » est sans aucun doute un choix à étudier car il dispose d’avantages certains comme une meilleure séparation de la fonction communication .

Pour terminer et illustrer mon propos, nous avons réalisé pour l’un de nos clients un firmware spécifique implémentant le profil « EtherCAT Semiconductor Device Profile 5003:2070 – Turbo Pump ».

Ainsi, l’impact de l’intégration de ce profil sur le code de son application est minimal et le firmware du netIC peut évoluer indépendamment comme par exemple pour intégrer une nouvelle version de la pile EtherCAT.

Cordialement,
Stéphane

netIC : Cas d’utilisation

Bonjour,

Dans l’article précédent, j’ai présenté brièvement le netIC et l’outil de test.

Aujourd’hui, je souhaite évoquer les divers cas d’utilisation de ce produit un peu particulier dans la gamme Hilscher.

C’est donc une passerelle Modbus RTU, Maitre ou Esclave, sur UART ou SPI vers CANopen, CC-Link, CompoNet, DeviceNet, PROFIBUS, EtherCAT, Modbus TCP, POWERLINK, PROFINET, Sercos III ou VARAN, dans la version Esclave de ces protocoles.

Mais le netIC dispose également de la possibilité de raccorder des entrées et sorties localement, jusqu’à 16 octets de chaque, directement via des registres à décalage sur l’interface SSIO.

Réalisation d’esclaves personnalisés

Ces entrées et sorties locales permettent donc de raccorder tout type de signal TOR ou Analogique via convertisseur, et dans la configuration du netIC, un simple mapping permet d’affecter ces entrées et sorties dans les données échangées sur le bus de terrain.

Il est ainsi très aisé de réaliser des esclaves personnalisés, adaptés au mieux au besoin de l’application.

Actualisation d’équipements

Sur nombre d’équipements, la connexion avec l’environnement tiers se fait encore aujourd’hui via un port série et un protocole ASCII ou Modbus RTU.

Avec la raréfaction de ces interfaces sur les matériels actuels, et la prolifération des bus de terrain, il devient nécessaire de disposer de la connectivité adéquate sans pour autant remettre en cause, en tout cas dans un avenir proche, les développements déjà engagés.

Le netIC fournit une solution simple à mettre en œuvre avec un minimum d’impact sur la conception matérielle ou logicielle déjà en place. Souvent, un simple réaménagement des composants ou une carte fille fera l’affaire et, côté logiciel, le protocole Modbus est facile à implémenter si ce n’est déjà le cas.

Bien sûr, en fonction de ce que l’on souhaite supporter comme fonctionnalité, le logiciel à développer côté Hôte peut être plus ou moins conséquent.

Ainsi, l’implémentation des échanges cycliques est relativement triviale. Par contre, si vous souhaitez gérer par exemple votre propre dictionnaire d’objets, il faudra prévoir un peu plus de temps.

Hilscher France peut prendre en charge la portion de code de votre applicatif relative à la gestion du bus de terrain. Après étude de votre besoin et validation de notre part que le produit proposé convienne, nous pouvons vous établir une proposition technique et commerciale.

Firmware spécifique

Si les firmwares standard ne conviennent pas à votre application, parce que par exemple vous disposez d’un protocole ASCII spécifique et que vous ne souhaitez pas tout modifier, nous pouvons réaliser un firmware sur la base de vos spécifications.

N’hésitez pas à nous solliciter si besoin.

Cordialement,
Stéphane

netIC : netIC Test Tool

Bonjour,

J’introduis aujourd’hui le netIC, une passerelle Hilscher pour l’embarqué :
http://www.hilscher.com/en/products/product-groups/embedded-modules/dil-32-communication-ic

C’est donc une passerelle au format DIL32, présentant d’un côté une interface vers tous les bus de terrain conventionnels ou sur Ethernet Temps Réel et de l’autre une connexion Modbus RTU Maitre ou Esclave, sur UART ou SPI.

Cette passerelle est fournie avec un outil de configuration, le « netX Configuration Tool », outil que l’on retrouve pour la configuration des cartes cifX.

Cet outil permet ainsi la configuration, le test et le diagnostic de la passerelle via la connexion UART0 réservée très justement à la configuration, au chargement du firmware, et au diagnostic.

Côté Hôte, il est également possible de faire un certain nombre de choses et l’outil de test et de démonstration que votre zélé serviteur a développé en C++, avec libmodbus et gtkmm, le binding C++ du toolkit graphique GTK+, a pour ambition de vous montrer cela via la connexion UART1.

Vous pouvez trouver ce fabuleux outil ici :
http://www.hf-news.fr/download/netIC/netIC_TestTool%20V1.2.0.7z

Il suffit d’exécuter « Setup.exe », l’installeur réalisé avec http://nsis.sourceforge.net/Main_Page.

Ayez un Anti Virus à jour, sait-on jamais !

Vous avez donc acheté une carte d’évaluation pour votre netIC et vous avez raccordé tout ça. Attention à bien positionner les jumpers…

Lorsque vous exécutez « netIC Test Tool », la fenêtre de trace vous montre les requêtes Modbus et les réponses obtenues du netIC.

nic_tt00

Il est nécessaire en premier lieu de vérifier les paramètres de connexion sur l’interface série que vous réglerez bien sûr à l’identique de ceux affectés avec le « netX Configuration Tool ».

Puis il faut se connecter, ce que l’on fait en cliquant sur le bouton idoine :

nic_tt01

Une fois connecté, on a accès à toute l’interface dédiée, que les onglets présentent dans l’ordre du modèle de données, cf. la documentation.

Ainsi on peut lire les informations systèmes, qui sont là pour vous permettre d’identifier le matériel et le firmware s’exécutant sur le netIC, ici un netIC 50-RE avec firmware Ethernet/IP Adapter :

nic_tt02

On peut lire et éventuellement modifier les réglages système :

nic_tt03

Pour certains bus de terrain, un état étendu est disponible, ce qui n’est pas le cas pour le firmware chargé :

nic_tt04

Il est aussi possible de modifier le paramétrage du côté bus de terrain :

nic_tt05

On peut consulter l’état du système :

nic_tt06

On peut agir sur les drapeaux et ainsi piloter le firmware :

nic_tt07

Et bien sûr jouer avec les entrées et sorties :

nic_tt08

Cherry on the cake, une superbe horloge Hilscher vous est offerte ! 😉

Hilscher-Clock

Nos clients obtiennent le code source sur demande pour en faire ce qu’ils souhaitent.

Cordialement,
Stéphane