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