De plus en plus d'utilisateurs de LabVIEW découvrent nos capteurs et nous demandent si nous comptons publier une librairie LabVIEW complète. Pour l'instant, la seule option offerte était de coder ses propres appels à notre librairie en ligne de commande, ce qui n'est ni très pratique ni très efficace. Nous avons donc décidé cette semaine de nous attaquer au problème pour offrir une vraie solution, et avons même déjà quelque chose à vous faire essayer. Ce n'est encore qu'un "proof of concept", mais nous comptons sur votre feedback et votre expérience pour que la forme finale de cette nouvelle librairie soit ce que vous souhaitez!
Edit dec 2019: une vraie librairie Yoctopuce pour LabVIEW est maintenant disponible.
LabVIEW: la problématique
LabVIEW est un environnement de programmation visuelle, particulièrement adapté pour interfacer des instruments de mesures. Les deux principales difficultés de principe que cet environnement pose pour intégrer notre gamme de produits sont:
- la nécessité d'un pilote pour LabVIEW, pour pouvoir discuter avec nos modules;
- la nécessité d'implémenter notre librairie LabVIEW via une interface graphique.
En ce qui concerne les pilotes, nous cherchons toujours (autant que possible) à les éviter: les pilotes sont des sources de soucis pour les utilisateurs, il faut les maintenir à jour séparément, ils posent des problèmes de portabilité, ils compliquent la migration des applications d'une machine à l'autre, bref, on ne les aime pas.
En ce qui concerne l'interface graphique, la problématique est d'assurer que la librairie reste à niveau avec tous les autres langages. Comme vous l'avez peut-être remarqué, une partie significative de notre librairie de haut niveau est générée automatiquement pour tous les langages de programmation. Ceci garantit à tous nos utilisateurs le même niveau de fonctionnalités et l'accès à toutes les nouvelles fonctions que nous rajoutons occasionnellement à nos modules, quelque soit le langage the programmation utilisé. Si une opération manuelle sur l'interface graphique de LabVIEW est nécessaire pour intégrer chaque changement à la librairie, des erreurs ou des omissions seront inévitables.
La solution au problème de pilote
Pour éviter l'utilisation d'un pilote natif qui doit être installé sur la machine, nous avons basé notre solution sur l'architecture NI-VISA, en utilisant le protocole réseau VXI-11 qui est supporté nativement par LabVIEW. Il a suffit d'ajouter le support pour VXI-11 à nos YoctoHub réseaux et au VirtualHub pour que les modules Yoctopuce soient reconnus comme des instruments par LabVIEW, et qu'il puisse ainsi communiquer très efficacement avec eux, en local ou à travers le réseau. C'est cette solution que nous vous proposons de tester aujourd'hui, sous Windows uniquement pour l'instant.
Voici comment nous avons défini l'instrument virtuel YRequest.vi, qui permet d'effectuer un requête sur un module Yoctopuce:
Ce VI prend en entrée l'adresse de l'instrument (le module) au standard VXI-11 et la commande SCPI à exécuter, et retourne le résultat. Voici un petit exemple simple d'utilisation:
Cet exemple lit simplement la mesure d'un Yocto-Temperature et l'affiche en texte et dans un thermomètre. Vous reconnaîtrez le numéro de série du module, précédé du préfixe "instr" obligatoire. La commande SCPI reprend la dénomination Yoctopuce habituelle (nom de fonction suivi par nom d'attribut), mais en suivant une syntaxe SCPI plus naturelle pour les utilisateurs de LabVIEW. Notez que dans cette première version il n'est pas possible d'abréger les noms SCPI et il faut respecter les majuscules/minuscules (contrairement au standard), mais cela sera corrigé dans la version finale.
La solution au problème de l'évolution de la librairie
L'utilisation de NI-VISA et VXI-11 fournit une brique réutilisable pour la plupart des opérations de bas niveau. Il sera néanmoins nécessaire d'y ajouter une abstraction de plus haut niveau équivalente à nos librairies pour chaque langage, afin de ne pas imposer à l'utilisateur de se référer à la documentation pour retrouver le nom de chaque attribut, ni de devoir faire des conversion explicites de chaîne en nombre comme nous l'avons fait ci-dessus. Pour cela, allons écrire un module Express VI qui permettra de sélectionner directement le type de module, la fonction et l'attribut à lire ou à modifier. A priori il devrait même être possible de faire cela sur la base d'un fichier texte de description des module, qui pourra être mis à jour automatiquement et ainsi garantir une mise à niveau constante de la librairie LabVIEW. Faites-nous part de vos bonnes et mauvaises expériences avec l'utilisation des Express VIs si vous en avez, nous pouvons encore changer d'approche si ça n'est pas la meilleure :-)
Un petit exemple d'automate LabVIEW
Pour terminer, voici un exemple un tout petit peu plus élaboré pour tester notre VI: il s'agit simplement de lire un potentiomètre, d'afficher sa valeur graphiquement et de commuter automatiquement un relais en fonction de la valeur du potentiomètre. Voici le diagramme bloc:
Et le voici en vrai:
Il ne vous reste qu'à essayer en chargeant la dernière version du VirtualHub pour Windows et ces quelques VIs. N'oubliez pas qu'il s'agit pour l'instant d'un "proof of concept", et que seul le strict minimum a été implémenté dans le support VXI-11 et SCPI. Mais si ça vous plait, la suite suivra... Alors faites-le nous savoir !