Archives par mot-clé : EtherCAT

A4A : Exemple d’application 6 : Modbus TCP Client / Serveur + deux canaux Hilscher

Bonjour,

Comme je l’indiquais récemment l’application « app6_gui » offre :

  • un serveur Modbus TCP pour y connecter par exemple un SCADA du marché,
  • une fonction IO Scanning avec une tâche client Modbus TCP par serveur d’E/S,
  • deux canaux cifX Hilscher, pour gérer deux cartes, par exemple une PROFIBUS DP Maitre et une EtherCAT Maitre, ou pour gérer une carte à deux canaux comme par exemple un PROFIBUS DP Maitre et un CANopen Maitre,
  • une interface graphique avec GtkAda, permettant de consulter l’état des communications et de l’application et de démarrer ou arrêter les programmes utilisateur,
  • l’intégration du « cifX TCP Server » permettant la configuration et le diagnostic des cartes par SYCON.net via une connexion TCP/IP.

Je voulais faire un article à part pour cette application, avec des images. J’ai donc monté la manipulation suivante :

Manip-2016-01-08

On a donc un PC, sous Debian Jessie et un noyau Linux 64 bit standard, avec deux cartes Hilscher PCI, une cifX 50-DP configurée en Maître PROFIBUS DP et une cifX 50-RE configurée en Maître EtherCAT :

PC+2cifX50

Comme Esclave PROFIBUS DP j’ai une carte Hilscher CB-AB32-DPS, un « piano » avec deux octets en entrée et autant en sortie qui permet de monter une manipulation en deux secondes et demie :

CB-AB32-DPS

Pour EtherCAT, j’ai également un « piano », le NXIO 500-RE, qui reçoit sa fonctionnalité en insérant la carte MMC qui convient, ici EtherCAT Esclave, avec toujours deux octets d’E/S :

NXIO-500-RE

Le client Modbus TCP qui interroge le serveur de l’application 6 est Modbus Poll dont j’ai déjà fait mention il y a longtemps.

Quant au client Modbus TCP, ce que certains appellent IO Scanning, il est configuré pour exécuter deux requêtes sur un serveur d’un genre particulier sur lequel je reviendrai plus tard.

Je vous épargne la trace laissée par l’application dans le terminal depuis lequel elle est lancée, qui est certes informative, voire même didactique, mais un peu indigeste.

La fenêtre principale s’ouvre et l’on y trouve les onglets suivants.

La vue « Identité », (remarquez la version !) :

A4A-App6-Identity

La vue « Etat général » en deux bouts :

A4A-App6-GeneralStatus1

A4A-App6-GeneralStatus2

On notera la présence des informations d’état des deux tâches « Fieldbus ».

On trouve ensuite la vue d’état du serveur Modbus TCP qui affiche les compteurs de requêtes, et bien évidemment celui qui bouge est celui de la fonction 3 configurée côté Modbus Poll :

A4A-App6-ModbusTCPServer

La vue « Client Modbus TCP » affiche les informations d’état concernant les deux requêtes configurées pour le serveur secret pour le moment, le second client étant désactivé :

A4A-App6-ModbusTCPClients

Notez que lorsque l’on rajoute des requêtes au niveau de la configuration des clients, la vue d’état est bien sûr adaptée automatiquement.

Puis viennent les deux vues d’état des canaux Hilscher cifX.

L’un est donc PROFIBUS DP Maître :

A4A-App6-ProfibusDPMaster

Et l’autre est EtherCAT Maître :

A4A-App6-EtherCATMaster

Le programme utilisateur à l’œuvre dans les trois tâches est très sensiblement identique :

   procedure Process_IO is

      Elapsed_TON_1 : Ada.Real_Time.Time_Span;

   begin

      if First_Cycle then

         Output_Byte := Pattern_Byte;

         First_Cycle := False;

      end if;

      Tempo_TON_1.Cyclic (Start   => not TON_1_Q,
                          Preset  => Ada.Real_Time.Milliseconds (500),
                          Elapsed => Elapsed_TON_1,
                          Q       => TON_1_Q);

      if TON_1_Q then

         case Cmd_Byte is

         when 0 =>
            Output_Byte := ROR (Value => Output_Byte, Amount => 1);

         when 1 =>
            Output_Byte := ROL (Value => Output_Byte, Amount => 1);

         when others => Output_Byte := Pattern_Byte;

         end case;

      end if;

   end Process_IO;

