From Friday, January 17th 11 PM CDT (January 18th 5 AM UTC) through Saturday, January 18th 11:30 AM CDT (January 18th 5:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Une application LabVIEW bien conçue est essentielle pour maximiser l’efficacité en matière de développement et de maintenance des logiciels. Ce document présente les constructions de base, les modèles de conception et les architectures spécifiques à la conception logicielle dans LabVIEW. Ce contenu n’est pas exhaustif, mais constitue plutôt un point de départ utile avec certains des éléments de conception logicielle LabVIEW les plus courants. Cliquez sur les liens dans le document pour obtenir des informations plus détaillées.
Chacune des sections suivantes décrit une construction commune utilisée dans la programmation LabVIEW pour accomplir une tâche spécifique. Une bonne connaissance de ces constructions de base vous permettra de reconnaître et de comprendre plus facilement leur utilisation au sein d’une application LabVIEW.
Les définitions de type (souvent abrégées en « typedefs ») vous permettent de spécifier un type de données qui sera défini de manière cohérente dans l’ensemble de votre application. Voici, par exemple, la définition du type cluster :
Lorsque vous déposez cette typedef sur une face avant ou un diagramme, elle apparaîtra comme un cluster, mais avec un triangle noir dans le coin supérieur gauche sur ses terminaux et de ses constantes :
Les typedefs sont particulièrement utiles pour définir des types cohérents dans l’ensemble de votre application. Pour illustrer cela, regardez ce qui se passe si nous ajoutons un nouveau paramètre (dans ce cas, un chemin de configuration) à la typedef :
En modifiant la typedef à un seul emplacement (le fichier source typedef .ctl), ce changement se propage automatiquement dans l’ensemble de l’application :
Si le cluster n’était pas une typedef, chaque instance du cluster (sur les faces avant et les diagrammes) dans l’ensemble de votre application devrait être mise à jour manuellement. À de rares exceptions près, vous devriez définir la typedef de tous les clusters et des types énumérés que vous créez lors de l’écriture de vos applications LabVIEW.
En utilisant des typedefs, vous améliorez la maintenabilité de votre code en utilisant un seul type de données partagées.
La structure Évènement permet de répondre aux évènements de l’interface utilisateur et aux évènements de programmation sur un diagramme LabVIEW. Vous pouvez, par exemple, enregistrer un diagramme d’évènement qui s’exécutera chaque fois que la valeur d’une commande du panneau avant changera. Vous pouvez aussi vous abonner à des évènements générés par programmation sur un diagramme à l’aide de la fonction Générer un évènement utilisateur.
Une structure Évènement est généralement placée à l’intérieur d’une boucle While pour que le code puisse répondre à plusieurs évènements tout au long de l’exécution du code. Configurez la structure Évènement afin d’avoir des cadres différents pour les différents évènements que vous voulez détecter. Chaque cadre d’évènement contient le code de gestion qui s’exécute à chaque fois que l’évènement en question se produit.
Consultez les projets suivants, fournis avec LabVIEW, pour obtenir plusieurs exemples illustrant les évènements de l’interface utilisateur et les évènements de programmation :
La variable globale fonctionnelle (également appelée « VGF », « LabVIEW 2 Style global » ou « Action Engine ») est un mécanisme de stockage de données. La VGF stocke des données dans un registre à décalage ou un nœud de rétroaction non initialisé et permet d’accéder à ces données n’importe où (c’est-à-dire « globalement ») au sein d’une application. Le diagramme d’une VGF VI de base est représenté ci-dessous et contient des Données d’entrée et des Données en sortie, ainsi qu’un enum Opération avec deux actions (« Définir » et « Obtenir ») :
La fonctionnalité offerte par cette simple VGF obtenir/définir revient à utiliser une variable globale. En pratique, votre VGF effectuera probablement d’autres fonctions que « définir » et « obtenir ».
Vous pouvez utiliser la VGF pour stocker des références et effectuer des opérations plus sophistiquées. Vous pouvez, par exemple, observer la VGF d’entrée/de sortie sur fichier ci-dessous (qui illustre l’utilisation d’un registre à décalage non initialisé au lieu d’un nœud de rétroaction). Cette VGF stocke la référence du fichier entre des appels successifs et effectue différentes actions (ouvrir, lire, écrire et fermer) dans un seul VI.
Notez que les VGF sont tout aussi sensibles aux situations de compétition que les variables globales. En règle générale, vous devez éviter d’écrire des données globales à plus d’un emplacement dans votre code.
Une face avant secondaire est une commande de face avant qui peut afficher la face avant d’un autre VI. L’utilisation d’une face avant secondaire vous permet de concevoir une interface utilisateur dynamique dans laquelle vous pouvez intervertir des sections entières de votre interface utilisateur en spécifiant un autre VI à afficher dans la face avant secondaire. La face avant secondaire facilite également le développement d’applications modulaires, où des groupes logiques d’éléments de la face avant peuvent être contenus dans des VI distincts. Avec cette conception, vous pouvez modifier des VI individuels qui s’affichent dans des faces avant secondaires sans modifier le code d’autres VI d’affichage ou du VI principale de l’application.
L’exemple ci-dessous analyse un dossier à la recherche de plug-ins VI et remplit un menu déroulant texte avec ces plug-ins. Lorsque vous sélectionnez un élément dans le menu déroulant texte, le plug-in VI correspondant est inséré dans la face avant secondaire du VI principal. Cette construction vous permet d’ajouter de nouveaux plug-ins VI sur le disque sans apporter de modifications au VI principal.
Exécutez l’exemple suivant, fourni avec LabVIEW, afin de vous familiariser avec les faces avant secondaires :
Par défaut, les VI dans LabVIEW ne sont pas réentrants. Cela signifie simplement qu’une seule instance d’un VI peut s’exécuter à la fois. Ainsi, dans le diagramme suivant, l’une des instances sous-VI de « Process.vi » doit attendre que l’autre se termine.
Si vous voulez que plusieurs instances d’un VI puissent s’exécuter en parallèle, vous devez rendre le VI réentrant. Pour ce faire, allez dans Fichier > Propriétés du VI > Exécution et définissez le paramètre « Réentrance » sur Exécution réentrante du clone partagé ou sur Exécution réentrante du clone préalloué.
Une fois que vous avez modifié un VI pour qu’il soit réentrant, plusieurs instances peuvent s’exécuter en parallèle :
Pensez à rendre vos VI réentrants dans les situations suivantes :
Notez que les Variables globales fonctionnelles seront presque toujours non réentrantes, car elles traient des données d’état globales que l’ensemble de l’application doit partager.
Exécutez l’exemple suivant, fourni avec LabVIEW, afin de vous familiariser avec les VI réentrants :
La plupart du temps, lorsque vous sollicitez un VI à partir d’un autre VI, vous utilisez un appel de sous-VI. Lorsque vous appelez un sous-VI, le diagramme appelant doit attendre que le sous-VI ait fini de s’exécuter avant de pouvoir continuer. Il s’agit d’un exemple d’un appelsynchrone.
Cependant, dans certaines situations, une application peut vous demander de lancer un sous-VI, mais de poursuivre l’exécution du VI appelant pendant que le sous-VI continue de s’exécuter. Il s’agit d’un exemple d’un appelasynchrone. Avec les appels de VI asynchrones, vous pouvez exécuter dynamiquement n’importe quel nombre de VI en parallèle. De plus, l’utilisation de VI réentrants vous permet de générer un nombre arbitraire d’instances du même VI et de les exécuter de manière asynchrone.
Dans l’exemple ci-dessous, le VI appelant appelle plusieurs instances du VI Process réentrant de manière asynchrone. Chaque VI s’exécute indépendamment et renvoie des données au VI appelant lorsqu’il a terminé. Le VI appelant peut exécuter d’autres codes du diagramme en parallèle et ne pas attendre que les instances du VI Process se terminent.
Consultez le projet suivant, fourni avec LabVIEW, pour obtenir plusieurs exemples illustrant plus en détail les appels de VI asynchrones :
La programmation orientée objet est facilitée dans LabVIEW par les classes LabVIEW. La programmation orientée objet LabVIEW utilise des concepts d’autres langages de programmation orientés objet comme C++ et Java, notamment la structure de classes, l’encapsulation et l’héritage. Vous pouvez utiliser ces concepts pour créer un code plus simple à maintenir et à modifier sans affecter d’autres sections de code au sein de l’application. Il existe de nombreux modèles de conception orientés objet pouvant être appliqués à LabVIEW. Ceux-ci sont décrits dans le document Application de modèles de conception communs orientés objet (OO) à LabVIEW.
Consultez les projets du dossier suivant, fourni avec LabVIEW, pour obtenir plusieurs exemples illustrant les bases de la programmation avec les classes LabVIEW :
Un modèle de conception est un mécanisme théorique d’exécution de code synchrone ou asynchrone. La plupart des architectures du monde réel (voir section ci-dessous) utilisent un ou plusieurs modèles de conception dans le cadre de leur mécanisme d’exécution de base. Comprendre le comportement des modèles de conception présentés dans cette section peut vous aider à mieux comprendre le comportement d’architectures plus complexes basées sur ces modèles de conception.
Une machine à états est l’implémentation du diagramme LabVIEW d’un diagramme d'états ou d’un organigramme. Un «état» donné aura une logique de diagramme pour déterminer l’état suivant à exécuter. Certaines machines à états sont commandées par une interface utilisateur, dans laquelle l’entrée utilisateur ou la logique du diagramme peuvent déterminer quel état sera ensuite exécuté.
Une machine à états LabVIEW de base se compose des éléments principaux suivants :
Consultez le projet suivant, fourni avec LabVIEW, pour en savoir plus sur les machines à états :
Créez votre propre projet de machine à états dans LabVIEW avec le modèle de projet Machine à états simple ; accédez au menu Fichier de LabVIEW >> Créer un projet >> Machine à états simple. Vous pouvez utiliser ce modèle comme point de départ pour votre propre application.
Le modèle de conceptionproducteur/consommateur illustre comment utiliser une file d’attente pour partager des données entre différentes boucles fonctionnant à des rythmes différents. La boucle qui contient une fonction Ajouter un élément à une file d’attente est le « producteur », et la boucle qui contient une fonction Supprimer le premier élément d’une file est le « consommateur ». L’utilisation d’une file d’attente garantit que les données ne sont pas perdues si les boucles s’exécutent à des rythmes différents.
Il est important de garder à l’esprit que le modèle de conception producteur/consommateur est en grande partie théorique. En pratique, vous verrez rarement le modèle fondamental producteur/consommateur dans un code réel. Au lieu de ça, vous verrez probablement le Gestionnaire de messages dans une file d’attente.
Exécutez l’exemple suivant, fourni avec LabVIEW, pour en savoir plus sur l’utilisation des files d’attente pour partager des données entre les boucles :
Le Gestionnaire de messages dans une file d’attente (GMF) est une implémentation du modèle de conception producteur/consommateur qui inclut aussi une structure d’évènement pour l’interface utilisateur et la génération d’évènements par programmation. La Boucle de gestion des évènements (BGE) comprend une structure d’évènements qui place dans une file d’attente (produit) les messages pour la Boucle de gestion des messages (BGM), qui les supprime de la file d’attente (consomme). La BGM peut aussi générer des messages pour elle-même si nécessaire. Dans ce cas, les « messages » sont des clusters contenant une chaîne (qui détermine la structure Condition dans la BGM) et une variante, qui peut contenir des données spécifiques à un message de n’importe quel type. Dans le GMF, la BGM peut aussi communiquer avec la BGE à l’aide d’évènements utilisateur.
Consultez le projet suivant, fourni avec LabVIEW, pour en savoir plus sur les GMF :
Créez votre propre projet de GMF dans LabVIEW avec le modèle de projet GMF ; accédez au menu Fichier de LabVIEW >> Créer un projet >> GMF.
Pour qu’une application LabVIEW de grande taille soit extensible et facile à entretenir, elle doit être bien conçue.
Imaginez une application LabVIEW théorique qui teste un périphérique. Il y aura du code pour configurer l’application, se connecter au périphérique, prendre des mesures, afficher les données, enregistrer les données, gérer les conditions d’erreur et potentiellement beaucoup d’autres fonctions.
Si toutes les fonctionnalités décrites de cette application se trouvent sur le même diagramme LabVIEW, il sera impossible de développer, de tester et de déboguer les fonctionnalités de l'application de manière isolée. Par exemple, s’il y a un problème dans le code d’enregistrement, il n’y a aucun moyen de déboguer uniquement l’enregistrement sans exécuter l’application entière. De plus, une modification du code d’enregistrement risque d’affecter par inadvertance une autre partie de l’application puisqu’elle se trouve dans le même VI.
Chacune des fonctions décrites ci-dessus conviendrait mieux à un processus asynchrone, où chaque fonction est modulaire et peut être développée, testée et déboguée indépendamment. Un mécanisme de communication solide entre les processus serait également nécessaire.
Une approche structurée de l’implémentation du code LabVIEW pour faciliter ce type de conception asynchrone modulaire est appelée architecture. Certaines équipes LabVIEW développent leurs propres architectures. Cette tâche peut s’avérer difficile, car il existe de nombreuses considérations, de nombreux pièges et avertissement associés au développement de l’infrastructure du code et de la messagerie nécessaires pour implémenter une application LabVIEW asynchrone réussie. De plus, la quantité de code passe-partout nécessaire pour implémenter un framework solide requiert des outils suffisants au sein du framework pour automatiser les tâches répétitives (pour aider les développeurs à éviter de commettre des erreurs lorsqu’ils essaient de programmer eux-mêmes manuellement le code au niveau du framework).
Heureusement, ce travail a déjà été effectué par plusieurs entités (internes et externes à NI) qui proposent leurs architectures de qualité consommateur à la communauté LabVIEW. Deux des architectures LabVIEW les plus utilisées aujourd'hui sont Actor Framework et DQMH.
L’Actor Framework (AF) est une architecture prise en charge par NI et fournie avec LabVIEW. Il s’agit d’une implémentation orientée objet du Gestionnaire des messages dans une file (GMF). Au lieu des cadres de boucle de gestion des messages dans une structure Condition et des fonctions Ajouter un élément à la fin d’une file, les classes de messages fournissent des VI de méthode « Agir » pour exécuter un code spécifique au sein d’un VI Actor Core.
La conception de l’AF basée sur les classes fournit un framework extensible pour l’implémentation d’acteurs enfants qui héritent du comportement des acteurs parents, ce qui n’est pas possible avec l’approche GMF standard basée sur la structure Condition. De plus, toutes les fonctionnalités de base du framework (initialisation, messagerie, réponse aux erreurs, etc.) peuvent être augmentées ou forcées dans un acteur donné en raison de la conception orientée objet du framework.
Consultez le projet suivant, fourni avec LabVIEW, pour en savoir plus sur l’Actor Framework :
Créez votre propre projet basé sur l’Actor Framework dans LabVIEW avec le modèle de projet Actor Framework ; accédez au menu Fichier de LabVIEW >> Créer un projet >> Actor Framework.
Veuillez noter que le succès de l’Actor Framework repose sur une solide connaissance élémentaire de la programmation orientée objet ainsi que sur une formation et une compréhension adéquates du framework lui-même. De nombreuses ressources de formation relatives à l’Actor Framework sont disponibles. Les plus populaires comprennent notamment :
Lorsque vous commencez à utiliser l'architecture Actor Framework dans vos propres applications, vous pouvez interagir avec d'autres utilisateurs dans Actor Framework – NI Community User Group afin de poser des questions et discuter des meilleures pratiques avec d’autres programmeurs.
Le Gestionnaire de messages dans une file d’attente Delacor (DQMH®) utilise un mécanisme semblable au GMF standard pour la communication au sein d’un processus donné (ou « module »), mais la communication entre les modules asynchrones a lieu par l’intermédiaire d’évènements utilisateur. DQMH n’est pas une architecture orientée objet, malgré le fait qu’il utilise des classes LabVIEW pour certains composants mineurs du framework.
DQMH est une architecture tierce développée et maintenue par le consortium DQMH. L’objectif principal de l’équipe de conception initiale de DQMH était de fournir un framework gratuit à la communauté LabVIEW, accessible aux développeurs de niveau CLAD/CLD.
Vous pouvez installer DQMH en utilisant un gestionnaire de paquets VI.
Une fois le paquet DQMH installé, vous pouvez consulter le projet suivant pour en savoir plus :
Une myriade de ressources de formation est disponible pour le DQMH. Lorsque vous commencez à utiliser l'architecture DQMH dans vos propres applications, vous pouvez interagir avec d’autres utilisateurs dans DQMH Consortium Toolkits – NI Community User Group afin de poser des questions et discuter des meilleures pratiques avec d’autres programmeurs.
DQMH® est une marque déposée du DQMH Consortium, LLC.
Les architectures AF et DQMH sont les architectures LabVIEW les plus populaires au monde, mais elles sont loin d’être les seules. D’autres architectures sont disponibles pour la communauté LabVIEW :
