« LabVIEW : programmation et applications » ou comment apprendre à utiliser LabVIEW

LabVIEW est un environnement de développement complet, graphique, compilé et particulièrement bien adapté au domaine de l'acquisition et de la mesure. Son approche totalement graphique offre une souplesse et une dimension intuitive inégalée. Comparativement aux langages textuels, il offre la même puissance de programmation, mais sans le côté abstrait et complexe lié à la syntaxe.

Orienté tests et mesures, il dispose de nombreuses fonctions permettant de piloter facilement des cartes d'acquisition et autres instruments, mais aussi de filtrer, d'analyser et de présenter les données. Ce langage est également appelé code G. Le code est représenté par un schéma composé de fonctions, de structures et de fils qui propagent les données. L'approche visuelle, l'interface entre le code et le développeur s'opposent sur la forme et la philosophie aux langages textuels, comme le C. LabVIEW est redoutable de puissance et n'a rien à envier aux autres langages.

L'exemple suivant, grâce à l'animation, illustre le principe du flux de données. Il réalise un calcul mathématique très simple a x b + c.

1. La fonction « Multiply » s'exécute lorsqu'elle dispose des données à ses entrées (a=1 et b=2), donc dès le départ.
2. La fonction « Add », dispose de l'entrée « c = 3 », mais elle est en attente du résultat de la fonction « Multiply ». Dès que la valeur « 2 » est calculée en sortie de la fonction « Multiply », elle devient disponible pour la fonction « Add » qui va pouvoir être calculée.
3. La fonction, en bas à droite de l'image, permet d'attendre une seconde. Il est très important de constater que cette attente s'exécute en même temps que la fonction qui calcule a x b + c.

La fenêtre qui contient le code est appelée le diagramme. Cette notion sera développée par la suite.

LabVIEW est un des premiers langages de programmation graphique destinés au développement d'applications d'instrumentation. Un logiciel d'instrumentation pourrait être défini comme un programme permettant de contrôler depuis un ordinateur, un système allant du capteur à la chaîne d'acquisition ou de commande jusqu'à l'édition du rapport final. Couplé à des cartes d'entrées/sorties, il permet de gérer des flux d'informations numériques ou analogiques et de créer ou de simuler des instruments de mesure (oscilloscope, compteur, multimètre, etc.). Le temps nécessaire à l'assemblage des composants de ce type de système est négligeable par rapport à celui nécessaire à sa programmation dans un langage classique (C, Pascal, Ada, etc.). Les interfaces utilisateur, développées avec ces langages, sont le plus souvent obscures et incompréhensibles. Les utilisateurs disposent avec LabVIEW d'un puissant outil intégré d'acquisition, d'analyse et de présentation des données, une solution qui entraîne un gain notable de productivité comparable à celui obtenu par l'introduction des tableurs dans les logiciels financiers. Pour cela, le langage utilise toute la convivialité des interfaces interactives des ordinateurs actuels en fournissant des objets proches graphiquement des objets réels (voyants, curseurs, interrupteurs, boutons, graphes, etc.), mais aussi des commandes système (pour une représentation plus standard) ainsi que des outils familiers et simples d'utilisation pour la programmation (structures de programmation, fonctions arithmétiques, fonctions logiques, comparateurs, etc.).

Historiquement, un logiciel de mesure est un instrument de mesure qui est contrôlé depuis un ordinateur à la place des boutons sur sa face avant.

Cette logique conduit à la notion d'instrument virtuel: instrument réel contrôlé depuis un ordinateur.

Un instrument virtuel est donc un programme qui présente une interface sous forme graphique (IHM) pour l'apparenter à un instrument physique. Les utilisateurs manipulent alors des instruments depuis l'ordinateur (virtuels) comme s'il s'agissait d'instruments physiques sur «étagère» (réels).

Un programme ou VI, développé dans l'environnement LabVIEW, se compose principalement de deux éléments étroitement associés et regroupés sous le même nom « nom_application.vi » (l'extension .vi permet une reconnaissance immédiate par l'environnement LabVIEW). Ainsi nous avons :

