Documents techniques

Bonnes pratiques de développeurs Secrets d’architectes

Amaury LAURENT (CLA, CLED) NERYS

Luc DESRUELLE

LabVIEW Champion, CLA, CTD

MESULOG (Director)

Président - MESULOG & Nerys

• Chef de projet Test & Mesure (architecture, déploiement, industrialisation)
• Analyse et valorisation des données mesurées (Prédiction, statistique, IA)
• Cybersécurité et gouvernance des projets numériques (OS DR)
• LabVIEW Architecte & Champion, TestStand Développeur

web@mesulog.fr

“Nous accompagnons les équipes industrielles et R&D dans la conception, la sécurisation et l’optimisation de leurs systèmes de test, en combinant expertise logicielle, analyse des données et intelligence artificielle.”

Responsable systèmes embarqués – NERYS

• Chef de projet Test & Mesure
• Développeur LabVIEW depuis 2014
• Certifié Développeur Systèmes Embarques et Architecte LabVIEW

CONCEPTION BANCS D'ESSAIS ET DE SYSTÈMES DE MESURE

Métrologie, R&D, caractérisation, endurance, Contrôle

CONCEPTION DE BANCS D'ESSAIS

• Banc de test
• Baies de contrôle commande
• Développement cartes électroniques
• Modélisation et conception mécanique
• Systèmes de mesure
• Développement logiciel

LOGICIELS DÉDIÉS AU TEST ET À LA MESURE

• Expert en logiciel test et mesure
• Expert en logiciel de tests automatisés
• NI LabVIEW et TestStand
• Partenaire NI Emerson
• Optimisation, fiabilisation de code
• Architecture projets complexes
• Analyse de données

“Nous accompagnons les équipes industrielles et R&D dans la conception de leurs systèmes de test, en combinant expertise logicielle, sélection de matériels, analyse des données et intelligence artificielle.”

1. Réalisation de système Test & Mesure (complet, en partie ou rénovation) :

• Banc essai (armoire électrotechnique, tiroir, valise d’essai)
• Machine spéciale (BE mécanique, BE électrotechnique et BE logiciel)

2. Développement logiciel

• Personnalisé sous NI LabVIEW & Python : spécialisé test et mesure, analyse données (IA)
• Test automatisé sous NI TestStand
• Système embarqué NI sous LabVIEW RT / FPGA
• VHDL, Visual Basic, C#, .NET, C, C++, Python

3. Editeur de solutions « clé en main »

• Suite Logiciels « Vasco » pour pilotage de banc d’essai - notamment système NI RT/FPGA
• Produits pour le séquenceur NI TestStand

4. Service & Formation Qualiopi

Gérer des projets dans une démarche qualité et cybersécurité (OS DRSF)

Un pôle logiciel qualifié : 13 développeurs expérimentés

Des certifications :

• Certified LabVIEW Architect & Developer
• Certified TestStand Architect & Developer
• Certified LabVIEW Embedded Developer,
• Certified Professional Instructor
• 1 LabVIEW Champion

Des langages de programmation et de développement

• NI LabVIEW (RT, FPGA)
• NI TestStand,
• NI VeriStand
• NI LabVIEW FPGA, VHDL,
• Visual Basic, C#, .NET, C, C++, Python

https://www.mesulog.fr/fr/metiers/realisations

https://www.mesulog.fr/fr/metiers/realisations

Venez nous voir

Pour récupérer votre souvenir NI Days Paris 2026 – 40 de LabVIEW – 50 de NI Pour jouer à notre jeu : Défiez l’IA. Pour échanger autour :

• Des architectures logicielles de mesure autour NI LabVIEW
• Des bancs de test automatisés autour de NI TestStand
• De la cybersécurité des systèmes de test
• De l’intégration concrète de l’IA dans les outils d’ingénierie.
• De l’analyse des données de tests

Dans un contexte de transformation industrielle, nos architectes vous accompagnent également sur :

