Bonjour,

Selon le système d’exploitation supportant l’exécution de « Ada for Automation » votre application d’automatisme bénéficiera d’un comportement plus ou moins « temps réel ».

C’est au concepteur de s’assurer que la solution qu’il met en œuvre répond à son besoin dans toutes ses dimensions.

Ainsi, telle application pourra se satisfaire d’un comportement temps réel mou tandis que telle autre nécessitera du temps réel dur.

Prenons un exemple simple pour expliciter cette notion.

Un vérin pneumatique est piloté grâce à une électrovanne et dispose d’un capteur sur l’organe mené « Ouvert » et d’un autre « Fermé ». Le vérin arrive en butée dans un cas comme dans l’autre. Un commutateur et deux voyants constituent l’IHM. En fonction de la position du commutateur on pilote l’électrovanne et la position de l’organe donnée par les fins de course est affichée sur les voyants.

Pour piloter une telle partie opérative, un temps réel mou convient tout à fait. La boucle de traitement peut s’exécuter selon une période qui peut varier sans que cela entraine un dysfonctionnement de l’installation.

Imaginons maintenant que sur un convoyeur transitent des colis qui passent devant une cellule de détection. Les colis ont une certaine taille et se déplacent avec une certaine vitesse. On peut calculer la durée pendant laquelle ils sont détectés par la cellule. Si le temps de cycle de la boucle de traitement peut être supérieur à cette durée, il est possible que certains colis ne soient pas traités.

La copie d’écran suivante montre l’état général de l’application exemple « app1 » fournie avec « Ada for Automation » s’exécutant sur une plateforme Microsoft Windows 7® standard.

On note au niveau des « Scheduling Stats » de la tâche principale que pour une période configurée de 50 ms on obtient des retards de 10 à 20 ms le plus souvent mais avec des écarts qui peuvent être bien plus importants.

La copie d’écran ci-après montre un comportement bien meilleur à cet égard.

Que s’est-il passé entre ces deux exécutions ?

On a tout simplement utilisé une fonction de l’API Windows® pour le multimédia qui permet de modifier la résolution du timer qui participe à l’ordonnancement du système.

Par défaut, cette résolution sur Windows 7® est à 10 ms si je ne m’abuse, on la passe à 1 ms avec le petit programme inclus dans « Ada for Automation » dans le dossier « TimeBeginPeriod » du nom de la fonction utilisée :
http://msdn.microsoft.com/en-us/library/dd757624%28v=vs.85%29.aspx

Je dois cette méthode à un client qui pilote des machines spéciales avec une application programmée en C++ sous Microsoft Windows 7®. Il se reconnaitra je l’espère, je l’en remercie bien.

Pour autant, cela ne constitue qu’une amélioration, qui peut avoir des effets secondaires comme indiqué dans la documentation de cette fonction.

Cela ne remplace certainement pas les solutions temps réel dur que peuvent proposer des sociétés comme IntervalZero ou tenAsys.

Ce sera disponible au téléchargement très bientôt mais je peaufine un peu car j’ai également complété le binding de la libmodbus et toutes les fonctions de lecture / écriture de registres ou de bits sont maintenant utilisables, et utilisées dans les exemples. Un nouvel article en perspective…

Edit : ça doit être disponible à présent.

Cordialement,
Stéphane