·     La « face-avant » (Front panel) qui est l'interface utilisateur du programme au sens génie logiciel: définition des entrées/sorties de données accessibles par l'utilisateur du programme (figures 1.4, 1.5 et 1.18). Cette notion sera reprise en détail dans le chapitre 3.

Le « Diagramme » (diagram) qui est le programme de l'application ou code source. Il écrit sous la forme d'un diagramme flux de données en langage G : ensemble des icônes et des liaisons entre ces icônes utilisées (figure 1.19). Cette partie de l'application est ce que l'on appelle le code source par opposition à l'interface utilisateur.

Le développeur LabVIEW devra suivre la synthèse des commandements suivants pour s'assurer que son code est conforme aux règles de développement.

1. Sur un seul écran ton code tiendra.
2. De gauche à droite tu coderas.
3. Les fils tu ne croiseras pas.
4. La gestion de l'erreur tu ne transgressas pas.
5. Le connecteur de type 4x4 toujours tu utiliseras.
6. Les contrôles, indicateurs et sous-VI judicieux tu nommeras.
7. Le flux de données tu respecteras.
8. Ton code toujours et immédiatement tu documenteras.
9. Des sous-VI tu feras.
10. La structure séquence empilée tu refuseras.

Plus d'informations sur les règles de style à respecter avec LabVIEW dans le livre.

Sur une fonction de la palette, le moyen le plus simple est d'utiliser la fenêtre d'aide contextuelle : menu Aide, puis Visualiser l'aide ou Ctrl-H : si cette aide est active, il suffit de placer le curseur sur un élément pour avoir une aide simplifiée. Dans la fenêtre, il est possible d'accéder à une aide plus détaillée en cliquant sur le lien hypertexte.

Pour vous procurer des informations sur les concepts de programmation LabVIEW, des instructions détaillées : sélectionnez Aide puis Rechercher dans l'Aide LabVIEW.

Pour développer une nouvelle fonction, vous pouvez modifier un VI d'exemple pour l'adapter à votre application : Sélectionnez Aide puis Recherche d'exemples pour parcourir des centaines de VI d'exemple (chapitre 4).

Internet et surtout le site de National Instruments, www.ni.com, regroupent des liens vers des cours et formations, solutions utilisateur (voir paragraphe 6.6), VI d'exemple, support technique, groupes d'utilisateurs et forum. Il est très riche en contenu et constitue une réelle source d'inspiration. À noter qu'il existe en langue française :

• deux forums de discussions pour NI LabVIEW et autres sujets, avec des experts qui répondent rapidement à toutes les questions. Les forums francophones sont d'une très grande qualité. Pour les trouver, le plus simple est de faire une recherche sur Internet avec les mots-clés : « Discussions au sujet de NI LabVIEW » . J'interviens régulièrement sur le forum : http://forums.ni.com/t5/Discussions-au-sujet-de-NI/bd-p/4171;
• une communauté très dynamique qui organise des rencontres développeurs pour le partage de techniques, d'informations et de convivialité ;
• les blogs des développeurs certifiés, par exemple blog du développeur certifié LabVIEW, Luc DESRUELLE, pour plus d'exemplesblog du développeur certifié LabVIEW, Luc DESRUELLE, pour plus d'exemples

Pour une expertise, un besoin ponctuel ou pour sous-traiter un développement, nous vous conseillons de faire appel aux partenaires National Instruments du Programme Alliance. Ces partenaires ont reçu, après évaluation, l'agrément certifiant de leurs compétences en matière de programmation et de connaissances générales sur le logiciel LabVIEW. La liste est disponible sur le site de National Instruments. Vous aurez ainsi accès à des professionnels disposant des niveaux Certifié LabVIEW Développeur (CLD), voire Certifié LabVIEW Architecte (CLA). Ils seront les garants de la réussite de vos projets, avec un développement dans les règles de l'art. Pour les trouver, le plus simple est de faire une recherche sur Internet avec les mots-clés « partenaire alliance national instruments ».