• Migration W indows 10 → W indows 11
• Mise en conformité Cyber Resilience Act (CRA)
• Modernisation de bancs existants

Merci :

• LabVIEW Debugging Tips and Tricks 2026 par Elijah Kerry, pour les Gifs animés sur les nouveautés LabVIEW et illustration outils NI
• Mes collègues, Mes clients, Les forums d’aide pour la source d’inspiration

C’est un écart entre la réalité « constatée » et :

• ce que le client attend,
• ce que le cahier des charges décrit,
• ce que le développeur pense avoir codé,

Vous avez déjà entendu les anecdotes suivantes - lors des retours clients :

• “Chez moi ça marche.”
• “C’est normal, c’est codé comme ça.”
• “C’est bon j’ai corrigé”

Ces phrases déplacent le problème vers une explication instinctive au lieu de créer une démarche d’analyse méthodique. Elles vont conduire à un correctif, mais pas toujours à la solution

« Mettre au point, ce n’est pas corriger à l’instinct, c’est appliquer une démarche méthodique pour comprendre pourquoi un système ne se comporte pas comme prévu »

Luc DESRUELLE, MESULOG

La démarche : prévenir → observer → analyser → comprendre → corriger → capitaliser.

Sommaire

1. La meilleure mise au point, c’est de l’éviter : coder dans les règles de l’art

2. Quand le bug arrive : Une stratégie pour mener l’enquête

3. Analyser les fichiers traces et journaux : de l’analyse manuelle à l’IA

4. Mettre au point dans LabVIEW 2026 : nouveautés de l’EDI

5. La spécificité des fuites mémoire

6. Aller plus loin avec les outils professionnels NI (logiciel & matériel)

Debugging LabVIEW Applications

Un planning chargé!..... ☺

c’est de l’éviter

Écrire un code source dans les « règles de l’art »

A l’instinct ?

• Sans méthode
• Sans outils
• Sans règle

Evidement non

Comme cette image générée par mon IA préférée

L’absence de méthode est à l’origine des bugs

• Code complexe
• Non documenté
• Non maintenable
• Imprévisible
• Pas de mise au point possible
• Problèmes de performance
• Problème de fuite mémoire
• …

Etapes du développement

Acquisition & Restitution

Acquisition & Restitution

Acquisition & Restitution

• NI Package Manager
• Failles de Sécurités
• CVE
• CWE

Architecture d’application

Spécifications

Développement

Tests et validation

Déploiement et correctifs

• SAST : VI Analyser Toolkit
• DAST : Unit Test Framework
• CI : Intégration continue
• Matrice des exigences
• Requirements Gateway
• Framework (DQMH…)
• Certifiés CLA + CLED
• Les 10 commandements LabVIEW
• LabVIEW Style Checklist
• Techniques de développement
• Livres sur NI LabVIEW de Luc ☺
• Développeurs Certifiés CLD + CLAD
• Sécurité des produits numériques
• CRA : Cyber Resilience Act
• Exigences minimales cybersécurité tout au long du cycle de vie

2 types d’erreurs

La qualité du code source

L’architecture du projet

(la forme)

(le fond)

1. Sur un seul écran ton code tiendra 2. De gauche à droite tu coderas 3. Tes fils tu ne croiseras pas 4. La gestion d’erreurs tu ne transgresseras pas 5. Le connecteur de type 4x2x2x4 toujours tu utiliseras 6. Tes objets judicieusement tu nommeras 7. Le flux de données tu respecteras 8. Ton code tu documenteras 9. Des sous-VI tu feras 10.La lisibilité du code tu garantiras

• Connecteur 4x4 (Par défaut : 4x2x2x4)
• Icône « explicite »
• Documentation Aide Contextuelle Ctrl + H
• Câbler toutes les erreurs
• Dans les boucles = registre à décalage pour mémoriser l’erreur
• Dans une boucle avoir une condition d’arrêt si erreur
• Commentaires développeur – fils droit – Gestion erreur – gauche vers la droite

Inspirées des règles “Power of Ten” de la NASA et de JPL pour les logiciels critiques

