Documents techniques

Code modulaire sous LabVIEW

Utilisation des llb, lvlib, lvclass, lvlibp, dll

• Amaury LAURENT
• Développeur LabVIEW depuis 2014
• Certifications : CLED et CLA
• Responsable projets systèmes embarqués

La modularité sous LabVIEW

• Fondée en 2007 à Gardanne (Bouches du Rhône), une équipe de 15 personnes
• Concepteur de bancs de tests, de caractérisation et de systèmes de mesure :
• Bureaux d’études spécialisés en électrotechnique, électronique et mécanique
• Pôle développement logiciels, avec une expertise LabVIEW.
• NERYS propose une solution flexible de pilotage de moyens d'essais appelée "Vasco"
• Configurable
• Personnalisable sous LabVIEW
• Compatible avec cibles temps réelles NI
• Historisation longue durée
• Scénarios
• Gestion de la calibration, traçabilité

• Depuis mai 2022 : NERYS + MESULOG → NERYS GROUP
• Gardanne (13), Moirans (38), La Rochette (73)
• Compétences logicielles NI :
• NI LabVIEW® (Windows, RT, FPGA)
• NI TestStand
• NI VeriStand
• Partenaire National Instruments
• Développeurs certifiés LabVIEW et TestStand
• Sur le web :
• https://nerysgroup.com/fr/
• https://www.mesulog.fr/
• Nous contacter :
• contact@nerysgroup.com
• web@mesulog.fr

La modularité sous LabVIEW

• Les sources des exemples ainsi que cette présentation sont disponibles sur le site :

https://nerysgroup.com/fr/entreprise/documentation

Pour commencer, un peu de théorie

Demandons à Chat GPT…

user.lib

A r

c

h i

t

e

e t

c

vi.lib

Application

https://lavag.org/topic/2202-how-not-to-code-large-applications/

https://fr.wikipedia.org/wiki/Programmation_modulaire

• Contient simplement une série d'étapes à réaliser
• N'importe quelle procédure peut être appelée n'importe quand (branchements)

Programmation procédurale

• Décompose une grosse application en modules cohérents
• Permet de développer et d’améliorer les modules indépendamment les uns des autres
• Permet de réutiliser les modules dans d'autres applications (capitalisation)

Programmation

modulaire

• Définition des interactions entre des objets logiciels
• Les fonctionnalités de l’application sont réalisées à travers les interactions entre les objets

Programmation orientée objet

Par abus de langage, une application orientée objet pourra être considérée modulaire

• Objectifs:
• Découper l’application en modules fonctionnels (architecture)
• Simplifier les développements en équipe
• Améliorer la planification
• Renforcer la testabilité (tests fonctionnels par modules)
• Capitaliser le savoir-faire en réutilisant les modules
• Les gains sont palpables tant par le client (qualité) que par nous (efficacité)

Dépendances limitées entre les modules

• Pas de globales communes à plusieurs modules

Interfaces explicites

• Utilisation d’accesseurs
• Limite les accès injustifiés à des données

Information publique et privée

• Exposer uniquement les données pertinentes
• Réfléchir aux fonctions de l’API

https://rmdiscala.developpez.com/cours/LesChapitres.html/Cours4/Chap4.3.htm

ChatGPT

• Les modules sont indépendants (voir autonomes)
• Pas de variables globales
• Pas d’appels croisés
• La communication entre modules gagne à être standard
• Sinon : développer des wrappers
• Tous les échanges entre modules passent normalement par le noyau applicatif
• Documenter son module:
• API
• Fonctionnement
• Tester son module

En plat de résistance,

un peu de LabVIEW

Demandons encore à Chat GPT…

LabVIEW offre plusieurs solutions pour diviser son application en modules.

• La llb
• La dll
• La lvlib
• La lvclass

Ces solutions ne sont pas une fin en soi, mais des moyens

techniques de structurer et distribuer des modules

ChatGPT

