Pratiques exemplaires pour le développement du module de code TestStand

Lors de la création d'un programme de test avec TestStand, les principales fonctionnalités de test sont implémentées dans des modules de code distincts. TestStand utilise des adaptateurs pour appeler ces modules, qui peuvent être développés dans divers environnements de programmation tels que LabVIEW, LabWindows™/CVI™, C#, VB .NET, C/C++ et ActiveX.

Ce document présente les meilleures pratiques à suivre lors du développement de vos modules de code de test, qui seront appelés à partir de votre séquence de test. Il est supposé que vous avez une connaissance de base de TestStand, y compris la création d'une séquence de test simple.

Établir une Stratégie de Développement de Modules de Code

Avant de commencer à développer un système de test, il est important de définir une approche générale pour les aspects suivants :

• Granularité des Modules de Code : Déterminer l'étendue des fonctionnalités de chaque module.
• Structure des Répertoires : Une structure de répertoires bien définie facilite le partage et le déploiement du code.

Granularité des Modules de Code

Lors de la conception d'un système de test, il est crucial de maintenir une granularité cohérente pour les modules de code. La granularité fait référence à l'étendue des fonctionnalités de chaque module dans un système de test. Une séquence de test avec une faible granularité appelle peu de modules, chacun exécutant plusieurs fonctionnalités, tandis qu'une séquence avec une granularité élevée appelle de nombreux modules, chacun ayant une portée plus restreinte.

Il est essentiel de trouver un équilibre entre ces deux extrêmes, car chacun présente ses propres avantages.

Figure 1. Implémentation d’un test simple avec différents niveaux de granularité

Pour assurer une granularité cohérente dans votre système de test, il est essentiel de créer un ensemble de normes pour le développement des modules de code, telles que :

• Initialisation et Arrêt du Matériel : Effectuez ces opérations dans des modules de code distincts pour permettre à TestStand de gérer la durée de vie des sessions matérielles.
• Détermination de la Granularité : Basée sur les exigences de test, créez un pas de test pour chaque exigence. Cela facilite la couverture complète des exigences. Vous pouvez également utiliser NI Requirements Gateway avec TestStand pour lier vos pas de test aux documents d'exigences.
• Structure des Résultats des Tests : Utilisez la structure souhaitée des résultats pour déterminer la portée des pas individuels. Chaque pas créant une entrée de résultat, un mappage un-à-un entre les pas de test et les entrées de résultat facilite l'organisation des résultats avec un minimum de modifications du rapport ou de l'enregistrement de la base de données.

Définition d’une Structure de Répertoires pour les Fichiers de Séquence et les Modules de Code

Lors de la spécification du chemin d’un module de code dans un pas de test, il est préférable d'utiliser des chemins relatifs plutôt qu'absolus pour les raisons suivantes :

• Portabilité : Si vous déplacez le fichier de séquence et ses dépendances, les chemins absolus ne seront plus valides.
• Déploiement : Lors du déploiement sur une machine cible, les chemins absolus ne seront pas valides à moins que les fichiers ne soient installés au même emplacement.

TestStand utilise une liste de répertoires de recherche pour résoudre les chemins relatifs, incluant généralement le répertoire du fichier de séquence actuel, les répertoires spécifiques à TestStand et les répertoires système.
Il est crucial de définir une structure de fichiers avant de commencer le développement. Voici quelques conseils pour établir une stratégie de stockage des fichiers de séquence et des modules de code :

• Modules de Code pour un Seul Fichier de Séquence : Enregistrez les fichiers de module de code dans un sous-répertoire relatif au fichier de séquence pour garantir que le fichier de séquence puisse toujours trouver les modules de code.
• Modules de Code Partagés : Pour les modules partagés entre plusieurs fichiers de séquence, créez un répertoire spécifique pour tous les modules de code partagés et configurez un répertoire de recherche pour cet emplacement. Cela permet à tous les fichiers de séquence de trouver les modules de code en utilisant un chemin relatif.
• Pour les modules de code utilisés par plusieurs fichiers de séquence non liés, il est recommandé de créer un répertoire dédié pour tous les modules de code partagés et de configurer un nouveau répertoire de recherche pointant vers cet emplacement. Ainsi, tous les fichiers de séquence pourront accéder aux modules de code en utilisant un chemin relatif à ce répertoire de recherche. Lors du déploiement, vous pouvez inclure le fichier de configuration des répertoires de recherche, situé dans <TestStand Application Data>CfgSearchDirectories.cfg. Si vous adoptez cette méthode, évitez de déplacer les fichiers de module de code dans le répertoire pour ne pas casser les chemins spécifiés dans les fichiers de séquence.