Éviter les locales et globales. Attention aux écritures en parallèle.

Définir des temps d’attentes finies et imposer un nombre maximal de tentatives.

Pre-allouer les tableaux et éviter la construction de tableau dans les boucles.

Le code doit être lisible en entier sur un écran.

Rendre les conditions des structures explicites

Limiter les structures de données trop complexes

Gérer toutes les erreurs. Ne jamais penser qu’une erreur

ne peut pas se produire.

Documenter son code Tester son code lors de

Lancer régulièrement le VI

l’écriture, Penser à toutes les possibilités

Analyzer.

Les bases de la gestion d’erreur sous LabVIEW

• Coder les fonctionnalités attendues et protégez-vous des comportements non désirés
• Chaque VI doit avoir - en paramètre d’entrée et de sortie - un cluster d’erreur,
• L’erreur d’entrée doit être câblée sur une structure condition afin de transmettre l’erreur sans la modifier
• Utiliser un registre à décalage dans les boucles pour ne pas perdre l’erreur
• Savoir générer une erreur utilisateur (code erreur > 5000, message, chaîne d’appel et informations de diagnostic)

Ajouter des indices dans votre enquête : personnaliser les messages d’erreur

• En cas d’erreur, penser à ajouter un message utilisateur dans le message d’erreur afin de faciliter la mise au point.
• Ajouter une balise <append> dans la « source » du cluster d’erreur
• En faire un VI facilement utilisable

Exemple avec un fichier qui n’existe pas

Les incontournables à maitriser

DQMH

Framework tiers largement adopté par la communauté

QMH

La base par NI

Modèle nativement proposé par NI dans LabVIEW

• Utilisable pour les certifications
• Documenté
• Grande souplesse d’évolution
• Facile à mettre au point
• Facile à maitriser
• Brique de base pour construire des applications complexes
• Standard approuvé

Gestion d’erreur intégrée

Toutes les erreurs sont envoyées dans l’état « ERROR »

Boite dialogue erreur standard

Boite de dialogue erreur personnalisée

Visualiser les informations dans l’application

Conseil : Ajouter un log d’erreur

Dans un fichier LOG

➔Date de l’erreur ➔Heure de l’erreur ➔Localisation de l’erreur ➔Code de l’erreur ➔Contexte de l’erreur

Conseil pour la mise au point : ajouter un fichier de diagnostic

Suivre des informations sur le logiciel

Dans un fichier Diag

➔Date ➔Heure ➔Message

• Action utilisateur
• Démarrage logiciel
• Arrêt logiciel
• Taskill logiciel
• …

Pas seulement “bien coder”, mais avoir :

• un guide et des règles développeur pour la qualité du code source
• une architecture projet,
• des modes dégradés dans les VIs si erreur
• une gestion d’erreurs systématique (dans source et projet),
• des journaux traces pour le diagnostic « diag »
• des journaux de sauvegarde des erreurs « log »
• des tests unitaires ou scénarios de validation,
• une revue de code,
• ne pas attendre la fin du projet pour générer l’exécutable

mener l’enquête

Mettre au point, ce n’est pas “essayer des trucs”, c’est une méthode d’analyse

Mettre au point, ce n’est pas “essayer des trucs”. C’est une enquête méthodique.

• Ecouter les retours, reformuler, prendre des notes : l’audition des témoins
• Ne pas chercher une conclusion trop rapidement,
• Catégoriser le problème : en [source, exécutable, matériel], [systématique / aléatoire], IHM, crash, erreur de calcul …
• Exploiter les fichiers [traces, log] + indicateurs IHM : pour recueillir les indices et orienter vers les causes possibles
• Isoler le code source qui génère le dysfonctionnement : l’audition du suspect
• Reproduire le problème,
• Formuler des hypothèses, les tester, et garder des preuves de vos tests
• Corriger votre code
• Valider la correction, la déployer
• Documenter

« Quand vous avez éliminé l’impossible, ce qui reste, aussi improbable soit-il, doit être la vérité. »