On trouve aussi dans « Ada for Automation » une application exemple 5, « app5 », identique à « app6 » mais qui ne gère elle qu’un seul canal Hilscher cifX.

Mais quel est donc ce serveur Modbus TCP secret dont je vous entretiens depuis le début ?
La NXIO 500-RE ne pourrait-elle faire l’affaire avec une MMC ad hoc ? Sans doute, mais pour des raisons qui m’échappent ce firmware n’existe pas…

Aussi, je me suis dit que je n’avais qu’à utiliser le « kernel 0 », issu de « app1simu », et qui fournit un serveur Modbus TCP.
Oui mais, et les boutons et LEDs ? GtkAda aurait bien sûr pu convenir mais comme je jouais avec Gnoga…

Taa taan ! Voilà un « piano » piloté depuis le navigateur !

A4A-App6-A4A-Piano-Local

Comme c’est du SVG, donc du vectoriel, même depuis un mobile ça se pilote.

Et en plus l’application supporte les connexions multiples ! On peut jouer à plusieurs ! J’adore…
Promis, dès que mon code est un peu plus propre je l’envoie sur le dépôt.

Cordialement,
Stéphane

A4A : Applications et Noyaux

Bonjour,

Le framework « Ada for Automation » est fourni avec un certain nombre d’applications exemples, simple applications consoles ou avec interface graphique en GtkAda, et très bientôt je l’espère avec interface web grâce à Gnoga, un autre framework que je vous avais présenté très brièvement ici, et avec lequel je m’instruis beaucoup tout en m’amusant.

Ainsi par exemple le projet de base A4A est proposé en version console, dont le fichier projet est « a4a.gpr », et en version interface graphique avec « a4a_gui.gpr ».
Cette application est la plus simple possible et joue avec les deux octets d’entrée et sortie à sa disposition, ne mettant en œuvre que des fonctions de rotation et d’affectation.

Ce projet repose sur un noyau, partagé par les deux versions, qui gère le programme utilisateur, un serveur Modbus TCP et des clients Modbus TCP, un pour chaque serveur d’E/S.
La tâche principale collabore avec une tâche périodique annexe via la nouvelle DPM générique dont il a été question précédemment, chacune des tâches disposant d’un programme utilisateur à exécuter à l’état RUN.
Le serveur Modbus TCP comme les clients échangent leurs données avec la tâche principale également via des DPM spécifiques dont le rôle est d’assurer la cohérence des données échangées.

Via le mécanisme d’extension des projets supporté par la suite d’outils fournis par AdaCore, on peut construire des projets héritant des fichiers du projet parent et ajoutant de nouveaux fichiers ou en les substituant s’ils portent le même nom.

C’est ce mécanisme qui est utilisé par exemple avec l’application 1 présentée ici, et encore ici.

Aussi, comme cette application hérite de tout A4A, son dossier source ne contient que ce qui lui est propre, son identification, sa configuration et le programme utilisateur.

Pour cette application 1, ne disposant pas de la partie opérative on a développé une application de simulation, nommée « app1simu ».
Cette application ne nécessitant que la fonction serveur Modbus TCP on a créé un nouveau noyau issu du noyau de A4A auquel on a ôté la gestion des clients Modbus TCP.
Ce noyau logeait dans le dossier de l’application « app1simu » puisqu’il lui était spécifique.

Il en fut de même pour l’application 2 qui met en œuvre une carte Hilscher cifX en lieu et place des clients Modbus TCP.

Et encore de même avec l’application 3 qui remplace les clients Modbus TCP par un maitre Modbus RTU.

Le problème dans cette situation c’est que pour réutiliser un noyau de « app1simu », de « app2 » ou de « app3 », il eu fallut hériter de ces projets ou lister les sources que l’on souhaitait réutiliser, c’est possible, ou pire dupliquer les sources, beurk… Bref, ce n’était pas satisfaisant d’autant que je comptais multiplier les noyaux… On multiplie ce qu’on peut.

J’ai donc réorganisé le framework de sorte que les noyaux se retrouvent dans leurs propres dossiers.
Piloté par une variable externe ou un scénario depuis GPS, le dossier sélectionné est ajouté au projet en cours de traitement.