Figure 2. Organisez votre structure de répertoires de manière à ce que les modules de code soient placés dans un sous-répertoire relatif au fichier de séquence.

Lors du déploiement du code de test avec l'utilitaire de déploiement TestStand, vous pouvez spécifier des destinations précises pour les fichiers de séquence et les modules de code dépendants. Si un chemin relatif existe entre les répertoires de destination, l'utilitaire mettra à jour les chemins dans le fichier de séquence pour pointer vers les nouveaux emplacements. Il est généralement préférable de faire correspondre la structure de répertoires de votre déploiement à celle du système de développement pour assurer une transition fluide.

Choix de l’Emplacement pour Implémenter les Fonctionnalités

Lors de la définition de la portée des modules de code pour votre système de test, il est crucial de déterminer où implémenter chaque fonctionnalité : dans les modules de code ou dans le fichier de séquence. Les sections suivantes peuvent vous aider à choisir l'emplacement le plus approprié pour les fonctionnalités courantes :

• Évaluation des mesures de test par rapport aux limites
• Définition des valeurs de stimulus
• Rapport et journalisation des résultats et des erreurs de test
• Opérations en boucle
• Exécution d’opérations de commutation
• Exécution de calculs et manipulation des données

Évaluation des Limites et des Résultats des Tests
Idéalement, les modules de code devraient se concentrer sur l'obtention des mesures de test, tandis que la séquence de test devrait traiter les résultats bruts. Cette méthode offre plusieurs avantages :

• Gestion Simplifiée des Limites : Les limites de test sont plus faciles à gérer dans le fichier de séquence, en utilisant des outils comme le chargeur de propriétés pour centraliser la gestion des limites de plusieurs pas.
• Inclusion Automatique dans les Résultats : Les limites définies dans la séquence sont automatiquement incluses dans les rapports de test ou les bases de données.
• Mises à Jour Faciles : Les limites peuvent être mises à jour sans modifier les modules de code, réduisant ainsi le besoin de validation, car seule la séquence de test est modifiée.

Pour des mesures simples, le module de code peut renvoyer la valeur brute à la séquence pour traitement. Par exemple, si un pas de test mesure la tension sur une broche spécifique de l'unité sous test (UUT), le module de code doit renvoyer la valeur mesurée, et la séquence de test peut alors déterminer le résultat en utilisant un pas de test de limite numérique.

Figure 3. Évaluer les limites directement dans le pas de test simplifie les modules de code et améliore la qualité de la journalisation des résultats.

Cependant, pour des tests plus complexes, il peut être nécessaire de traiter les résultats bruts dans le module de code. Les données complexes peuvent être converties en une chaîne ou un résultat numérique, qui peut ensuite être évalué dans TestStand. Par exemple, les résultats d'un test de balayage de fréquence peuvent être traités pour obtenir une valeur minimale, que le module de code évalue avant de renvoyer les données de fréquence pour la journalisation, comme indiqué dans l’exemple de test du périphérique mobile ci-dessous :

Figure 4. Pour des données plus complexes, traitez-les dans le module de code afin de générer un résultat numérique ou textuel, puis utilisez un paramètre pour transmettre les données brutes à des fins de journalisation.

Si les données brutes sont volumineuses, leur transmission à TestStand peut affecter les performances. Dans ce cas, envisagez d'enregistrer les données directement dans un fichier TDMS et de créer un lien vers ce fichier dans le rapport de test. Cela permet de référencer les données sans les transmettre à TestStand. Pour plus de détails, consultez la section sur l'inclusion d'hyperliens dans un rapport - Fichier TDMS.

Si un pas de test ne peut pas déterminer le résultat en utilisant les types d’évaluation disponibles, envisagez de créer un nouveau type de pas de test avec des fonctionnalités supplémentaires adaptées au type de test requis. Pour plus d’informations sur la création de types de pas de test personnalisés, consultez l’article sur les meilleures pratiques pour le développement de types de pas de test personnalisés de cette série.