Sir Arthur Conan Doyle - The Sign of the Four

Garder en mémoire que:

• Même de bonne fois, dans une enquête, 20 % des indices sont faux,
• Un bug est résolu lorsque l’explication trouvée :
• explique tous les faits observés
• explique les faux indices
• Les corrections hâtives sont des rustines : Elles masquent un symptôme sans corriger la cause
• Un message d’erreur peut être une conséquence, pas une cause.
• Si vous fermez les yeux, le dysfonctionnement reviendra un vendredi à 18h00

Analyser les indices, les fichiers traces et journaux

De l’analyse manuelle à l’IA

Collecter et sauvegarder :

1. Depuis votre application

Vos indicateurs dans l’IHM

Vos fichiers d’erreur (fichier log) Vos journaux de diagnostic (fichier diag),

2. Depuis votre OS

Les journaux des évènements

3. Les crashs dumps et journaux : EDI LabVIEW et les autres applications

%userprofile%\Documents\LabVIEW Data\LVInternalReports \NomApplication %localappdata%\National Instruments\ApplicationUtilise\Logs\*.log

Observateur d’événements sous Windows

• NIPB log file: %localappdata%\National Instruments\NI Package Builder\Logs\*.log
• NIPM log file: %localappdata%\National Instruments\NI Package Manager\Logs\NIPkgLogs\*.log
• NIPM error file: %localappdata%\National Instruments\NI Package Manager\Logs\errorlog.txt

« Le programme s’arrête » -> le PC a redémarré suite mise à jour Windows

C’est une équipe : complémentaire - chacun couvre ce que l’autre ne sait pas faire

ANALYSE MANUELLE par humain

ANALYSE AUTOMATIQUE par IA Classique

CE QU' ELLE APPORTE

CE QU' ELLE APPORTE

Connaît le contexte métier : ce que le code doit faire

Analyse en quelques secondes des volumes énormes

Regroupe et corrèle les signaux faibles

Expérience - Expertise : il connait son métier

Remonte à la cause racine, pas au seul symptôme

Traduit un code d'erreur cryptique en clair

SON COÛT

SES LIMITES

Chronophage dès que le volume explose

Peu reproductible dépend du développeur

Pas de notion liée au métier, au matériel NI

Confiante même quand elle se trompe

Analyse de vos indicateurs IHM et fichiers de « votre application » LabVIEW : L'analyse manuelle

• C’est lui qui a fait le code, il connait le contexte métier des fichiers traces
• Lecture du message d’erreur doit orienter vers l’origine et donc la solution
• Vos fichiers d’erreur (fichier log) : nom du VI en erreur + code + raison possible = 95% des résolutions
• Analyse critique avec la possibilité d’ajouter des informations de diagnostic dans le code

Exemple erreur « Package Builder »

• Constat : Impossible de réaliser le Package
• Information :
• error file: %localappdata%\National Instruments\NI Package Builder\Logs
• Fichier log-2026-06-10_09-47-20.txt
• Analyse : fichier erreur par Claude
• Temps attente : 10 secondes
• Proposition : réinstaller NI TestStand
• Verdict : Validé

Exemple crash application LabVIEW

• Constat : crash Vasco.exe
• Information
• %USERPROFILE%\Documents\

Fichier lvlog Fichier dump (dmp)

LabVIEW Data \LVInternalReports\ Vasco\

• Analyse : 2 fichiers par Claude
• Temps attente : 30 secondes
• Proposition : ajouter classe dans build
• Verdict : Validé

Nous interrogeons des instruments, et certaines requêtes ne fonctionnent pas

Les attentes

• Sur requête, l’appareil devrait retourner une liste de commandes valides.
• Les requêtes devraient retourner une valeur.
• Un champ vide n’est pas une réponse valide.

La pratique

• Certaines commandes fonctionnent
• D’autres ne sembles rien faire
• Il n’y a pas d’erreur constatée