Moi, Luc DESRUELLE, l'auteur du livre LabVIEW et de ce tutoriel, serait ravi de vous apporter mon expertise en tant que Certifié LabVIEW Architecte (CLA), au travers de la société MESULOG qui est partenaire National Instruments. Mais aussi l'ensemble de mes confrères…

La gestion de l'erreur n'est jamais une option, mais une obligation. Elle consiste à anticiper, détecter et résoudre les mises en garde et les erreurs. Sans cette gestion, le programme peut avoir un comportement incohérent, mais sans pouvoir en identifier la cause. Par exemple, sans gestion d'erreur, un programme pourrait réaliser une acquisition sur un instrument éteint, et sauvegarder sans problème les données sur un disque dur réseau qui n'existe pas. Un miracle ? Non un calvaire.

La structure de la donnée « erreur » au niveau de LabVIEW est un cluster formé des trois éléments suivants (figure 3.22) :

• État : un booléen qui est à l'état « Vrai » si une erreur s'est produite ;
• Code, un entier de 32 bits, qui contient le numéro de l'erreur ou « 0 » s'il n'y a pas d'erreur. Un code d'erreur différent de zéro avec un état « Faux » signale une mise en garde. Une mise en garde n'empêche pas le code de tourner, mais LabVIEW attire votre attention sur un point qu'il lui semble anormal.
• Source : une chaîne de caractères identifiant l'endroit où l'erreur s'est produite.

En code source, pour résoudre le problème, il est possible de faire un clic droit sur le bord du cluster d'erreur et de sélectionner Expliquer l'erreur (figure 3.23). Une boite de dialogue de gestion de l'erreur va s'ouvrir permettant de :

• expliquer l'origine en visualisant le nom du VI qui a généré l'erreur, dans notre exemple « Mon Code Acquisition.vi » ;
• proposer une ou des raisons possibles par rapport au code d'erreur, dans notre exemple LabVIEW propose la raison suivante : « La tâche spécifiée n'est pas valide ou n'existe pas », ce qui est le cas ;
• l'origine et la cause permettent en général de comprendre le problème et de le résoudre. Si cela n'est pas le cas, il faut utiliser les outils de débogage, comme les sondes et les points d'arrêt.

Tous les VI posséderont donc obligatoirement un « cluster d'entrée erreur » et un « cluster de sortie erreur ». Une exception peut être faite concernant les VI qui ne génèrent aucune erreur. Par exemple, un VI qui réalise le calcul « a²+b² ». Ce calcul est réalisé par des fonctions natives de LabVIEW qui ne génère pas d'erreur, le VI qui réalise ce code ne générera donc pas d'erreur. Cependant, même dans ce cas, il est intéressant d'ajouter à ce VI une entrée et une sortie « cluster d'erreur ». Cette entrée et cette sortie seront directement reliées entre elles. Ce « dispositif » permettra de positionner le VI dans le flux d'erreur global et donc de séquencer le code de la bonne façon.

Savez-vous répondre à la question (simple) suivante ? (niveau CLAD…)

L'explication n'est pas si simple.

Par définition les nœuds de propriété se synchronisent dans le thread « interface utilisateur »

• seul système d'exécution pas multithread, donc si occupé provoque des lenteurs ;
• la face avant du VI sera chargée en mémoire. Or les commandes et indicateurs, sur une face avant chargée en mémoire, ont leur propre copie des données. Il en résulte trois copies (buffer) des variables pour la mise à jour entre le diagramme et l'IHM.

La comparaison avec la variable globale engendre la même conclusion.

Finalement

VII-B-1. Histoire▲

VII-B-2. Principe et bénéfice▲

Une FGV est donc un registre à décalage non initialisé d'un VI non réentrant, qui permet de mémoriser une valeur dans le registre lors d'une commande « Écriture » (noté souvent « Set »), et de la retourner sur un « Lecture » (noté souvent « Get »), comme illustré à la figure 3.51.

Les bénéfices apportés par cette technique