Définition des Stimuli de Test

Pour de nombreux tests, l’UUT ou l’environnement de test doit être dans un état spécifique avant de pouvoir effectuer le test. Par exemple, une tension d’excitation peut être nécessaire pour mesurer la température, ou une chambre chauffée doit être réglée à une température précise. Utilisez des paramètres pour transmettre ces valeurs d’entrée, comme la tension d’excitation ou la température souhaitée. Cette méthode présente des avantages similaires à ceux du retour de données brutes dans les modules de code, comme expliqué précédemment.

Journalisation des Résultats de Test

TestStand offre des fonctionnalités intégrées pour la génération de rapports et l’enregistrement des résultats dans une base de données. Par conséquent, évitez d’implémenter l’enregistrement des données directement dans les modules de code. Assurez-vous plutôt que toutes les données à enregistrer sont transmises en tant que paramètres et utilisez TestStand pour les enregistrer. Certaines données, comme les résultats des tests, les limites et les informations d’erreur, sont automatiquement enregistrées. Pour enregistrer d’autres données, utilisez la fonction de résultats supplémentaires pour inclure des paramètres supplémentaires dans le rapport.

Pour plus d’informations sur l’ajout de résultats au rapport de test, consultez l’exemple "Ajouter des données personnalisées à un rapport" inclus avec TestStand.

Si vous avez des exigences spécifiques pour la journalisation, envisagez de modifier ou de créer un plug-in de traitement des résultats. Cela vous permettra d’utiliser la collection de résultats intégrée de TestStand tout en déterminant comment les résultats sont traités et présentés. Consultez la section sur la création de plug-ins dans le document "Pratiques exemplaires pour le développement et la personnalisation de modèles de processus TestStand" pour plus d’informations.

Opérations en Boucle
Déterminer la meilleure approche pour implémenter des boucles peut être complexe, chaque méthode ayant ses avantages et inconvénients. Voici quelques conseils pour choisir la stratégie la mieux adaptée à votre application :
Boucle Interne dans le Module de Code :

• Améliore les performances, surtout pour les boucles rapides, car chaque appel de module de code ajoute une surcharge de quelques millisecondes. Une boucle interne peut donc accélérer les tests avec de nombreuses itérations.
• Permet des comportements de boucle plus complexes.

Boucle Externe dans le Fichier de Séquence :

• Permet d’afficher et de modifier les paramètres de boucle directement dans le fichier de séquence sans modifier le module de code.
• Facilite l’accès à l’indice de boucle dans le fichier de séquence, utile pour déterminer les routes de commutation ou d’autres comportements changeant selon l’itération.
• Enregistre chaque itération de la boucle séparément, affichant les résultats de chaque itération dans le rapport ou la base de données.

Exécution d’Opérations de Commutation
De nombreux systèmes de test utilisent des commutateurs pour permettre à un seul matériel de tester plusieurs sites. Les commutateurs permettent de contrôler par programme les connexions des broches d’une unité en cours de test (UUT) à du matériel spécifique via des routes prédéfinies.

Implémentation de la Commutation dans les Modules de Code TestStand
Vous pouvez implémenter la commutation dans les modules de code TestStand de plusieurs façons :

• Utilisation des Propriétés de Commutation Intégrées d’un Pas : Nécessite NI Switch Executive.
• Utilisation des Pas du Commutateur TestStand IVI : Disponible uniquement pour TestStand 32 bits.
• Appel Direct des Fonctions du Driver du Commutateur : Implémenté directement dans les modules de code.

Lorsque vous utilisez du matériel NI Switch, NI Switch Executive permet de définir rapidement des itinéraires. Si vous avez accès à NI Switch Executive, l’utilisation des paramètres de pas intégrés pour la commutation est généralement la meilleure approche, offrant plusieurs avantages :