• I/O Trace confirme que l’application reçoit bien les commandes de l’appareil.
• I/O Trace montre que certains appels ont pour statut le code 0x3FFF0006.
• Nigel explique une raison possible et indique la localisation dans le code source.
• Nigel recommande de changer la taille du buffer de lecture à 250 octets

Ce que les IA – et notamment Nigel - savent bien faire

• Analyse les fichiers traces, dump
• Expliquer ou générer du code
• Interpréter les erreurs
• Documenter

Ce que l’IA fait mal

• Comprendre votre contexte industriel
• Comprendre le timing réel
• Comprendre l’architecture globale d’un projet complexe et les intéractions

problèmes de code source dans NI LabVIEW

Les méthodes et outils dédiés au code source dans NI LabVIEW

Permet - d’activer / désactiver - les outils de mise au point dans l’EDI NI LabVIEW

Soit chaque VI Soit pour l’ensemble des VIs du projet

Menu : Project > Project Environment Settings et option « Activer débogage pour tous les VIs ».

Pourquoi ?

Vous n’avez pas à gérer des sous-VIs dont l’option de débogage est désactivée et donc d’avoir à recommencer toute votre session de mise au point.

Clic droit sur le VI -> SubVI Node Setup.

Sélectionner “Suspend when called

• La face-avant du VI s’affiche lors de son exécution
• Vous pouvez modifier les valeurs des commandes et des indicateurs de la face-avant
• Avant de cliquer sur le bouton pour poursuivre l’exécution avec les valeurs saisies manuellement
• Utile pour modifier manuellement les données d’un appareil absent ou un système simulé

Activer ‘Retain Values’ depuis la barre d’outils d’un VI :

sert à conserver la dernière valeur entre deux exécutions du VI.

Pour Activer l’option pour toute la hiérarchie des VIs -> maintenir le clic souris sur le bouton menu

Pourquoi ? Cela vous permettra de placer des sonder les câbles

après une exécution dans tous les sous-VIs.

Cela doit être utilisé avec prudence sur tous les VIs allouant une quantité importante de mémoire à l’exécution.

Les sondes et points d’arrêt sont gérés depuis une fenêtre commune

• Permet d’ajouter/supprimer des sondes et des points d’arrêt.
• Les sondes et points d’arrêt sont conservés d’une session à une autre.

Nouvelle fonctionnalité pour exporter des données dans le presse-papier

Les points d’arrêt « mettent en pause » le code LabVIEW jusqu’à ce que le développeur réactive l’exécution

Câble Diagramme

Noeud / sousVI

Exécution détaillée (Ctrl-Flèche bas)

Ouvre un nœud et pause l’exécution du code.

Pause à la prochaine action du sous-VI ou de la structure.

Exécution sans détail (Ctrl-Flèche droite)

Exécute un nœud et pause au prochain nœud.

Quitter (Ctrl-Flèche haut)

Arrête l’exécution du nœud actuel et pause. Lorsque le VI a fini son exécution, le bouton « Quitter » est grisé.

L'animation de l'exécution présente le mouvement des données d'un nœud à un autre sur le diagramme en utilisant des "bulles" qui se déplacent le long des fils de liaison.

• Les sondes et points d’arrêt sont gérés depuis une fenêtre Et la sonde d’erreur conditionnelle qui mets un point d’arrêt en cas d’erreur

Les sondes génériques sont uniquement utilisées pour visualiser les données « sur un fil de donnée », Mais qu’en est-il si nous voulons avoir davantage d’informations ?

Les sondes d’historique peuvent être créées pour des numériques, des chaînes de caractères, des chemins et des booléens.

Amaury LAURENT : « Utiliser la boite d’erreur automatique, c’est comme faire du vélo avec les roulettes »

Luc DESRUELLE : « je l’active pour améliorer ma gestion d’erreur »

Supend/Stop l’execution du code source sur les erreurs qui ne sont pas câblées

Pourquoi certains veulent désactiver cette fonctionnalité