• Une meilleure gestion des données en mémoire, car le stockage de l'information est unique, soit dans le registre à décalage du VI. Il supprime ainsi toutes les copies mémoires ou buffer, engendrées par la présence des globales et/ou locales. Cette méthode est d'un grand intérêt, surtout pour des structures de données complexes comme des tableaux de cluster.
• Possibilité d'ajouter une gestion de l'erreur, via le cluster d'erreur standard de LabVIEW et une structure condition. Il est ainsi possible d'éviter toute opération sur la FGV si une erreur est présente à son entrée. Il est à noter que cela est optionnel, mais conseillé.

Plus d'informations sur la gestion des données, notamment FGV, AE, DVR, programmation objet (OOP) sous LabVIEW dans le livre et le blog de Luc Desruelle.

Nous venons de voir que la gestion des données met en place des techniques de programmation particulières, type « globale fonctionnelle » ou Moteur d'action, afin d'optimiser la gestion mémoire, le flux de données et surtout la protection des ressources. Pour faire un programme, nous allons devoir assembler les sous-fonctions, gérer l'erreur, ajouter des structures, et autres. Que ce soit pour une boite de dialogue ou un programme d'acquisition, il y a des techniques à connaître spécifiques au logiciel LabVIEW.

Ce chapitre aborde les modèles de conception, en anglais design pattern. Il s'agit de techniques reconnues et éprouvées comme étant les bonnes façons de résoudre des problèmes donnés. Ce sont des solutions standard et indépendantes du logiciel de développement. La plate-forme LabVIEW fournit des exemples en code G des conceptions les plus courantes. Elles sont à connaître pour permettre une lecture plus rapide du code. Les respecter permettra d'obtenir une implémentation plus rapide, standard, évolutive et maintenable par d'autres développeurs.

VIII-B-1. Définition générale▲

VIII-B-2. Transcription en LabVIEW▲

Nous allons reprendre notre exemple précédent qui réalise une série de mesures de température, à la fréquence d'un point toutes les 5 secondes. Mais contrairement à l'exemple précédent, nous voulons que notre application réagisse en 125 ms à l'appui sur le bouton Stop, pour arrêter le programme. Nous voulons donc traduire le diagramme fonctionnel de la figure 3.61.

Il existe plusieurs versions pour traduire ce concept en langage G, nous les verrons au fur et à mesure dans ce chapitre.

Elle est composée par :

• Une boucle While, pour permettre l'exécution en continu du code ;
• Une structure Condition : chacun de ses états va reprendre par complète analogie un état du diagramme fonctionnel (figure 3.61) : « Démarrage ; Attente ; Mesure Arrêter ».

• La liste des états est représentée par les valeurs d'une énumération, qui sera déclarée comme une définition de type. Ce qui signifie :

  • Définition de type, la mise à jour du modèle sera répercutée sur toutes ses instances dans le code. Donc des états pourront être rapidement ajoutés et appliqués partout dans le code, par exemple dans des constantes (figure 3.17). Pour éditer la définition de type, faites un clic droit sur l'énumération et sélectionnez Ouvrir la déf. de type ;
  • La commande de type énumération, ou énum, lorsqu'elle est câblée au terminal de sélection d'une structure Condition, fait correspondre les conditions à la liste des éléments de l'énum (ou énumération). Le code est donc autodécrit. Si un état n'est pas présent dans la structure, le code ne sera pas exécutable ;
• Un registre à décalage, qui permet d'implémenter « chaque état définit l'état suivant ». Il est câblé au terminal de sélection de la structure condition, soit le symbole « ? ». À chaque itération de la boucle While, le contenu du registre à décalage définira donc, via la structure condition, l'état courant à exécuter. À la fin de l'exécution de chaque état, une constante de l'énumération d'états est câblée sur la sortie du registre à décalage, définissant ainsi le prochain état à exécuter.

Plus d'informations sur les modèles de conceptions avec LabVIEW dans le livre, mais aussi la présentation d'un modèle professionnel de projet « prêt à l'emploi » de type producteur consommateur avec structure événementielle, dont le code est disponible gratuitement en téléchargement.

Pour rappel avec LabVIEW 2012 sont arrivés les modèles de projet LabVIEW via le gestionnaire de projet. Il est livré quelques modèles, ou Framework, avec LabVIEW, dont les fameux QMH (Queue Driven Message Handler) ou modèle Gestionnaire de messages dans une file d'attente (GMF) en français et l'Actor Framework.

