La quasi-totalité des fonctionnalités de l'API Yoctopuce sont présentes dans la librairie LabVIEW, cela représente plus de 2000 fonctions différentes disponibles à travers plus de 80 classes. Cependant, il n'y a qu'un VI par classe, comment a-t-on réussi à tasser une moyenne de 25 appels par VI? Cette semaine, on vous propose de vous expliquer plus en détails le concept des objets proxy de l'API Yoctopuce pour LabVIEW.
Les VIs Yoctopuce
Les VIs Yoctopuce ont été conçus pour donner un accès immédiat aux propriétés qu'on a jugé les plus importantes pour chaque classe. Par exemple, la lecture d'un capteur de température se fait de manière assez immédiate:
La manière la plus simple de lire un capteur de température avec la libraire LabVIEW
Il suffit de:
- Initialiser l'API Yoctopuce avec le VI RegisterHub
- Lire la température avec le VI Temperature
- Libérer l'API avec le VI FreeAPI
Ici, on a utilisé directement la sortie currentValue, mais comment accéder aux fonctionnalités plus avancées? par exemple, comment demander au capteur de température quelles sont les valeurs minimales et maximales qu'il a observées? C'est prévu, il suffit de mettre l'entrée "create ref" à TRUE et on obtient sur la sortie "optionnal ref" une référence sur l'objet Proxy correspondant au capteur. Cet objet Proxy sert à gérer le capteur en tâche de fond et à permettre l'accès à toutes les méthodes et propriétés relatives au capteur de Température, y compris get_highestValue() et get_lowestValue().
Utilisation de l'objet TemperatureProxy pour connaître les valeurs min et max
Par contre, il est important de ne pas oublier de fermer la référence une fois que l'on n'en a plus besoin. Notez que "fermer la référence" ne fait que ce qui est marqué sur l'étiquette: à savoir signaler à LabVIEW qu'on n'a plus besoin d'interagir avec cet objet Proxy, qui lui continue d'exister et de vivre sa vie en tâche de fond.
Comment ça marche?
Si on regarde le code source du VI Temperature, on comprend assez facilement le principe. Lorsque que vous utilisez le VI Temperature de la librairie Yoctopuce, un appel est fait à la classe statique YoctoProxyManager. Cet appel sert à obtenir une référence sur l'objet Proxy correspondant au nom de donné en paramètre. En l'absence de nom, l'objet renvoyé correspondra au premier capteur trouvé. Notez que si aucun capteur ne peut être trouvé, on obtient une référence valide mais qui pointe sur un capteur lambda qui se déclare comme "Hors ligne".
Source du VI Temperature
Cette référence sur l'objet Proxy est utilisée pour récupérer la valeur de toutes les propriétés interfacées directement par le VI. Une fois toutes les propriétés nécessaires gérées, soit le paramètre create ref est à FALSE (valeur par défaut) et la référence est fermée, soit il est à TRUE et la référence vous est retournée directement via la sortie "optionnal ref", et c'est à vous d'en faire bon usage.
Un autre exemple un peu moins trivial
Ce mécanisme peut passer pour du luxe sur des classes aussi simples que Temperature, mais il est vraiment indispensable pour des classes plus complexes. La classe Display en est le parfait exemple. Pour afficher un simple "Hello" sur un écran de multiples appels sont nécessaires.
Afficher 'Hello' en haut à gauche d'un écran Yoctopuce
- On utilise le VI Display pour obtenir une référence sur l'objet YDisplayProxy
- On utilise cette référence pour faire un appel à resetAll, qui efface tout l'écran
- Toujours avec cette référence, on appelle get_displayLayer(1) et on obtient une autre référence, de type YDisplayLayerProxy, sur la couche N°1 de l'écran
- Puis cette référence sur la couche n°1 est utilisée pour afficher le texte "Hello" à la position 0,0 avec un alignement TOP/LEFT. La constante d'alignement est fournie par la classe "YDisplayLayerProxy".
- Enfin, les références sont fermées et l'API libérée
Conclusion
Si votre utilisation des modules Yoctopuce se limite à la lecture d'un capteur ou la commutation d'un relais, les VI fournis seront amplement suffisants. En revanche, si avez besoin de gérer des comportements un peu complexes, vous aurez à utiliser ces références sur les objets Proxy. Mais, on vient de le voir, c'est loin d'être insurmontable. Pour finir, voici les quelques points que vous ne devez pas perdre de vue:
- Par convention, les propriétés de l'API proxy sont gérées à l'aide d'un cache par la librairie et peuvent être appelées aussi souvent que vous le désirez sans pénaliser le temps d'exécution
- La plupart des méthodes de l'api proxy entraînent des communications explicites avec les modules et doivent être appelées à bon escient. Plus il y aura de communications, plus votre code sera lent.
- Toutes les références doivent être fermées, sinon LabVIEW va rapidement tomber à court des ressources.
Enfin, notez que les quelques exemples donnés ici ne font pas de traitement d'erreur, ne les recopiez pas tels quels dans une application de production.