Ainsi le noyau de « app1simu » est maintenant le « kernel0 », celui de A4A est le « kernel1 », celui de « app3 » est devenu « kernel2″…

C’est beau et ça fonctionne à peu près.
La variable est définie dans un fichier de projet partagé par les autres fichiers de projets, le projet « shared.gpr », et reçoit une valeur initiale par défaut qui est « kernel1 » si elle n’est pas définie par ailleurs.
Attention cependant de laisser GPS terminer ses opérations de mise à jour des références croisées avant de changer de noyau au moyen de la liste déroulante du scénario sous peine de corruption de sa base de données, du moins avec la version Debian.
Ce n’est pas très grave puisqu’il suffit de supprimer celle-ci pour qu’elle soit reconstituée mais c’est un peu pénible.

...
   type Kernel_Type is
      ("kernel0",   --  Modbus TCP Server
       "kernel1",   --  Modbus TCP Server + Modbus TCP IO Scanning
       "kernel2",   --  Modbus TCP Server + Modbus RTU IO Scanning
       "kernel3",   --  Modbus TCP Server + one Hilscher cifX channel
       "kernel4",   --  Modbus TCP Server + Modbus TCP IO Scanning
                    --  + one Hilscher cifX channel
       "kernel5"    --  Modbus TCP Server + Modbus TCP IO Scanning
      );            --  + two Hilscher cifX channels

   Kernel : Kernel_Type := external ("Kernel", "kernel1");
...

Et l’on voit que le noyau de « app2 » est devenu le « kernel3 », que le « kernel4 » fusionne le « kernel1 » et le « kernel3 » et que le « kernel5 » ajoute un canal Hilscher au « kernel4 ».

J’ai bien sûr créé les applications exemples « app5 » qui roule avec le « kernel4 » et « app6 » motorisé par le « kernel5 », le tout en version console ou GUI.

Comme chaque canal Hilscher est susceptible de gérer un bus de terrain différent, classique ou sur Ethernet Temps réel, chaque canal est géré par une tâche indépendante qui exécute son propre programme utilisateur avec une période que l’on peut configurer.
Les tâches « fieldbus » communiquent avec la tâche principale via les DPM génériques déjà évoquées.

Ainsi l’application « app6_gui », mon top model ;-), offre :

  • un serveur Modbus TCP pour y connecter par exemple un SCADA du marché,
  • une fonction IO Scanning avec une tâche client Modbus TCP par serveur d’E/S,
  • deux canaux cifX Hilscher, pour gérer deux cartes, par exemple une PROFIBUS DP Maitre et une EtherCAT Maitre, ou pour gérer une carte à deux canaux comme par exemple un PROFIBUS DP Maitre et un CANopen Maitre,
  • une interface graphique avec GtkAda, permettant de consulter l’état des communications et de l’application et de démarrer ou arrêter les programmes utilisateur,
  • l’intégration du « cifX TCP Server » permettant la configuration et le diagnostic des cartes par SYCON.net via une connexion TCP/IP.

Je vous remercie pour votre attention et vous souhaite une très bonne et heureuse année 2016 pleine de projets, personnels comme professionnels, et de réussite.

N’hésitez pas à nous solliciter.

Cordialement,
Stéphane

A4A : Nouvelles – Mai 2015

Bonjour,

Bien décidé à étendre les capacités de « Ada for Automation » pour la gestion des solutions de communication Hilscher, j’ai donc entrepris de réaliser les blocs fonctions correspondants aux requêtes disponibles avec la pile de protocole EtherCAT Maitre, particulièrement celles permettant la lecture et l’écriture d’objets via l’interface « CoE » (CANopen over EtherCAT).

Le manuel documentant cette pile de protocole, que l’on trouve sur le DVD des solutions de communication, peut être téléchargé ici :
https://kb.hilscher.com/display/ECM3V0/EtherCAT+Master

Deux requêtes sont ainsi disponibles :

  • ETHERCAT_MASTER_CMD_SDO_UPLOAD_REQ pour la lecture d’un objet,
  • et ETHERCAT_MASTER_CMD_SDO_DOWNLOAD_REQ pour l’écriture.