Même si l'Actor Framework est passionnant, il reste difficile à utiliser pour les non-spécialistes. Le Queue Driven Message Handler, plus connu sous le petit nom de QMH ou QDMH, est un incontournable qui est très simple d'utilisation.

La structure proposée par le modèle QMH repose sur un modèle éprouvé d'une structure producteur - consommateur, dans lequel :

• (la boucle productrice) la structure événementielle capture les actions utilisateurs, sur la face avant, et produit le « message » via une FIFO ;
• le message est un cluster composé d'un état « case » et une donnée facultative Data de type variant ;
• (la boucle consommatrice) la structure consommatrice, basée sur un modèle de machine à états, dépile sur apparition les données de la FIFO. Le message définit une transition vers l'état avec la donnée associée. Le « case » de la structure « Message » est une chaîne qui correspond à un des sous-diagrammes de la structure Condition. Par conséquent, la lecture du message provoque l'exécution du sous-diagramme correspondant de la structure Condition. Ce sous-diagramme est appelé diagramme de message, car il correspond à un message ;
• ces boucles s'exécutent en parallèle et sont connectées par la file d'attente de messages, qui facilite la communication entre les boucles ;
• votre application peut avoir plusieurs « Boucle Consommatrice », QMH = Actor, chaque boucle correspond à une tâche effectuée par l'application.

Alors, pourquoi utiliser un modèle personnalisé ? Le modèle proposé par National Instruments est un modèle, qui mérite des améliorations, vos améliorations, mais la structure « Message et file d'attente FIFO » est à garder. Je vous conseille donc de générer VOTRE projet, MAIS sur la base du QMH, de regarder la très bonne documentation HTML livrée avec le projet, et de modifier le code.

Gestionnaire de messages dans une file d'attente :

L'exemple donné par le QMH :

• quitte l'application sur « erreur » -> remplacer « Exit » par « Error »« et ajouter un état dans la »Boucle de gestion de messages« . Remarque : la « Message Queue.lvlib » est distribuée en « support VI ». Elle n'est pas dans la vi.lib ni la user.lib. Vous pouvez donc la modifier. Je vous propose de renommer la lvlib, pour faire la différence avec la lvlib d'origine.

  

• ne sauvegarde pas ni ne gère l'erreur, qui est donc fatale -> dans l'état « Error » ajouter un affichage de l'erreur ainsi que la sauvegarde et le filtrage si l'utilisateur le décide ;

• n'affiche pas la version du logiciel -> ajouter les VI de gestion de version de LabVIEW ;

• la structure event driven sort sur erreur -> remplacer par un VI qui transfère l'erreur à la « Boucle de gestion de messages » via la FIFO

  

• supprimer le code « exemple » ;

• n'a pas votre personnalisation! Ajouter votre logo ;

• autres…

Les architectures des instruments E/S (figure 4.8) et des cartes DAQ (figure 4.7) font apparaître deux éléments communs que sont le driver et le logiciel d'application. Aucun système de mesure par ordinateur n'est complet sans logiciel. L'application est le code réalisé pour permettre à l'utilisateur de piloter la chaîne d'instrumentation, analyser, sauvegarder et présenter les données.

Le driver est le programme qui fait le lien entre le logiciel d'application et le matériel. Il est chargé de traduire les commandes LabVIEW pour les rendre compréhensibles par la carte ou l'instrument. Il facilite le travail des développeurs en évitant une programmation fastidieuse et spécifique dans les registres bas niveau de la carte. Voici quelques exemples.

• Les cartes d'acquisition et génération de signaux : National Instruments fournit un driver unique qui est compatible avec toutes les cartes, qui est NI-DAQmx. Nous détaillerons ses fonctionnalités dans le chapitre 4.2.
• Les instruments autonomes sur table : nous utiliserons le driver VISA ou IVI. Nous détaillerons ses fonctionnalités dans le chapitre 4.3.
• Les instruments modulaires : nous utiliserons le driver VISA ou IVI ou un driver spécifique livré par le fabricant avec le matériel.