• Séparation des Fonctions de Commutation : La définition des configurations de commutateur au niveau du pas dissocie les fonctions de commutation du code de test, augmentant ainsi la réutilisabilité et réduisant la complexité des modules de code.
• Expressions Dynamiques : De nombreux champs des paramètres de commutation peuvent être spécifiés par une expression, permettant l’utilisation de variables comme RunState.LoopIndex pour indexer les routes ou les noms de groupe de routes.
• Tests Parallèles : Utilisez l’indice d’interface de connexion de test (RunState.TestSockets.MyIndex) dans la chaîne de routage pour utiliser différentes routes de commutation pour chaque interface de connexion de test.
• Durée de Vie de la Connexion : Vous pouvez lier la durée de vie de la connexion au pas, à la séquence, au thread ou à l’exécution.

Figure 5. Utilisez NI Switch Executive pour définir des itinéraires directement dans les paramètres de pas TestStand, en prenant en charge les expressions TestStand pour déterminer dynamiquement l’itinéraire en fonction de l’indice de boucle actuel ou d’autres propriétés.

Exécution de Calculs et Manipulation des Données

Pour éviter de maintenir des modules de code pour des tâches simples, utilisez le langage d’expression de TestStand pour effectuer des calculs de base et manipuler des tableaux unidimensionnels. Les tâches de programmation plus avancées doivent être implémentées dans les modules de code, car les langages de programmation offrent des fonctionnalités plus robustes. Par exemple, la concaténation de tableaux multidimensionnels est plus facile avec les fonctions natives de LabVIEW qu’avec le langage d’expression.

Dans certains cas, les classes natives du framework .NET peuvent être utilisées pour éviter des expressions trop complexes. Par exemple, la classe System.IO.Path permet de manipuler rapidement des chemins sans créer de module de code.

Figure 6. Vous pouvez utiliser un pas .NET pour accéder aux méthodes du framework .NET sans nécessiter de module de code supplémentaire.

Pratiques Exemplaires pour l’Implémentation de Modules de Code

Lors de l’implémentation de modules de code, plusieurs décisions de conception affecteront la plupart des modules que vous créez. Voici quelques conseils pour les concepts suivants :

• Communication des Données de TestStand aux Modules de Code
• Gestion de la Terminaison de Séquence dans les Modules de Code
• Signalement des Erreurs de Module de Code à TestStand
• Gestion de la Vitesse d’Exécution et de l’Utilisation de la Mémoire des Modules de Code

Communication des Données de TestStand aux Modules de Code
Il existe deux méthodes pour accéder aux données TestStand dans un module de code :

• Transfert via les Paramètres du Module de Code
• Accès Direct via l’API TestStand

En général, il est préférable d’utiliser des paramètres pour transmettre les données plutôt que d’accéder directement via l’API TestStand pour les raisons suivantes :

• Risque d’Erreurs Réduit : Les erreurs dans les noms de propriété ou les types de données sont plus faciles à détecter, car les valeurs des paramètres sont définies dans les paramètres de type du pas de test dans TestStand, et non directement dans le module de code.
• Gestion Simplifiée : Les modifications apportées aux propriétés des pas sont spécifiées dans la configuration des paramètres dans TestStand, sans nécessiter de modifications du module de code.
• Réutilisation Facile en Dehors de TestStand : Le module de code ne dépendant pas de l’API TestStand, il peut être utilisé en dehors de TestStand sans modification.

Figure 7. Dans la mesure du possible, utilisez des paramètres pour transmettre les données nécessaires aux modules de code.

Cependant, l’utilisation de l’API pour accéder directement aux propriétés peut être utile lorsque le module de code doit accéder dynamiquement à diverses données en fonction de l’état du pas. Utiliser des paramètres dans ce cas peut entraîner une longue liste de paramètres, dont certains ne sont utilisés que dans certaines conditions.

Si vous utilisez l’API TestStand dans un module de code, transmettez une référence à l’objet SequenceContext (ThisContext) en tant que paramètre. Cet objet donne accès à tous les autres objets TestStand, y compris le moteur TestStand et l’état d’exécution actuel. La référence de contexte de séquence est également nécessaire si vous utilisez le moniteur de terminaison ou les VIs de boîte de dialogue modale.

Figure 8. Utilisez SequenceContext pour accéder à l’API TestStand dans les modules de code, permettant ainsi l'accès programmatique aux données.