Cependant, tandis que je dupliquais une requête déjà réalisée, je me suis dit qu’il était plus que temps de réusiner…

En effet, j’avais jusque là focalisé mon attention sur l’infrastructure de la messagerie et les requêtes diverses avait été écrites surtout pour valider cette infrastructure et fournir quelques exemples.

Or, les requêtes sont toutes fondées sur le même modèle et on peut sans doute mutualiser celui-ci :

  • le bloc est initialisé, c’est à dire qu’on lui attribue un canal de communication, et il récupère auprès de celui-ci l’identifiant de sa queue de réception qu’il utilisera pour l’en-tête de la requête.
  • la procédure « Cyclic », appelée cycliquement donc par le programme utilisateur, gère l’obtention du paquet pour la requête depuis le pool, l’élaboration de la requête, la transmission de celle-ci, la réception de la réponse et son traitement, et le retour du paquet réponse au pool.
  • à la fin du traitement, on peut soit utiliser le résultat, soit récupérer le code de la dernière erreur survenue éventuellement.

Les requêtes dans « Ada for Automation » sont implémentées sous la forme d’un bloc fonction qui n’est autre qu’une méthode d’un objet. En créant un objet « Requête » abstrait encapsulant les attributs communs, comme le graphe d’état, et les méthodes communes, comme la procédure « Cyclic », et en dérivant les objets requêtes de ce parent commun, l’écriture en est simplifiée tout comme la maintenance.

Les objets requêtes dérivés héritent des méthodes de leur parent.
En sus, ils comportent une méthode « Fill_Request », qui est appelée par la procédure « Cyclic » après que les champs communs de l’en-tête aient été remplis, pour fournir les éléments spécifiques de la requête.
Ils comportent également une méthode « Store_Result » qui traite le résultat après que les vérifications communes aient été faites.
Ces méthodes sont déclarées dans la partie privée du paquetage parent en ayant un corps spécifiant qu’elles doivent être implémentées dans l’objet dérivé.
Enfin, ils fournissent une méthode pour récupérer le résultat depuis le programme utilisateur.

Pour pouvoir hériter de la partie privée du parent, attributs et méthodes, les objets dérivés doivent être définis dans des paquetages fils de celui du parent. Aussi, il a fallu modifier quelque peu la hiérarchie des paquetages implémentant les requêtes déjà réalisées et bien sûr en modifier le code pour les insérer dans le nouveau schéma.

L’autre classe d’interaction avec les piles de protocoles rassemble les indications qui sont à l’initiative de la pile, contrairement aux requêtes qui sont à l’initiative du programme utilisateur.

Le même raisonnement peut être tenu à leur propos et l’on a donc implémenté un objet abstrait « Indication » et dérivé les indications déjà réalisées de celui-ci.

J’ai pour l’occasion retravaillé également les tests et les applications mettant en œuvre ces requêtes et indications.

C’est beau et ça fonctionne ! 😉

Vous pouvez suivre les modifications apportées via GitLab :
https://gitlab.com/ada-for-automation/ada-for-automation

Le même genre de requêtes de lecture et écriture d’objets est disponible quelle que soit la technologie de bus de terrain utilisée. J’envisage de réaliser les blocs fonctions correspondants pour Ethernet/IP Scanner, CANopen Maitre, PROFINET IO Controller…

L’interface applicative fournie par les solutions de communication Hilscher est riche et certaines fonctions sont certainement plus utiles pour l’application que d’autres qui le seront pour un outil de configuration ou de diagnostic évolué.

Il n’est donc pas question d’être exhaustif et le choix des réalisations se fera au gré des souhaits exprimés.

N’hésitez pas à nous faire part de vos remarques et propositions éventuelles via le forum ou par email (contact).

Cordialement,
Stéphane

A4A : Nouvelles – Avril 2015

Bonjour,

Ce mois d’Avril a été propice et l’actualité « Ada for Automation » est donc plus étoffée que de coutume.

Nouvelle présentation du site

Commençons par la nouvelle la plus visible, le changement de thème de WordPress. L’aspect n’est pas tant ce qui m’a conduit à en changer bien que je le trouve assez réussi. C’est surtout le « Responsive Design » ou la faculté de s’adapter à la taille de la fenêtre du navigateur qui a motivé mon choix.