Après avoir analysé l'ensemble de la chaîne d'instrumentation physique, il reste un élément à sélectionner : l'ordinateur et sa cible d'exécution. En effet, prenons l'exemple d'une machine de surveillance d'un laser effectuant une intervention chirurgicale sur la rétine d'un œil humain. Personne n'acceptera une telle intervention si l'ordinateur fonctionne sous un système d'exploitation Windows, alors que l'antivirus réalise une mise à jour. La mise à jour n'est bien évidemment qu'un exemple et permet de mettre en évidence que le système est susceptible d'être interrompu à tout moment. Un arrêt d'urgence ne peut pas être géré par un système « standard ». Pas plus qu'un système de surveillance réalisant une analyse pendant plusieurs mois et qui ne devra pas être redémarré par le service informatique de l'entreprise.

Les cartes d'acquisitions de National Instruments sont pilotées via les VI NI-DAQmx dans LabVIEW.

Le driver NI-DAQmx installe sous LabVIEW une API, Application Programming Interface, qui est une bibliothèque de fonctions, constituée de VI et de propriétés. Cette API va permettre d'utiliser les fonctions du driver. La palette est disponible sous E/S de mesures → DAQmx (figure 4.12). Elle est très intuitive et contient un nombre réduit de VI qui correspondent aux fonctionnalités principales, approximativement 90 % des besoins : lecture, écriture, cadencement, déclenchement. Ce sont les mêmes fonctions qui sont utilisées pour les signaux analogiques et numériques. Pour les fonctionnalités avancées, il faut utiliser les propriétés, mais nous n'en aurons pas besoin dans les exemples du livre.

La bibliothèque a un nombre limité de VI, car ils sont polymorphes, c'est-à-dire qu'ils s'adaptent à des types de données différents. C'est un ensemble de VI qui a le même modèle de connecteur. Par exemple, il n'y a qu'une seule fonction « Lecture DAQmx », car elle s'adapte à la lecture des données de signaux de type analogique, numérique ou compteur, pour une voie unique ou multiple, en retournant un échantillon unique ou multiple, sous la forme d'un nombre ou d'une Waveform. Cette liste est accessible en cliquant dans le menu sous l'icône du VI (figure 4.13). Quelques exemples des possibilités des VI LabVIEW DAQmx pour les fonctions lecture et écriture sont présentés dans les tableaux 4.6 et 4.7. Les données E/S sont soit une valeur scalaire, un tableau 1D, un tableau 2D, ou une Waveform.

Il y a plusieurs techniques de mesure. L'acquisition de données « point à point » est la plus simple : acquérir un seul échantillon sur demande, attendre, de nouveau acquérir un seul échantillon et ainsi de suite. Dans cette opération, le driver NI-DAQmx acquiert une valeur d'une voie en entrée et renvoie immédiatement cette valeur exemple de code de pilotage…

Synthèse DAQmx

DAQmx est le driver de pilotage des cartes d'acquisition de National Instruments. Il installe sous LabVIEW une API qui est une bibliothèque de VI très simple à utiliser.

Une voie virtuelle est un ensemble de paramètres comprenant un nom, une voie physique, des connexions, le type de mesure ou de génération et optionnellement des informations de mise à l'échelle. Il faudra soit la créer dans MAX, soit dans le programme LabVIEW.

Il existe trois types de tâches :

• point à point : acquisition d'un seul échantillon sur demande avec un cadencement logiciel ;
• fini : acquisition de plusieurs échantillons avec le cadencement matériel de la carte ;
• continu : acquisition de plusieurs échantillons avec le cadencement matériel de la carte ; recommencer cette acquisition en continu. Les données sont mises à disposition dans un buffer circulaire qu'il convient de lire périodiquement depuis l'application.

Il est possible de créer un système d'acquisition et de génération simultanée de données en combinant les tâches DAQmx.

Measurement And Automation Explorer, abréviation MAX, est un logiciel complémentaire qui s'installe avec le driver NI-DAQmx. Il va permettre de configurer, créer, tester et diagnostiquer l'ensemble du système d'entrées/sorties de données (figure 4.19). Il donne accès à l'ensemble du matériel et logiciels de National Instruments. Son utilisation est donc beaucoup plus large que celle décrite dans ce chapitre.

