Archives par mot-clé : CANopen

A4A : CAN Newsletter magazine March 2017: 25th anniversary

Bonjour,

Je n’ai pas beaucoup travaillé sur « Ada for Automation », et encore moins communiqué, ces derniers temps. Ce n’est pas pour autant que je suis resté les bras ballants et lorsque CAN in Automation (CiA) a offert gentiment la possibilité de participer à leur revue pour leur 25ème anniversaire j’ai proposé un article et celui-ci a eu l’honneur d’être sélectionné !

Cette revue vient de paraître début Mars et vous pouvez la trouver en ligne ici :
CAN Newsletter magazine March 2017: 25th anniversary

L’article lui-même est disponible au format PDF et en Anglais ici :
Ada for Automation : Ada language for automation

Je vous en souhaite une bonne lecture.

Je reviens rapidement vers vous pour plus de nouvelles, car il y en a !

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

cifX : Siemens WinAC RTX – Application de test – CANopen Master – SDO

Bonjour,

Dans les articles précédents concernant l’application de test pour le pilote cifX pour WinAC RTX® il était question de configurer une carte Hilscher cifX 50E-RE avec les firmwares Open Modbus TCP en IO Server, PROFINET IO IRT Device ou Ethernet/IP Adapter.

Faisant suite à la requête d’un de nos clients, une nouvelle version de cette application de test est disponible qui permet, en utilisant une carte Hilscher cifX 50E-CO avec le firmware CANopen Master, de lire une donnée du dictionnaire d’objet d’un esclave via SDO :
http://www.hf-news.fr/download/cifX/WinACRTX2009/cifXWACDriver/20131023.zip

Comme l’application implémente plusieurs options de configuration, ces options sont maintenant configurables depuis l’OB de démarrage.

Enfin, les blocs fonctions gérant les messages ont été retouchés pour traiter d’éventuelles erreurs.

Le bloc fonction qui implémente la lecture via SDO a donc été rajouté :

FB47 CIFX_COM_SDOR0_0 Hilscher cifX Driver : Messaging / CANopen Master SDO Read

La carte Hilscher cifX 50E-CO est configurée avec l’outil SYCON.net en CANopen Master et l’application de test montre la lecture de l’objet (Identity Object, Product code) d’index := 1018, sous-index := 2 de l’esclave d’adresse 2.

Une VAT permet de piloter cette requête et d’afficher le résultat :

cifXWACVATSDO1

Il suffit de renseigner les paramètres de la requête et de lancer la commande (Do).

La réponse est contenue dans les quatre octets de données 00 1A 20 20, soit 1712160 en décimal, ce qui correspond au code produit de la passerelle Hilscher netTAP CANopen esclave utilisée pour les essais.

cifXWACVATSDO2

Votre NanoBox Siemens peut donc se voir adjoindre une fonctionnalité Maitre CANopen et ainsi être tout à fait capable de gérer des esclaves CANopen en prenant en charge les PDO, c’est à dire les données process cycliques, les SDO pour l’accès en lecture et écriture aux données du dictionnaire, et les commandes NMT pour la gestion des modes de marche des nœuds.

N’hésitez pas à nous solliciter pour obtenir un exemple de code convenant à votre besoin.

Cordialement,
Stéphane

netTAP : firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT

Bonjour,

Je vous avais présenté dans cet article le firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT.

Je rappelle rapidement que ce firmware permet les fonctions de lecture / écriture de SDO et la commande NMT CANopen via Modbus TCP.

Ce firmware était disponible pour la passerelle Hilscher NT 100-RE-CO. Nous l’avons porté sur la version économique NT 50-CO-EN.

Vous disposez donc de deux options, l’une pour raccorder un réseau CANopen constitué de plusieurs esclaves, la seconde pour raccorder un seul équipement.

Le manuel utilisateur pour ce firmware est disponible ici :
Manuel%20Utilisateur%20Passerelle%20NetTAP%20Modbus%20TCP%20CANopen%20V02.pdf

Un projet de configuration exemple SYCON.net est également fourni :
NT-OMBCOM-ACYC%2020130718.zip

Enfin, le projet de test avec un automate Schneider Electric M340 est téléchargeable là :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/SchneiderElectric/nt-ombcom-acyc.sta

Le firmware est disponible auprès de Hilscher France.

N’hésitez pas à solliciter Hilscher France si besoin.

Cordialement,
Stéphane

netTAP : firmware spécifique Modbus TCP – CANopen Maitre / SDO + NMT

Bonjour,

Hilscher propose avec ses passerelles netTAP 100, netTAP 50 et netBRICK et les firmwares standard disponibles, environ 300, un éventail de solutions pour la conversion de protocoles particulièrement large.

Cependant, si les firmwares standard couvrent très bien les besoins pour les données échangées cycliquement, comme les PDO pour CANopen, les communications acycliques ne sont à ce jour pas supportées.

Ces échanges acycliques sont utilisés pour la configuration, le paramétrage et le diagnostic précis des équipements connectés.

En visant l’exhaustivité en matière de combinaisons protocolaires, il n’est pas aisé de concevoir un mécanisme générique susceptible de supporter l’ensemble des fonctions quel que soit le protocole. Les concepts sont bien similaires mais les disparités sont irréductibles, volume, type de données, adressage…

D’où la nécessité de concevoir spécifiquement un mécanisme permettant cet échange acyclique. C’est ce que nous avons réalisé avec ce firmware.

Le produit standard Hilscher NT 100-RE-CO possède les interfaces physiques nécessaires et Hilscher France fournit le firmware spécifique.

Les outils de configuration standard Hilscher sont utilisés.

Ce firmware permet les fonctions de lecture / écriture de SDO et la commande NMT CANopen via Modbus TCP.

Le manuel utilisateur pour ce firmware est disponible ici :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/Manuel%20Utilisateur%20Passerelle%20NetTAP%20Modbus%20TCP%20CANopen%20V01.pdf

Un projet de configuration exemple SYCON.net est également fourni :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/Hilscher/NT-OMBCOM-ACYC%2020121123.zip

Enfin, le projet de test avec un automate Schneider Electric M340 est téléchargeable là :
http://www.hf-news.fr/download/netTAP/NT-OMBCOM-ACYC/SchneiderElectric/nt-ombcom-acyc.sta

Il est à noter que le principe retenu pour la gestion des échanges acycliques dans ce firmware peut être aisément transposé à d’autres combinaisons protocolaires et nous pouvons donc réaliser chez Hilscher France la combinaison dont vous auriez besoin comme :

  • PROFINET Maitre ou Esclave – CANopen SDO + NMT
  • Ethernet/IP Maitre ou Esclave – CANopen SDO + NMT
  • PROFIBUS Maitre ou Esclave – CANopen SDO + NMT
  • DeviceNet Maitre ou Esclave – CANopen SDO + NMT

N’hésitez pas à solliciter Hilscher France si besoin.

Cordialement,
Stéphane