Si vous réutilisez des modules de code en dehors de TestStand, gardez à l’esprit que toutes les opérations utilisant l’API TestStand ne seront disponibles que si le module est appelé à partir d’une séquence TestStand. Les données obtenues via l’API ne seront pas accessibles. Vous pouvez définir un autre mécanisme pour obtenir des données de test lorsque le module de code est utilisé en dehors de TestStand, en vérifiant d’abord si la référence de contexte de séquence est nulle. Dans LabVIEW, utilisez la fonction Not A Number/Path/Refnum?, qui renvoie une valeur booléenne.

Figure 9. Utilisez la fonction "Not A Number/Path/Refnum?" pour vérifier la validité de la référence d’objet SequenceContext dans les modules de code utilisés en dehors de TestStand.

Gestion des Ensembles de Données Volumineux dans les Modules de Code
Les modules de code peuvent produire de grandes quantités de données complexes à partir de mesures ou d’analyses. Évitez de stocker ces données dans des variables TestStand, car TestStand crée une copie des données lors de leur stockage, ce qui peut réduire les performances et provoquer des erreurs de mémoire insuffisante. Utilisez les approches suivantes pour gérer des ensembles de données volumineux sans créer de copies inutiles :

• Traitement Interne : Effectuez l’analyse des données dans le même module de code qui les a acquises et renvoyez uniquement les résultats nécessaires à TestStand.
• Transfert de Pointeurs de Données : Pour les modules de code LabVIEW, utilisez les références de valeur de données (RVD).

Gestion de la Terminaison de Séquence dans les Modules de Code
Lorsque l’utilisateur appuie sur le bouton Terminer (Terminate), TestStand arrête l’exécution de la séquence et exécute tous les pas de nettoyage. Cependant, si un module de code est en cours d’exécution, il doit terminer son exécution et retourner le contrôle à TestStand avant que la séquence puisse se terminer. Si le module de code prend plus de quelques secondes à s’exécuter ou attend une condition, comme une entrée utilisateur, il peut sembler à l’utilisateur que la commande Terminer a été ignorée.

Pour résoudre ce problème, vous pouvez utiliser le moniteur de terminaison pour permettre aux modules de code de vérifier et de répondre à l’état de terminaison de l’exécution appelante. Par exemple, dans le test de la carte mère d’ordinateur, le moniteur de terminaison est utilisé dans la boîte de dialogue de simulation. Si la séquence de test est terminée, le VI "Vérifier l’état de terminaison" renvoie Faux et la boucle s’arrête.

Gestion des Erreurs

Une erreur dans un système de test est un comportement d’exécution inattendu qui empêche le test de se dérouler correctement. Lorsqu’un module de code génère une erreur, il est important de transmettre ces informations à la séquence de test pour déterminer l’action à entreprendre, comme terminer l’exécution, répéter le dernier test ou alerter l’opérateur de test.

Pour fournir à TestStand les informations d’erreur des modules de code, utilisez le conteneur Result.Error du pas. TestStand vérifie automatiquement cette propriété après chaque pas pour détecter les erreurs. Si une erreur est renvoyée, l’exécution peut se ramifier vers une autre partie de la séquence, comme le groupe de pas de nettoyage.

Vous pouvez configurer la réponse de TestStand aux erreurs de pas en utilisant le paramètre "Erreur pendant l’exécution" (On Run-Time Error) dans l’onglet Exécution des options de station. En général, utilisez l’option "Afficher la boîte de dialogue" (Show Dialog Box) lors du développement pour faciliter le débogage. Pour les systèmes déployés, envisagez d’utiliser les options "Exécuter le nettoyage" (Run Cleanup) ou "Ignorer" (Ignore) pour éviter de nécessiter une intervention de l’opérateur. Les informations sur l’erreur sont automatiquement enregistrées dans les résultats du test pour aider à diagnostiquer la cause de l’erreur.

Figure 10. Passez les informations d’erreur au conteneur Step.Result.Error pour notifier TestStand en cas d’erreur dans le pas.

Gestion des Performances et de l’Utilisation de la Mémoire des Modules de Code