L'accès à ce logiciel de configuration se fait soit directement par l'icône du logiciel, soit dans une fenêtre LabVIEW à partir du menu Outils, puis Measurement And Automation Explorer (figure 4.18).

L'utilitaire présente sous forme d'une arborescence les éléments de configuration de votre ordinateur. Lors de la sélection d'un élément de l'arborescence, la partie droite de l'utilitaire présente des panneaux additionnels de configuration et/ou d'information.

Les éléments qui nous intéressent ici sont :

• Périphériques et interface : le matériel connecté à votre ordinateur est listé sous cette rubrique ;
• Voisinage de données : les tâches et voies virtuelles DAQmx configurées sur cet ordinateur ;
• Échelles : les échelles DAQmx qui sont configurées sur cet ordinateur.

Définitions paramètres DAQmx sous MAX

• Une voie physique est un terminal ou broche sur lequel vous pouvez mesurer ou générer un signal analogique ou numérique. Chaque voie physique a un nom unique.
• Une voie virtuelle est un ensemble de paramètres qui peuvent inclure un nom, une voie physique, des connexions d'entrée, le type de mesure ou de génération et des informations de mise à l'échelle.
• Une tâche se compose d'un ensemble d'une ou de plusieurs voies virtuelles et comprend le cadencement, le déclenchement et d'autres propriétés. Une tâche représente la mesure ou la génération que vous voulez réaliser.

Tester le fonctionnement de la carte

La première action consiste à vérifier le bon fonctionnement de la carte d'entrées/sorties, dans Périphériques et interfaces, qui permet de :

• Visualiser la configuration d'un périphérique existant ;
• Diagnostiquer son fonctionnement via « Panneaux de test » ;
• Créer un périphérique simulé. Cette possibilité est très utile pour le développeur quand le matériel n'est pas disponible. Il est donc possible de simuler le matériel que nous utilisons dans le livre et de réaliser tous les exemples ;
• Accéder au « Brochage du périphérique » pour connaître le câblage des voies sur la carte.

IX-D-1. Trouver un driver d'instrument : IDNet▲

IX-D-2. Zoom sur les fonctionnalités de VISA▲

L'API du driver VISA, Virtual Instrumentation Software Architecture, installe sous LabVIEW une bibliothèque de fonctions constituées de VI et de propriétés. Elle va servir à créer des applications pour les instruments de mesure. Cette bibliothèque est très intuitive, mais contrairement à la bibliothèque NI-DAQmx, elle contient un nombre important de VI, avec des sous-bibliothèques spécifiques à chaque bus de communication. Dans la réalité, seulement six fonctions sont nécessaires pour écrire la très grande majorité des drivers (figure 4.54 et 4.55).

Ouverture, Fermeture de la communication et Timeout

Ces trois fonctions (ouverture, fermeture et timeout) sont disponibles dans la palette VISA avancée. Ce sont les trois paramètres de base de la communication avec un instrument de mesure :

N° 1 un driver commence toujours par un VISA Open qui permet d'ouvrir une session sur le périphérique spécifié, à faire une seule fois en début de programme ;

N° 2 la fonction d'ouverture est toujours suivie par la configuration du TimeOut, qui est le temps d'attente maximum lors d'une interrogation sur l'instrument, par défaut 10 secondes. Elle est disponible au travers d'une propriété ;

N° 3 le code du driver se termine toujours par un VISA Close qui permet de fermer la session sur le périphérique (à faire une seule fois uniquement en fin de programme).

Écriture des données dans l'instrument

N° 4 Pour écrire des données dans l'instrument, on utilise VI VISA Write. Nous utiliserons uniquement la communication basée sur des messages, c'est-à-dire avec l'envoi de chaînes de caractères ASCII, et pas celle basée sur l'écriture de registre.

Lecture des données dans l'instrument