Que vous accédiez au site depuis un PC, une tablette ou un smartphone, même un pas très smart, le site devrait être lisible, même si le contenu peut être indigeste…
Même sur un PC vous pouvez expérimenter en jouant avec la taille de la fenêtre et observer comment les différents éléments se replacent magiquement.

Hormis le choix et la disposition des « Widgets », le thème est standard.

J’espère que cette nouvelle présentation vous soit agréable.

Interface Homme-Machine – Gnoga et AICWL

Tandis que j’étudiais, comme évoqué dans cet article, les technologies Web pour une utilisation avec « Ada for Automation », Monsieur David BOTTON a créé Gnoga, un framework pour développer des applications Web en Ada :
http://www.gnoga.com/

Aussi, je suis particulièrement intéressé par ce cadre applicatif et je compte bien l’utiliser pour l’IHM d’applications « Ada for Automation » comme App1.

Pouvoir piloter l’arrosage de son potager depuis son smartphone ou sa tablette est à n’en pas douter un must ! 😉

Cependant, pour un affichage plus dynamique et des composants graphiques évolués, la bibliothèque ADA INDUSTRIAL CONTROL WIDGET LIBRARY de Monsieur Dmitry A. KAZAKOV est sans conteste plus adaptée :
http://www.dmitry-kazakov.de/ada/aicwl.htm

Ces deux solutions partagent quelques composants dont le serveur web de Monsieur Kazakov.

Bien sûr, GtkAda permet également de réaliser une IHM et les trois technologies ne s’opposent pas mais se complètent à merveille.

Vérification de style et correction des avertissements

L’un des avantages les plus proéminents du « libre » c’est qu’il permet d’apprendre beaucoup en étudiant le code écrit par la communauté.

Comme les projets évoqués ci-dessus mettent en œuvre des options permettant la vérification de style et générant un maximum d’avertissements lors de la compilation, je me suis penché sur le sujet et ai intégré dans les fichiers projets ces options documentées ici et là :
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Style-Checking.html
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Warning-Message-Control.html
https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gnat_ugn/Compiler-Switches.html

Il a fallu évidemment corriger beaucoup de choses… ce qui a été fait pour l’essentiel.

Réorganisation des tests

Je n’avais pas encore eu l’occasion de remercier Monsieur François FABIEN pour ses conseils avisés.

Comme François me l’avait suggéré il y a quelque temps déjà j’ai réorganisé les tests afin qu’ils aient leurs propres projets et répertoires.
Ainsi, ils n’interfèrent plus avec les autres projets et cela permet de rendre les choses plus « lisibles », du moins je l’espère.

HilscherX – réusinage de la communication acyclique

Le plus gros du travail sur le code a porté sur la partie permettant l’utilisation des cartes de communication Hilscher ainsi que des modules comX et netJACK qui partagent la même interface applicative.

Le principe de cette communication acyclique a été abordé dans un certains nombre d’articles, le premier de la série étant sans doute celui-ci. La page Plan du site liste les articles concernant l’infrastructure mise en œuvre dans « Ada for Automation » pour gérer ce type de communication.

Il y est question de Paquets, de Pool de paquets, de Queues de paquets, etc… Si le principe reste inchangé, l’implémentation a été revue car le problème était le suivant :

L’en-tête des paquets contient des identifiants de source et de destination qui permettent le routage de ces paquets. La documentation Hilscher explique ce routage en indiquant que les champs Source et Source_Id doivent identifier l’application et le processus émetteurs. Le procédé de routage doit en fonction de ces champs retrouver la queue de messages correspondante.

Cependant, un raccourci employé est de renseigner ces champs avec les pointeurs de queues directement comme on peut le constater couramment dans la documentation relative aux piles de protocoles. Dans le firmware des produits, le système d’exploitation rcX utilisé est un système 32 bits et les pointeurs ont une taille de 32 bits. Indiquer la valeur du pointeur de la queue permet donc un routage très rapide puisqu’il n’y a pas lieu de rechercher ce pointeur ailleurs.

Dans ma première implémentation j’avais donc utilisé le même artifice… Mais il s’est posé un problème avec ma Debian 64 bits, le pointeur de la queue ne tenait plus dans le champs !