• Technologie vieillissante
• Une llb est un zip qui contient des VI, CTL, …
• Un fichier sur disque par module
• Pour récupérer un module : copier la llb
• Possibilité de définir un VI Top Level
• Utilisation très similaire aux dossiers virtuels

• DLL : Dynamic Linked Library
• Permet d’intégrer un module logiciel écrit dans n’importe quel langage (y compris LabVIEW)
• Ne distribue pas les sources
• Doit être incluse dans la distribution
• Gestion de version native
• Nécessite de recompiler pour changer de plateforme

La modularité sous LabVIEW

• Comme le lvproj : un fichier xml
• Sur le disque : la lvlib + les sources du module
• Pour récupérer un module : copier tout le dossier (lvlib + sources)
• /!\ éviter de déplacer les fichiers à la main
• Privilégier l’onglet Files de l’explorateur de projet
• Décrit le contenu du module
• Autorisations d’accès (access scope)
• Gestion de version
• Protection par mot de passe
• Documentation
• N’impacte pas le code

• Il s’agit de la distribution d’une lvlib dont les sources ont été supprimées
• 1 seul fichier sur le disque
• Impossible d’accéder aux sources
• Doit être incluse dans la distribution de l’application
• Peut être chargée dynamiquement
• Utiliser le « Replace With… » pour passer rapidement de lvlib à lvlibp

• Extension de la programmation modulaire : la programmation objet (OOP)
• lvclass = lvlib, le format de fichier est identique (XML)
• Avantages/inconvénients équivalents à ceux de la lvlib, mais implique de se conformer aux principes de l’OOP
• Impossible de faire une lvclassp
• Ensemble de données (attribues) et d’actions (méthodes)
• Héritage, dispatch dynamic, encapsulation

Merci Luc pour l’illustration

• Mix de l’OOP avec la lvlibp
• Obligation de respecter une séquence de construction
• Permet de charger dynamiquement un module dans une application

1. Empaqueter l’interface des plugins

2. Appeler l’interface empaquetée

3. Faire hériter les plugins de la classe

4. Empaqueter les modules en

(classe mère) dans une lvlibp

dans l’appli

mère empaquetée

activant l’option « Ne pas inclure les bibliothèques dépendances »

• Permet de dissocier les cycles de vies du noyau et des modules
• Permet de livrer uniquement les modules utilisés

• Le projet principal ne connait pas les modules
• Tout le monde connait la classe abstraite (classe mère dans une lvlibp)
• Aucun couplage entre les modules
• Chargement 100% dynamique à partir des fichiers lvlibp

• LabVIEW génère du code compilé à la volée à partir du code source
• Soit embarqué dans les VI (par défaut)
• Soit dans le cache (separate compile code)
• Le Run-Time Engine exécute le code compilé
• La construction d’un exe ou d’une lvlibp est un processus de génération d’un fichier binaire dans lequel les sources sont supprimées pour distribuer une application ou un module

Aspects à prendre en compte lors du choix de la technologie employée pour le développement modulaire

ChatGPT

• Décrit la hiérarchie entre les composants d’un projet
• Automatise la construction de l’application
• Facilite le passage Debug/Release

https://www.mooregoodideas.com/products/solution-explorer/index.html

En dessert,

une petite synthèse

Ne demandons pas à Chat GPT…

DLL LLB LVLIB LVCLASS LVLIBP Plugins

Multi-langage oui non

Sources accessibles non oui oui oui non

Cross-plateforme non oui oui oui non

Mono fichier oui oui non non oui Simple à intégrer non oui oui oui oui non

Sources protégées oui non oui oui oui

Binaire pour distribution Gestion de version oui non oui oui oui

oui non non non oui

Aucun chat n’a été maltraité pendant la réalisation de cette présentation

N’oubliez pas :

Mettez de l’ambition dans votre ingénierie !

Merci pour votre

attention

Des questions ?

?

La modularité sous LabVIEW