Bonjour,

J’avais évoqué dans un article précédent la mise en œuvre de la messagerie Hilscher cifX qui permet d’effectuer les opérations de configuration, de paramétrage ou de diagnostic des cartes de communication ou des équipements raccordés sur le bus de terrain.

Hormis pour les cas triviaux comme la configuration d’une carte esclave, il est préférable de mettre en place une infrastructure permettant de gérer au mieux les flux de messages.

En général, il n’est pas souhaitable que la tâche traitant les données process cycliques soit interrompue pendant un laps de temps qui peut être plus ou moins important.

En effet, les messages présentent un caractère hautement asynchrone.

Par exemple, lorsque l’application agit en tant que Client, elle envoie une requête via la BAL d’émission. Cette requête va traverser les couches de communication et éventuellement être adressée à un partenaire de communication sur le réseau. Si le partenaire répond, l’application recevra une réponse à sa requête ou une réponse négative le cas échéant.

On peut, pour ce qui est de la configuration, gérer le flot de messages avant de rentrer dans la boucle de traitement principale.

On peut également traiter les flux de messages de diagnostic dans une tâche ad hoc.

Avec un automate classique, on dispose pour ce genre d’exercice de blocs fonctions dédiés dont le traitement est conduit sur plusieurs cycles de la boucle principale, comme par exemple les blocs AG_SEND / AG_RECV dans les automates Siemens.

Pour WinAC RTX® nous avons d’ailleurs écrit un certain nombre de ces blocs fonctions pour s’interfacer avec les cartes Hilscher cifX. Cf. cette série d’articles.

« Ada for Automation » s’adresse à des automaticiens, il fallait donc s’inspirer de ce qui se fait en la matière.

L’API messages Hilscher est vaste, un jeu de messages pour le système rcX et un jeu de messages par pile de protocole, aussi nous nous proposons d’en coder quelques uns pour l’exemple et le reste à discrétion.
Merci pour vos contributions ! 😉

Dans les coulisses, pour un bloc exécutant une fonction Client cela repose sur le fonctionnement suivant :

Les blocs fonctions sont connectés à une instance d’objet gérant la messagerie du canal de communication, « Channel_Messaging ».

Un bloc fonction dispose d’un graphe d’état et d’une queue de réception qui peut contenir un paquet pour les blocs Client, (plusieurs pour les blocs Serveur).

La fonction cyclique du bloc permet de commander celui-ci et de connaitre l’état de la commande.

Les messages peuvent avoir une taille maximale de 1500 octets environ.
Afin d’éviter l’allocation / libération de paquets on travaille avec un réservoir – pool – de paquets.

Un bloc fonction demande un paquet au pool.
Il remplit l’en-tête et le corps du message. Dans l’en-tête, il renseigne le Source_Id avec l’adresse de sa queue de réception, ce qui permettra à la tâche de réception de poster la réponse directement.

On utilise une queue de paquets qui alimente une tâche gérant la BAL d’émission.
On poste les paquets dans cette queue et la tâche d’émission les dépile.
Ainsi, dans un même cycle, plusieurs blocs fonctions peuvent poster des paquets.
Une fois le paquet envoyé au système, le paquet est retourné au pool.

Le bloc fonction poste donc le paquet dans la queue d’émission et attend la réponse qui doit parvenir à sa queue de réception.

La tâche de réception scrute la BAL de réception et poste le paquet reçu dans la queue de réception du bloc fonction.

Le bloc fonction traite le paquet reçu et retourne le paquet au pool.

Plusieurs programmes de test montrent cette infrastructure au travail.
Un petit schéma serait un plus…

Pour ce qui est du code, il sera disponible normalement dès ce soir sur Gitorious.

Merci pour vos retours.

Cordialement,
Stéphane