N° 5 Pour la lecture des données retournées par l'instrument, on utilise VI VISA Read. Il est très important de comprendre que cette fonction retourne les données contenues dans le buffer dès qu'une de ces trois conditions est présente :

• un caractère de terminaison est arrivé, par exemple dans le cas d'une communication sur un bus série (voir figure 4.57) ;
• le nombre d'octets dans le buffer de réception est égal à celui passé en paramètre à la fonction VISA Read (voir figure 4.56) ;
• le temps d'attente a dépassé le TimeOut configuré par la fonction VISA Open. Dans ce cas LabVIEW retourne un code d'erreur, 0xBFFF0015, le délai d'attente (timeout) a expiré avant que l'opération ne soit achevée.

Plus d'informations sur la création de drivers d'instrument avec LabVIEW dans le livre, avec des exemples concrets et détaillés.

De nombreux outils gratuits de ce réseau sont devenus indispensables au développeur LabVIEW, car ils permettent de gagner beaucoup de temps. Après téléchargement depuis le VIPM, ils seront directement disponibles dans la palette LabVIEW

Les bibliothèques OpenG contiennent des centaines de VI en open source créés par la communauté OpenG et partagés dans le cadre de la licence BSD-3-Clause (approuvée par Open Source Initiative). Cela permet une utilisation commerciale dans vos applications propriétaires. Ces bibliothèques sont indispensables pour vos projets LabVIEW, à télécharger gratuitement, elles contiennent des VI réutilisables couvrant tous les domaines d'applications. Elles incluent : 

• la manipulation de tableaux ;
• la manipulation de chaînes de caractères ;
• la gestion de fichiers ;
• la manipulation de données variant et aplaties ;
• etc.

La figure 6.36 montre comment télécharger directement dans LabVIEW ces bibliothèques, en les sélectionnant depuis le logiciel VIPM, clic droit et installer.

Comme évoqué au chapitre 2.3.3, lors de la mise au point du code, l'utilisation de l'outil « Sonde » (probe) de la palette Outils permet de vérifier des valeurs intermédiaires dans un diagramme flux de données. LabVIEW propose un grand nombre de sondes pour permettre cette mise au point de votre code. Elles sont bien entendu très utiles, mais restent souvent basiques.

Les sondes personnalisées proposées par l'équipe des développeurs de la société SAPHIR proposent de nombreuses sondes alternatives. Installées facilement au travers du VIPM, elles permettent d'étudier le comportement de votre code en cours d'exécution de manière plus appropriée. Nous allons détailler quelques exemples des sondes les plus utilisées :

• la sonde « History »  stocke les valeurs d'une chaîne de caractères. À chaque appel de la sonde, la valeur de la chaîne surveillée est ajoutée à une table, avec l'affichage de l'heure à laquelle la chaîne a été lue. La sonde History permet à l'utilisateur de définir des filtres d'affichage à l'aide d'expressions rationnelles. Elle offre la possibilité de mettre en pause l'exécution du programme si la chaîne de caractères remplit certaines conditions : contenir un motif particulier, atteindre une certaine longueur, etc. Cette sonde est utilisée pour la mise au point d'une machine à état pilotée par chaîne de caractères, voir chapitre 3.4.3, ou la surveillance de données renvoyées par un instrument de mesure ;
• la sonde « Delta » affiche sur un graphique déroulant l'évolution d'une valeur, ainsi que son écart avec la valeur précédente. De plus elle permet de mettre en pause l'exécution du programme si la valeur mesurée et/ou l'écart calculé dépassent un seuil défini par l'utilisateur. Cette sonde est utilisée pour la vérification de l'évolution d'une valeur (par exemple un delta temporel) au cours du temps ;
• la sonde « Chronographe » fournit des informations relatives aux durées d'exécution de vos programmes. Elle mesure les durées  entre chaque appel de cette sonde ou entre les appels d'autres sondes du Toolkit VIBox Probes. Cette sonde est utilisée pour la vérification du cadencement d'une boucle ou la détection des parties de code consommatrice en temps processeur.

Plus d'informations au sujet des sondes SAPHIR via le LabVIEW Tools Network et en téléchargement sur le VI Package Manager.