• Eviter les interruptions par l’environnement de développement LabVIEW. Sur erreur non câblées, avec cette option, l’EDI LabVIEW interrompt toutes les exécutions de code source, en complet
• Dans les versions antérieures, cette fonctionnalité est disponible uniquement en source donc dans l’IDE, Pas dans les exécutables.

• Pour activer cette fonctionnalité dans un EXE ou PPL, vous devez inscrire cette clé dans le fichier .ini :

LogUnwiredErrors=True

La programmation graphique offre plusieurs atouts :

1. Les données ont un typage strict et un code couleur associé. 2. Le flux de données rend l’ordre d’exécution explicite. 3. Toutes les fonctions (sous-VIs) ont une interface utilisateur. 4. Des sondes peuvent être ajoutées sans modification du code source. 5. L’accès concurrent est clairement visible dans le code. 6. La gestion des erreurs est explicitement visible 7. La compilation du code source est automatique et constante. (flèche brisée si impossible) 8. L’environnement de développement (EDI) NI LabVIEW a de nombreuses fonctions de mise au point 9. Il existe de nombreux outils - professionnels NI et autres - pour aider à la mise au point

Memory Leaks

La spécificité des fuites mémoire

Symptômes de l’hôte

1. Les applications crashent après un long temps d’exécution ou de nombreuses itérations.

2. Ralentissement progressif ou instabilité.

3. Mémoire insuffisante ou crashs.

4. Les processus doivent être « tués » pour récupérer de l’espace mémoire.

5. La mémoire augmente régulièrement au fil du temps dans le gestionnaire des tâches.

Les causes les plus courantes d’une fuite mémoire sont :

1. L’utilisation d’un « Build Array » dans une boucle Tant que : enregistrer des données sans limite définie.

2. La concaténation de chaînes de caractères : construction d’une chaîne « infinie », sans jamais la limiter.

3. FIFO Queue, une file d’attente utilisée avec un buffer infini : producteur plus rapide que le consommateur → la file s’allonge...

jusqu’à la fin de vos jours.

4. Structures de variants basées sur des DVR qui ne libèrent jamais leurs données.

5. Graphique (Chart) en face-avant avec un historique de données volumineux lors d’une acquisition continue.

6. Références ouvertes en boucle et non fermées

Gestionnaire des tâches

Indispensable outil de votre OS pour supervision des ressources système

VI profiler - Profil Performance et Mémoire

Identifier les VIs les plus sollicités et mesurer temps d’exécution + mémoire

Afficher la visualisation des buffers

Voir où le compilateur alloue de la mémoire

DETT

Analyser et surveiller dynamiquement l’exécution du code

RT Utilities Palette

VIs pour monitorer la mémoire, CPU et le jitter (variations de latence)

Resource Monitor

Exemple fourni pour lire les informations CPU et mémoire sur systèmes distants

aider

Les outils NI pour la qualité logicielle

VI Analyser

Analyse statique du code source Analyse la qualité du code Possibilité d’ajouter des tests

Desktop Execution Trace Toolkit

Analyse dynamique, en RunTime

Solutions logicielles pour évaluer les performances et la connectivité du matériel

NI MAX

Measurement & Automation eXplorer L’outil de base Vérifie l’identité des appareils, des connections et l’état du pilote.

Exemples NI LabVIEW

Exécuter un code de référence fonctionnel pour valider l'interaction du pilote avec le matériel.

FlexLogger

Se connecte directement au matériel NI-DAQ pour visualiser les données en direct.

IO Trace

Permets de voir exactement les appels/commandes envoyés et leur date d’envoi.

Instrument Studio

Interagit directement avec le matériel NI-PXI pour voir les données en direct et injecter des signaux bruts.

problèmes de code source

Exemples d’utilisation des outils NI pour la qualité logicielle

VI Analyser

Analyse statique du code source Analyse la qualité du code Possibilité d’ajouter des tests

Desktop Execution Trace Toolkit

Analyse dynamique, en RunTime