Par défaut, TestStand charge tous les modules de code d’un fichier de séquence en mémoire lors de l’exécution d’une séquence et les garde chargés jusqu’à la fermeture du fichier. Cela peut entraîner un retard initial lors du démarrage de la séquence, mais les exécutions ultérieures seront plus rapides.
Vous pouvez configurer le moment où un module de code est chargé et déchargé dans l’onglet "Options d’exécution" (Run Options) des paramètres du pas. En général, les options de charge par défaut offrent les meilleures performances, mais dans certains cas, il peut être préférable de charger le module de code uniquement lorsqu’il est nécessaire, en utilisant l’option "Charger de façon dynamique" (Load dynamically). Pour les modules de code rarement utilisés, comme les diagnostics après un échec de test, le chargement dynamique est recommandé.
Notez que TestStand ne signale pas les problèmes des modules de code jusqu’à leur chargement, ce qui peut se produire tard dans une longue exécution. Utilisez l’analyseur de séquence pour vérifier les erreurs avant l’exécution. L’analyseur vérifie les modules de code chargés statiquement et dynamiquement.
Pour les modules de code gourmands en mémoire, modifiez l’option de déchargement par défaut pour réduire l’utilisation de la mémoire, par exemple en définissant le module sur "Décharger après l’exécution du pas" (Unload After Step Executes) ou "Décharger après l’exécution de la séquence" (Unload After Sequence Executes). Cette modification peut augmenter les temps d’exécution, car TestStand devra recharger le module à chaque appel. Une meilleure alternative consiste à utiliser la version 64 bits de TestStand et un système avec plus de mémoire physique pour des performances optimales.

Gestion des Données Partagées dans les Modules de Code
Si vos modules de code utilisent des données partagées, comme des variables statiques ou des variables globales fonctionnelles LabVIEW, la modification des options de déchargement peut entraîner des changements de comportement, car les données globales sont perdues lorsque les modules sont déchargés. Pour éviter la perte de données, assurez-vous que toutes les données nécessaires sont transmises à la séquence TestStand ou stockées dans un emplacement plus permanent.
Pour plus d’informations sur l’optimisation des performances d’un système de test, consultez les pratiques exemplaires pour améliorer les performances du système NI TestStand.

Utilisation de l’Instrumentation dans les Modules de Code

Les modules de code sont souvent utilisés pour interfacer avec le matériel de test afin de configurer des stimuli et de prendre des mesures. Les méthodes de communication avec le matériel incluent :

• Utilisation d’un Driver Matériel : Comme NI-DAQmx, pour communiquer directement avec le matériel.
• Utilisation d’un Driver d’Instruments : Qui envoie des commandes à un instrument via le driver matériel VISA ou IVI.

La méthode de communication dépend du type de matériel utilisé. Dans les deux cas, vous ouvrirez une référence ou une session au driver avant d’effectuer des appels spécifiques et fermerez la session une fois l’interaction terminée.
Choix d’une Approche pour la Gestion des Références Matérielles
Pour éviter les impacts sur les performances dus à l’ouverture et à la fermeture répétées des sessions d’instrument, il est important de bien gérer les références matérielles dans vos séquences de test. Deux approches courantes existent :

• Gestion Manuelle des Références Matérielles : En appelant les fonctions d’initialisation et de fermeture dans vos modules de code.
• Utilisation de Session Manager : Pour gérer automatiquement la durée de vie des références matérielles.

Si vous utilisez un driver d’instruments ou communiquez directement avec des instruments via les drivers VISA ou IVI, utilisez Session Manager, sauf si vous avez besoin de contrôler directement la durée de vie des sessions matérielles. Pour les drivers matériels comme DAQmx, vous devez gérer les références manuellement.

Gestion Manuelle des Références Matérielles avec les Variables TestStand
Lorsque vous initialisez l’instrument, transmettez la référence de session en tant que paramètre de sortie à la séquence d’appel et stockez-la dans une variable. Vous pouvez ensuite utiliser cette variable comme entrée pour chaque pas nécessitant un accès à l’instrument.
De nombreux drivers, comme NI-DAQmx, VISA et la plupart des drivers d’instruments, utilisent le type de données Référence d’E/S pour stocker les références de session. Utilisez le type de données LabviewIOControl dans TestStand pour stocker ces références.

Figure 11. Utilisez une variable de type LabVIEWIOControl pour transmettre des références matérielles, comme une référence de tâche DAQ, entre les modules de code.