J’ai donc revu le routage afin de passer par une table intermédiaire, la Queue_Map, qui associe les pointeurs de queues et des indices, ces indices étant utilisés dans le champs Source_ID. Et puis, comme j’ai fait quelques progrès en Ada, j’ai également retravaillé les Pool et Queue de paquets.

HilscherX – RCX_GET_DPM_IO_INFO_REQ

Dans l’interface standard Hilscher, la fameuse Dual Port Memory, les zones réservées à l’image procédé, « les IO areas » comportent 5760 octets en entrée et autant en sortie.
Dans la plupart des cas d’utilisation c’est plutôt confortable et seule une partie de ces octets sont utilisés.

Les fonctions de l’API, xChannelIORead et xChannelIOWrite, qui permettent l’accès à ces zones prennent en paramètres un offset et une taille de données, ce qui permet de ne rafraîchir que les données effectivement configurées, avec bien sûr un gain de temps à la clef.

Il est possible avec la requête RCX_GET_DPM_IO_INFO_REQ de récupérer les informations concernant les zones IO, offset et taille, et nous avons donc implémenté un bloc fonction pour cela, le test qui va avec et modifié la tâche principale du projet « A4A_HilscherX » en conséquence.

Ainsi, les projets comme « App2 » qui héritent de « A4A_HilscherX » en profitent naturellement.

HilscherX – Diagnostic générique

Le document consacré à la Dual Port Memory mentionne, pour chaque canal de communication,

  • un « Common Status » qui permet de connaître un état de la communication commun à toutes les piles de protocoles,
  • un « Extended Status » qui permet de connaître un état de la communication relatif à chaque pile de protocole et documenté dans le manuel de la pile.

L’état étendu n’est pas utilisé par toutes les piles.

Pour certaines piles comme PROFIBUS DP Maitre, CANopen Maitre ou DeviceNet Maitre, cette zone contient la structure de diagnostic fournie par l’ancienne gamme des CIF, aujourd’hui obsolète, afin de faciliter la migration d’applications vers la nouvelle gamme cifX.

Cependant les capacités des bus de terrain basés sur Ethernet Temps Réel requièrent de repenser le principe du diagnostic. Pa exemple, PROFIBUS DP ne permet que 126 nœuds sur le réseau quand EtherCAT en prévoit en théorie jusqu’à 65535 !

Aussi, le manuel de la DPM indique que le diagnostic des protocoles maîtres se passe en deux temps.

Dans un premier temps, on utilise la requête RCX_GET_SLAVE_HANDLE_REQ pour récupérer une liste de « handles » d’esclaves, configurés, actifs ou présentant une information de diagnostic disponible, selon la liste demandée.

Dans un second temps, pour chaque « handle » de la liste retournée, la requête générique RCX_GET_SLAVE_CONN_INFO_REQ permet de récupérer les informations de connexion de l’esclave considéré.

Chaque pile de protocole maître retourne une structure documentée dans le manuel propre à la pile.

Nous avons donc créé un bloc fonction pour RCX_GET_SLAVE_HANDLE_REQ et un pour RCX_GET_SLAVE_CONN_INFO_REQ et créé les applications de test pour PROFIBUS DP Maître et EtherCAT Maître.

Et puis ?

Je lorgne du côté de la partie « Motion Control » chez PLCopen :
http://www.plcopen.org/pages/tc2_motion_control/

J’aimerais bien construire une telle bibliothèque en Ada intégrée dans « Ada for Automation ». La spécification est téléchargeable sur le site.

Bien sûr, si un tel projet vous intéresse pour vos propres réalisations, travaillons ensemble !

Pour l’instant je ne dispose pas de matériel pour tests. A minima il me faudrait un variateur communicant, avec son moteur et son codeur.
Aussi, si un tel matériel traîne dans vos placards et vous embarrasse, pensez à moi avant de le jeter à la benne.

D’ailleurs, je suis preneur de tout équipement communicant pourvu qu’il fonctionne encore et que son alimentation ou sa taille ne soient pas incongrues.
Merci d’avance pour vos contributions matérielles, qui me permettront de réaliser expériences, démonstrations et articles sur ce blog comme j’ai déjà pu le faire ici avec un radar de chez Endress + Hauser ou avec du matériel Eaton !

N’hésitez pas à nous faire part de vos remarques et propositions éventuelles via le forum ou par email (contact).

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