• Inspecter le code, de façon interactive ou automatisée, pour identifier les causes des problèmes courants grâce à plus de 90 tests standardisés.
• Pratique pour des revues de code interactives et l’analyse de la qualité d’un code.
• Tests configurables pour des problèmes impactant la performance, mémoire, lisibilité etc...
• Possibilité de créer des tests pour appliquer des règles et directives spécifiques.
• API programmable pour une utilisation dans le cadre des processus d’intégration continu.

Vérifier la qualité de votre code : VI Analyser Toolkit – SAST

Le LabVIEW Desktop Execution Trace Toolkit (DETT) s'avère particulièrement utile lorsqu'une analyse approfondie du comportement d'exécution est nécessaire, notamment pour le débogage de code complexe, événementiel ou multithread. Scenario: Role of DETT:

Erreurs difficiles à reproduire

Enregistrer des données au fil du temps, cela aidera à détecter les problèmes qui n’apparaissent pas à chaque exécution. Repérer la création and destruction des références, vous pouvez ainsi repérer les fuites dans les files d’attente, notificateurs, ou évènements utilisateur. Afficher les évènements, changement de threads, et appels bloquants, vous aidera à repérer les ralentissements. Visualiser les messages et leur synchronisation, rendra plus simple le débogage d’architecture producteur/consommateur ou QMH. Se connecter aux exécutables avec VI Server activé, vous permettra de déboguer du code déployé. Enregistrement de données lorsque les VIs sont chargés, appelés, et déchargés, ce qui est essentiel dans des architectures basées sur des plugins. Révéler les impasses, boucles infinies, ou erreurs non gérées en récupérant la séquence d’évènements avant le crash.

Fuites mémoire or fuites de référence

Pertes de performance inattendue

Messagerie complexe

Déboguer des applications (.exe)

Suivre des appels dynamiques de VI

Diagnostiquer des crashs/blocages

• Isoler l’impact des modifications du code sur le comportement de l’application
• Charger des traces enregistrées avec des filtres personnalisés
• Définir des plages d’indices de trace pour cibler le débogage.

Outils NI pour isoler des problèmes matériels

Exemples d’utilisation des outils NI pour la qualité matériels

Solutions logicielles pour évaluer les performances et la connectivité du matériel

NI MAX

Measurement & Automation eXplorer L’outil de base Vérifie l’identité des appareils, des connections et l’état du pilote.

Exemples NI LabVIEW

Exécuter un code de référence fonctionnel pour valider l'interaction du pilote avec le matériel.

FlexLogger

Se connecte directement au matériel NI-DAQ pour visualiser les données en direct.

IO Trace

Permets de voir exactement les appels/commandes envoyés et leur date d’envoi.

Instrument Studio

Interagit directement avec le matériel NI-PXI pour voir les données en direct et injecter des signaux bruts.

Permet de : 1) Configurer les voix d’acquisitions 2) Configurer et test l’acquisition 3) Lire la documentation du câblage 4) Créer un code clés en main

Permet de réaliser des acquisitions, des enregistrements, des alarmes, et de visualiser les données

Mutualisation des sessions avec InstrumentStudio

1. Mettre en pause votre VI (point d’arrêt ou arrêt

explicite) avant d’utiliser InstrumentStudio pour déboguer une session en direct.

2. Si vous cliquez sur CONTROL pendant que le VI est

en cours d’exécution, LabVIEW reprendra automatiquement la session.

3. InstrumentStudio exécute une session en priorité

basse — LabVIEW et TestStand prennent automatiquement la priorité.

4. CONTROL force InstrumentStudio à prendre le

contrôle, mais toute activité de session externe (appels de pilote LabVIEW/TestStand) reprendra le contrôle sauf si le VI est arrêté.

NI InstrumentStudio

Logiciel de surveillance et de débogage

• Accélère la mise au point des périphériques et des systèmes
• Identifie les problèmes matériels pendant l’exécution des programmes de test
• Contrôle interactif pour tester des hypothèses

Conclusion

Fin de l’enquête ! Merci