Lorsque vous transférez des pointeurs d’instruments entre TestStand et des modules de code, stockez la référence matérielle dans une variable locale. Si le matériel est utilisé dans plusieurs séquences, passez le pointeur en tant que paramètre de séquence à chaque séquence qui en a besoin. Évitez d’utiliser des variables globales pour stocker les références matérielles, car il peut être difficile de s’assurer que l’instrument a été initialisé avant d’utiliser la référence.
Utilisez les groupes de pas de test de configuration pour initialiser le matériel et les groupes de pas de test de nettoyage pour fermer les références matérielles pour les raisons suivantes :

• Les références matérielles seront toujours fermées si l’utilisateur met fin à l’exécution de la séquence, car le groupe de pas de test de nettoyage s’exécute toujours à la fin d’une exécution.
• Vous permet d’exécuter de manière interactive des pas qui utilisent la référence matérielle, car les groupes de pas de test de configuration et de nettoyage s’exécuteront avant et après les pas sélectionnés.

Figure 12. Utilisez les groupes de configuration et de nettoyage (Setup & Cleanup) pour initialiser et fermer les références matérielles.

Gestion Manuelle des Références Matérielles avec Session Manager
Pour les pointeurs d’instruments VISA et IVI, vous pouvez utiliser Session Manager pour gérer automatiquement les références matérielles. Cette méthode présente plusieurs avantages :

• Couplage Réduit : Pas besoin de transmettre des variables de pointeurs d’instrument entre les composants logiciels. Chaque composant spécifie simplement un nom d’instrument logique pour obtenir une session.
• Barrières de Langage Réduites : Les modules de code écrits dans différents langages peuvent partager la même session sans avoir à convertir des pointeurs entre les langages.
• Contrôle de la Durée de Vie : Les sessions d’instruments étant des objets ActiveX avec des références comptées, vous pouvez lier la durée de vie de la session à celle d’une variable de référence ActiveX, éliminant ainsi la nécessité de fermer explicitement l’instrument dans les langages qui prennent en charge les variables de référence ActiveX.

Session Manager initialise automatiquement le pointeur après la création de la session et le ferme lorsque la dernière référence à la session est libérée. Les modules de code et les séquences utilisent un nom logique, comme "DMM1", pour obtenir un objet de session à partir de Session Manager, qui contient le pointeur d’instrument correspondant.
Lorsque vous utilisez Session Manager, stockez l’objet de session dans une variable de référence d’objet TestStand. La durée de vie de la session est ainsi liée à celle de la variable de référence d’objet, garantissant que le pointeur de l’instrument est initialisé et fermé une seule fois par exécution, quel que soit le nombre de modules de code ou de sous-séquences accédant à la même session.
Par exemple, le pas "Obtenir une session DMM" (Get DMM Session) obtient une référence à l’objet de session d’instrument pour le DMM en utilisant le nom logique. La référence de session est stockée dans une variable locale pour que la session reste initialisée pendant toute la durée de l’exécution de la séquence.

Figure 13. Utilisez Session Manager pour référencer des instruments à l’aide d’un nom logique. Le VI de Session Manager obtient la référence DMM IO en utilisant ce nom logique.

Pour plus d’informations sur l’utilisation de Session Manager, consultez l’aide de Session Manager NI, située dans <Program Files>National InstrumentsSharedSession Manager.
Appel des Bibliothèques de Drivers de Matériel
Pour communiquer avec du matériel, vous utilisez des bibliothèques de drivers qui fournissent des fonctionnalités pour effectuer diverses tâches avec un langage de programmation. Lorsque vous utilisez ces bibliothèques, vous appelez souvent plusieurs VIs ou fonctions pour réaliser une seule opération logique, comme prendre une mesure ou configurer un déclencheur. Créer un module de code pour implémenter cette fonctionnalité, plutôt que d’appeler directement les fonctions de bibliothèque depuis un pas TestStand, présente plusieurs avantages :

• Réduction de la Surcharge : Évite la surcharge du système de fonctionnalité de pas autour de chaque fonction
• Abstraction : Fournit une couche d’abstraction entre les appels de drivers et les séquences TestStand.
• Partage de l’Implémentation : Facilite le partage de l’implémentation entre différents programmes de test

Contactez un expert !