Cette ancienne limitation génère, encore, régulièrement des erreurs dans les applications. Ce type d'erreur est parfois difficile à identifié, car peut de développeur vont tester la validité des chemins qu'ils utilisent dans leurs programmes. A titre personnel, je recommande toujours d'utiliser une fonction qui teste la validité des chemins, en recherchant les caractères "exotiques non supportés", et la longueur des chemins.

je viens de lire une très bonne aide dans le manuel Python, et je la partage 

source https://docs.python.org/fr/3/using/windows.html#using-on-windows

Historiquement les chemins sous Windows étaient limités 260 caractères. Cela impliquait que les chemins plus longs n'étaient pas résolus, et seraient une cause d'erreurs.

Dans les dernières versions de Windows, cette limitation peut être étendue à approximativement 32.000 caractères. Votre administrateur devra activer la stratégie de groupe « Enable Win32 long paths » ou mettre la valeur de LongPathsEnabled à 1 dans de registre à HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem.

Ceci permet à la fonction open(), au module os et à la plupart des autres fonctionnalités utilisant des chemins d'accepter et de renvoyer des chemins plus longs que 260 caractères.

Un code LabVIEW, réalisé par un ami, qui va permettre de récupérer des données sur un service Windows via un constructeur .NET (system.serviceprocess.servicecontroller) pour connaître son statut.

La classe servicecontroller de system.serviceprocess représente un service Windows et vous permet de vous connecter à un service en cours d'exécution ou arrêté, de le manipuler ou d'obtenir des informations le concernant.

La méthode GetServices récupère les services de pilotes autres que de périphériques sur un ordinateur et ceux qui ne sont pas des pilotes.

Le retour est ServiceController[] qui est un tableau de type ServiceController, dans lequel chaque élément est associé à un service sur l'ordinateur spécifié.

Dans l'exemple LabVIEW, le service à gérer est W32Time.

A+

VI Server entre 2 exécutables LabVIEW ou Get Access To A Running Executable From  Executable 

Comment piloter "simplement' une application LabVIEW, depuis une autre application LabVIEW? éventuellement depuis le réseau, entre 2 ordinateurs? et aussi simplement que si le code était dans une seule application?

L’idée est de piloter des fonctionnalités du VI Server contenues dans un exécutable depuis un autre exécutable. Sous LabVIEW il est possible de faire communiquer « facilement » deux exécutables en utilisant le VI Server en accès distant, ou remote.

Avant de commencer, un retour sur la définition du VI Server (source site de NI) : VI Server is a set of functions that allows you to dynamically control front panel objects, VIs, and the LabVIEW environment. With VI Server, you can also programmatically load and run VIs in LabVIEW either on the same machine or across a network. 
VI Server has an object-oriented architecture that is platform-independent.  Each object that is a part of VI Server is a part of a class. The class that the object is a part of determines what properties and methods are available. Many of these classes have sub-classes. For instance, any boolean control is a member of the Boolean class, which is a member of the Control class. The Control class is a member of the GObject class, which is a member of the Generic class. Lower level classes, such as the Boolean class, have their own properties and methods, and inherit properties and methods from higher level classes, such as the Generic class.

Exemple d'un code pour piloter une application "RemoteHMI.exe"

Dans l’exécutable à piloter "RemoteHMI.exe", il faut activer le serveur TCP et le port de communication (par exemple le 11112), via le fichier ini de l’applicatif dans la section du RunTime LabVIEW

[RemoteHMI]
server.tcp.enabled=True
server.tcp.port=11112

évidement la section qui transmet les informations au RunTime LabVIEW doit contenir [NomDeMonApplication] pour NomDeMonApplication.exe

Il est également possible d'activer le serveur TCP par programmation, même si je n'aime pas trop cette méthode. L'exemple suivant, sur le site de NI, permet d'activer le port d'écoute en 3365, activer le serveur TCP et autoriser l'accès en localhost uniquement.

cette méthode est décrite sur le site de NI à l'URL Get Access To A Running Executable From Another VI or Executable Through VI Server 

Cela permet d’avoir accès à toutes les fonctions du VI server à distance, comme si nous étions dans le même exécutable

Cette fonctionnalité est très utile pour piloter un système depuis un autre exécutable, et ainsi séparer la partie commande de la partie pilotage.

cette fonctionnalité me permet de piloter une application développée sous NI LabVIEW à partir de codes modules sous NI TestStand, et ainsi automatiser une séquence de test.

exemple d'un code Remote.vi

exemple d'un code Client

Le code source est disponible dans le post. Vous pouvez me contacter pour vous aider à mettre en place une solution de plugin ou d'abstraction (type HAL). Bonne lecture et A bientôt.

C’est tout un programme, qui me vient en tête, à la suite de plusieurs discussions sur les méthodes de chargement d’un code « externe » à une application et sur les plugins.

Le but n’est pas de décrire en détail l’ensemble des techniques, mais d’évoquer les différentes possibilités.

Dans une application « classique », le code de niveau principal (Main.vi) a des sous-VI qui sont des dépendances appelées statiquement. Lors de la création de la spécification de construction, il suffit de sélectionner le code source de niveau principal, pour que l’ensemble des dépendances soient ajoutées dans le fichier binaire de l’exécutable.

Pour « charger du code externe », il existe plusieurs méthodes (comme toujours). De la plus simple, à la plus complexe, toutes avec des avantages et des inconvénients, évidement, comme toujours.

Il est possible d’envisager :

Chargement d’un code dynamique

Le chargement d’un code dynamique, qui n’est donc pas une dépendance statique du VI Main (Top-level), et qui sera inclus dans la spécification de construction de l’exécutable. Par cette méthode, le sous-VI sera directement « visible / utilisable » par le code principal. Il suffit de le charger en mémoire pour l’utiliser.

Cette technique est simple, et elle permet de charger un code « sur besoin », « sur demande ». Si le code ne peut pas s’exécuter sur la machine, il y aura une erreur lors du chargement. Cette technique est assez limitée car elle ne permet pas de modifier le code externe sans regénérer l’exécutable. Le but est de limiter un temps de chargement, de limiter les « impacts » d’une partie de code qui n’est pas forcement utilisée.

Plugin

Un plugin est un outil qui permet d’ajouter des fonctions supplémentaires à un logiciel principal. Il est qualifié aussi de module d’extension ou add-on (voir définition sur internet).

Code dynamique .VI

Avec LabVIEW, une évolution simple de la première méthode décrite est d’avoir le chargement d’un code dynamique dont le code source « .VI » est externe à l’application. Le code n’est ainsi pas dans la spécification de construction de l’exécutable, le code dynamique n’est donc pas ajouté dans le fichier binaire de l’exécutable. Le code source est donc « à côté » de l’exécutable. Cette technique permet d’avoir un noyau qui est l’exécutable et qui va utiliser un plugin ou un code qui est modifiable. L’avantage est que le « noyau » est indépendant des évolutions de code des plugins. L’inconvénient de cette technique est de partager directement le fichier du code source (le fichier du .VI). Donc cette technique ne permet pas de protéger le code, qui est directement modifiable (cybersécurité) ou peut être récupéré (protection intellectuelle). Cela n’est pas forcement un problème dans un laboratoire qui veut charger le driver de communication avec un multimètre. Mais cette technique peut être un problème sur un plugin d’intelligence artificiel (AI) qu’une industrie désire actualiser régulièrement, mais en conservant « le secret de développement ».

OOP en couche d’abstraction (Abstration Layer OOP)

Une techniquement similaire en programmation Objet (OOP) va permettre de développer une « couche d’abstraction » (Abstraction Layer) avec le chargement / remplacement d’un code via une classe fille en dynamic dispatch.

Cette technique est « classique » en programmation objet.

Une première solution consiste à charger toutes les classes dans le fichier binaire de l’exécutable. J'ai illustré cette technique dans un exemple qui permet de piloter 1 carte d'acquisition mais avec 2 drivers différents.

Dans cet exemple, il y a :

• Une class Deformation avec 2 enfants ConditionneurExterne et CarteSpecifique
• 1 méthode configuration, avec dans chaque class enfant une méthode en dynamic dispatch pour la fenêtre de configuration spécifique, qui sera donc appelée lors de la définition de l’objet de la carte utilisée
• Idem pour les méthodes acquisition, méthode acquisition en dynamic dispatch
• Les données spécifiques à une carte sont donc dans la donnée privée de la class de l’enfant.

Le post de cet exemple est disponible ici : exemple de code OOP HAL avec LabVIEW

Le projet UML est le suivant

Le projet LabVIEW contient toutes les classes (mère et enfants)

Une deuxième approche « plugin » est de charger les classes filles avec un code source (lvclass) « en dehors » de l’exécutable. Il faut passer le chemin de la classe pour la charger.

Avec cette technique l’avantage est de pouvoir réellement définir une abstraction, dans laquelle l’applicatif définit une couche intermédiaire via des méthodes (la classe mère) qui seront redéfinies lors du chargement de la classe fille sélectionnée et chargée dynamiquement.

Exemple de code objet pour avoir une abstraction, avec les classes filles intégrées dans le fichier binaire de l’exécutable.

Zoom sur la couche d'abstraction matérielle abrégé HAL pour hardware abstraction layer avec LabVIEW

En  développement informatique, une couche d'abstraction matérielle (abrégé HAL pour hardware abstraction layer) est un  couche intermédiaire entre le logiciel applicatif et le matériel . Cette couche offre des fonctions standardisées de manipulation du matériel tout en cachant les détails techniques de la mise en œuvre. C'est une fonctionnalité importante des systèmes qui utilisent différents types de matériel car en cas d’évolution seule la couche d'abstraction matérielle nécessite adaptation. (source Wikipedia).

En développement informatique avec LabVIEW, la couche d’abstraction matérielle est réalisée en programmation Objet. La classe mère, directement appelée par l’application principale, va être l’interface de programmation qui fournit des fonctions génériques (les méthodes de la classe mère). La classe fille, dans un dossier « en dehors de l’exécutable, va être chargée dynamiquement en fonction du matériel et va redéfinir les méthodes génériques pour être spécifique au matériel utilisé.

VI Server entre 2 exécutables LabVIEW

Cette fonctionnalité est une petite parenthèse dans les méthodes pour appeler du code externe à un exécutable. L’idée est de déclencher du code d’un exécutable depuis un autre exécutable.

Sous LabVIEW il est possible de faire communiquer « facilement » deux exécutables en utilisant le VI Server en accès distant, ou remote.

Dans l’exécutable à piloter "RemoteHMI.exe", il faut activer le serveur TCP et le port de communication (par exemple le 11112), via le fichier ini de l’applicatif dans la section du RunTime LabVIEW

[RemoteHMI]
server.tcp.enabled=True
server.tcp.port=11112

Cela permet d’avoir accès à toutes les fonctions du VI server à distance, comme si nous étions dans le même exécutable

Cette fonctionnalité est très utile pour piloter un système depuis un autre exécutable, et ainsi séparer la partie commande de la partie pilotage.

Plugins via des classes dans PPL (OOP + lvlibp)

Les méthodes de chargement de code source directement accessible présentent 2 problèmes : la sécurité de garantir que le code ne sera pas modifié et la propriété intellectuelle de ne pas vouloir qu’une personne analyse le code.

Pour résoudre les problématiques, l’idée est de charger le code depuis une bibliothèque protégée. Sous LabVIEW nous utilisons des « lvlibp », ou terme PPL pour l’anglais (Packed Project Libraries d’extension lvlibp).

En français des bibliothèques de projet empaquetées : Les bibliothèques de projet empaquetées LabVIEW sont des bibliothèques de projet  qui regroupent plusieurs fichiers en un seul fichier ayant l'extension .lvlibp. Lorsque vous ouvrez une bibliothèque empaquetée, vous ne voyez que les VIs LabVIEW exportés, donc le code en accès public et pas le code protégé.

Bibliothèques de projet empaquetées sous Windows

Lorsque vous utilisez cette technique de plugin depuis des classes filles en dynamic dispatch, votre exécutable doit contenir la classe mère (Objet) qui va décrire les méthodes utilisables. Elle porte également le nom d’interface.

1) création de la lvlib contenant la classe mère interface (lvclass), puis générer la lvlibp

2) Les classes filles seront séparément réalisées en programmation objet (.lvclass) et seront distribuées dans des PPLs, ou bibliothèques de projet empaquetées ou .lvlibp. Afin de permettre l’appel des classes filles, depuis les lvlibp par la classe mère dans l’exécutable, il est indispensable de générer la classe mère ou interface dans une lvlibp, et de l’inclure dans les bibliothèques de projet empaquetées (PPLs ou lvlibp) des classes filles.

3) Code de l'application principale

Le code va utiliser la lvlipb de la classe mère ou interface (la même qu'utilisée dans les classes enfants)

Il faut charger les "plugins" ou classes enfants. Les classes sont dans des lvlibp. Il faut utiliser le code 

  qualified name specifies the qualified name of the exported file in the packed library. 

Un exemple de code suivant permet de charger les plugins, en chargeant une classe enfant dans une lvlibp

Il faut typer la classe ainsi chargée dynamiquement dans la classe spécifique.

Un exemple de code de plugin par un

Exemple de mesure de déformation via une couche HAL avec un projet plugin utilisant des PPLs

En utilisant la programmation objet, avec les classes dans des PPLs, et en chargeant dynamiquement le code via des Plugins, nous obtenons une couche d'abstraction. 

Voici un exemple de mesure de déformation à partir de 2 types de carte qui ne sont pas compatibles. Le but est d'avoir une abstraction matérielle (abrégé HAL pour hardware abstraction layer) afin de séparer le code du programme (le noyau) du driver des cartes d'acquisition.

La couche HAL est un  couche intermédiaire entre le logiciel applicatif et le matériel . Cette couche offre des fonctions standardisées de manipulation du matériel tout en cachant les détails techniques de la mise en œuvre. 

Architecture projet plugin avec PPLs pour présenter une couche HAL

Le code source est disponible dans le post. Vous pouvez me contacter pour vous aider à mettre en place une solution de plugin ou d'abstraction (type HAL).

Bonne lecture et A bientôt.

Luc

Je me permets de commenter la nouvelle de la fin de la version LabVIEW NXG, et donner mon avis sur le sujet. La fin de la version LabVIEW NXG ne signifie pas la fin de la version LabVIEW (standard), au contraire. NI a annoncé le 3 décembre 2020 la fin de la version LabVIEW NXG mais l'intégration des évolutions dans la version LabVIEW (standard ou CG) : We will integrate the strengths of the NXG platform into our LabVIEW 2021(+) codebase, which will result in the best of both worlds. 

https://forums.ni.com/t5/LabVIEW/Our-Commitment-to-LabVIEW-as-we-Expand-our-Software-Portfolio/m-p/4...

NI a eu une décision à prendre. Et NI a (surement) fait le bon choix. La décision est (majoritairement) applaudie. Elle clarifie une position, et elle donne de la visibilité. Je pense que c’est une bonne décision pour les développeurs LabVIEW. L’objectif de la version LabVIEW NXG était de remplacer la version LabVIEW (dite CG), d’ici quelques années. La finalité était de faire une nouvelle version qui corrige les problèmes originels de la version standard. Le but était de pouvoir faire évoluer plus facilement l'environnement de développement (EDI). Faciliter la pérennité de LabVIEW. Mais la communauté des développeurs n’a pas adhéré à la version NXG.

Beaucoup de raisons à cette non « adhésion ».

1. Le remplacement d’un outil qui fonctionne est une opération très hypothétique.

2. Les utilisateurs aiment (beaucoup trop) LabVIEW Standard.

3. Les utilisateurs n’ont pas reconnu leur LabVIEW.

4. Les dernières versions de LabVIEW Standard sont très biens (2020 est très stables + nouvelles fonctionnalités)

5. LabVIEW NXG apportait aux développeurs plus de problèmes que de solutions

6. LabVIEW NXG n’avait pas les outils professionnels indispensables d’analyse de code, de test unitaire, etc.… Les professionnels ne pouvaient pas l’utiliser sans ces outils.

Il y a quand même de très bonnes fonctionnalités qui ne sont que dans la version NXG : la possibilité de faire des applications Web à partir du code G (WebVI), l’Unicode, system designer, la capture et sauvegarde des données des sondes dans le projet, une navigation par panneau avec moins de fenêtre en cascade, le zoom (pas sûr !),etc.. plus d'exemples sur les fonctionnalités intéressantes de NXG

NI a acté que la communauté des développeurs n’adhérait pas à la version NXG, en tant que replaçant de la version connue. Les équipes de développement de LabVIEW (standard = CG) ont solutionné les problèmes de l’environnement. Les problèmes de maintenance et de risque sur la pérennité ont été levé.

NI a donc décidé

1. De rapatrier les bonnes fonctionnalités de la version NXG dans la version standard, à partir de la version LabVIEW 2021.

2. Les WebVI sont pérennisés, et continueront d’être améliorés. Cette technologie est plébiscité.

3. LabVIEW 2021 va apporter de véritables et nouvelles fonctionnalités

4. NXG ne sera plus le remplaçant de l’environnement de développement (EDI) de LabVIEW,

5. NXG sera une plate-forme d’outils (NXG-Based Portfolio of Software) pour FlexLogger, Instrument Studio, VeriStand, Digital Pattern Editor.

Cela était déjà ressenti par les membres de la communauté, depuis quelques temps. NI va pouvoir se concentrer sur l’amélioration de LabVIEW. C’est une bonne nouvelle, je pense.

Le choix qui a été fait est le meilleur. Il y a beaucoup de bonnes idées dans NXG, qu’il faut ramener dans la version standard. La version LabVIEW 2021 saura apporter de nouveau l’enthousiasme aux développeurs ! Conserver le toolkit Web et l’améliorer est une très bonne nouvelle, car les défis du développeur de demain sont de faire des applications « classiques » liées à des applications Web.

LabVIEW NXG est mort, et vive LabVIEW!

That’s why we’ve decided to take the following steps: We will integrate the strengths of the NXG platform into our LabVIEW 2021(+) codebase, which will result in the best of both worlds. This means centralizing our investments in LabVIEW in a way that enables us to deliver even more value to LabVIEW users in the years ahead. We will continue to advance our NXG-based portfolio of solutions such as the NXG Web Module, SystemDesigner, as well as our expanding suite of configuration-based products such as FlexLogger and VeriStand. As part of this commitment, you can expect to see the NXG Web Module and SystemDesigner integrated into other parts of our portfolio. We will cease development efforts on LabVIEW NXG and release the final version - LabVIEW NXG 5.1 – in 2021. We will not release new versions of LabVIEW NXG starting in 2022.

A suivre...

 Rhône-Alpes

Disponible depuis LabVIEW NXG, l'utilisation du module LabVIEW NXG Web Module permet de réaliser des applications Web à partir des WebVIs. Nous allons vous présenter comment connecter une application développée sous LabVIEW (CG = Current Generation), via des WebServices, à une application Web développée avec LabVIEW NXG via les WebVIs.

Cet article est détaillé dans le Chapitre 7 du livre 
"LabVIEW programmation et application - Introduction à LabVIEW NXG" - 4ème édition
parution le 22/08/2018, aux éditions DUNOD - 560 pages - EAN13 : 978-210078283 Lien livre LabVIEW sur le site Amazon. Description détaillée du livre ici

C’est surement une des fonctionnalités les plus attendues de LabVIEW NXG : Avec la généralisation des tablettes et smartphones, les développeurs réclament la possibilité d’utiliser leur logiciel au travers d’une interface Web. Mais toujours dans l’esprit de LabVIEW donc sans faire de code textuel. LabVIEW doit permettre de créer facilement des applications Web en s’appuyant sur des technologies standards.

Depuis la version 2.0, NXG répond à cette demande. L’éditeur permet de placer des objets HTML5 et de générer le code. Il est possible de modifier le code source HTML, soit pour ajouter des fonctionnalités avec du code JavaScript, soit pour personnaliser l'apparence des contrôles en utilisant une feuille de style CSS (Cascading Style Sheets). Vous pouvez modifier des propriétés telles que la police, la couleur, la forme ou la disposition d'un contrôle.

Dans la version standard de LabVIEW, il existe déjà une fonctionnalité permettant de se connecter à la face-avant d’un VI depuis une interface web. Mais cette fonctionnalité nécessite d’installer le RunTime LabVIEW, qui ne supporte pas toutes les plates-formes, et d’activer un plugin Web qui n’est compatible qu’avec certains navigateurs internet. Avec NXG finit les limitations. Les WebVIs peuvent être déployés sur toutes les plateformes, sur n'importe quel navigateur et sans plug-ins.

Application Web avec les WebVIs de LabVIEW NXG

Dans cette présentation, je vous propose de

• développer une application LabVIEW qui réalise des mesures (classique comme applicatif), mais :
• qui publie les données en JSON via des WebServices : programme accessible au travers du protocole HTTP qui permet l’échange de données par des messages

   

• développer une application web (Web App) avec LabVIEW NXG

Le module Web de LabVIEW NXG, permet de réaliser une application web standard, conforme aux technologies Web, par exemple :

1. HTML: permet d’afficher un document à travers un navigateur web
2. CSS: feuille de style, modifier la mise en forme du document
3. Javascript: ajout contenu dynamique, intégrer du code dans le document HTML pour l’exécuter sur la machine client

Présentation disponible sur le site MESULOG : Journée rencontres LUGE 2019.2 : Application Web LabVIEW CG et NXG Web Module

L'utilisation du module est décrit en détail dans le livre "LabVIEW Programmation et applications - Introduction à LabVIEW NXG"  – 4iéme édition parution 2018 aux éditions DUNOD.

Retour rapide sur cette très belle journée du jeudi 13 juin 2019, pour le LUGE 2019.2 (la 2iéme de l'année 2019) : le User Group des développeurs LabVIEW / TestStand en Rhône-Alpes. 

La journée a encore été une très belle réussite. Le contenu technique des présentations a été très riche :

• LabVIEW NXG, et les WebVI,
• Application Web développées en textuelle VS avec LabVIEW NXG,
• Web Services sous LabVIEW CG et NXG
• Modbus série/TCP
• outils internes,
• NI Package Manager (NIPM)

Sponsorisé par National Instruments France, et accueilli par Saphir, cet évènement a regroupé une trentaine de développeurs. L’échange de retour d’expérience a été bouillonnant, les présentations techniques toujours aussi pointues et l’ambiance autant conviviale que chaleureuse.

Le LUGE s’impose indéniablement comme la rencontre incontournable pour les développeurs LabVIEW / TestStand de la région Rhône-Alpes.

Merci encore aux équipes de Wovalab (Olivier Jourdan - WebServices), SAPHIR (Louis Lafont de Sentenac - Outils Internes & NIPM) et MESULOG (Micaël Da Silva - WebServices et Luc Desruelle - Application Web WebVI avec LabVIEW NXG) pour les présentations.

Merci à National instruments France pour le parrainage du repas de clôture de cette belle journée.

Vous êtes dans la région Rhône-Alpes et vous êtes développeur LabVIEW / TestStand? Venez rejoindre les journées développeurs pour apprendre et partager >>> le user group LUGE

Avec NIDays Paris qui disparait à partir de cette année (et oui!!!) et les journées développeurs en région de National Instruments qui ont déjà disparues, nous avons le plaisir de voir progresser l'intérêt des réunions "LUGE", les journées des développeurs LabVIEW User Group de la région Rhône-Alpes. Mieux nous structurer va permettre de mieux organiser et donc de mieux réaliser le dernier évènement LabVIEW/TestStand local.

La gestion d'un groupe utilisateur LabVIEW, ou "USER GROUP" est divisée en 3 partie : "La partie évènementielle", 'les présentations Techniques" et "l'intendance de la journée".

1. La partie "évènementielle" est gérée via le forum, par l'équipe LUGE. Elle ne change pas entre chaque journée. Il n'y a pas officiellement de "comité", mais elle est gérée par les membres actifs de la communauté LUGE, via le site internet. 
2. La partie "technique" pour proposer des présentations et donner de son temps pour les faire. Nous cherchons toujours des présentateurs.
3. La partie "intendance de la journée" change à chaque réception. Par tradition le sponsor journée est une entreprise. Il "reçoit".

    

Il faut les 3 parties pour réussir une journée de partage LUGE, de la communauté des développeurs de la région Rhône-Alpes. L'organisation de chacune des parties prend du temps. La finalité est le plaisir de partager nos connaissances, d'échanger et de nous rencontrer. L'investissement de chacun pour le collectif est mis en avant.

Principe de l'organisation

Bon partage à tous, au plaisir d'échanger avec vous!

A+

Luc

Date de parution : 22/08/2018

Éditeur Dunod - 4ème édition - 560 pages - EAN13 : 978-210078283

Lien livre LabVIEW sur le site Amazon

LabVIEW est un environnement de développement graphique particulièrement bien adapté au domaine de l’acquisition, de la mesure et du contrôle/commande. 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é complexe lié à la syntaxe.

Co-écrit par un professionnel, cet ouvrage s’adresse du débutant au développeur expérimenté afin de réaliser une application dans les règles de l’art. Des exemples téléchargeables permettent d'illustrer en détail les domaines abordés. Cette nouvelle édition est à jour de la nouvelle version LabVIEW NXG sortie en 2018 et le contenu a été validé par National Instruments, l'éditeur du logiciel.

Il est structuré en sept chapitres :

• Les deux premiers sont consacrés à l’initiation à LabVIEW (160 pages), avec la description du flux de données, des éléments de base et la prise en main de l’éditeur. Il est illustré par des exemples simples.
• Le troisième chapitre (100 pages) aborde la programmation avancée en LabVIEW en définissant des techniques et architectures permettant au code d’être maintenable, évolutif et performant (règle de programmation, définition structure de programme, machine à états, producteur / consommateur, variable globale, FGV, DVR, programmation Objet, projet, gestion des erreurs, génération exécutable)_. Il dévoile des précieuses astuces d’un professionnel pour comprendre les concepts nécessaires à la certification LabVIEW Développeur.
• Les chapitres quatre à six (220 pages) abordent les capacités spécifiques de LabVIEW pour l'acquisition de données sur les cartes National Instruments (via driver DAQmx), le pilotage d'instruments (Série, GPIB, LXI, PXI), la réalisation de driver VISA, les systèmes temps réel & FPGA, le traitement du signal, l'analyse mathématique, la sauvegarde des données et la génération de rapport au format Microsoft Office.
• Le dernier chapitre (130 pages) est consacré à LabVIEW NXG, la nouvelle génération de l’environnement de développement LabVIEW. L’éditeur a été révolutionné pour être plus intuitif, plus moderne, plus ergonomique et s’éloigner du concept de l’instrument physique. De puissants nouveaux concepts apparaissent, comme les interfaces interactives pour réaliser des mesures sans programmation (System Designer), le zoom, les objets vectoriels, les applications web, la génération de code HTML ou la capture des données. Les nouvelles fonctionnalités sont progressivement détaillées, illustrées avec des exemples et complétées par des glossaires. Le lecteur apprend à faire le lien entre les deux environnements et à comprendre les différences. La démarche à suivre pour la migration du code de LabVIEW Standard vers NXG est expliquée concrètement à partir d’un projet. Au final, la création d’applications Web grâce aux nouvelles fonctionnalités offertes par les WebVIs est décrite en détail (génération de code HTML, feuille de style CSS et intégration JavaScript).

Le chapitre 7 de cette nouvelle édition est à jour de la nouvelle version LabVIEW NXG.

Le code des chapitres 2 à 6 sont écrits en LabVIEW « standard », et sont facilement transposables en LabVIEW NXG.

Un lien vers un post du forum francophone qui parle de l’examen Certifié LabVIEW développeur (CLD) :

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/CLD-pr%C3%A9paration/m-p/3082265/highlight/true#M...

Auteurs : Luc Desruelle, Francis Cottet, Michel Pinard

Luc Desruelle

Certifié LabVIEW Architecte, LabVIEW Champion et Certifié TestStand Développeur. Ingénieur, architecte logiciel et chef de projet Test et Mesure chez MESULOG, partenaire National Instruments.

Co-écrit par Luc DESRUELLE, professionnel reconnu de la communauté LabVIEW, ce livre complet et progressif s’adresse du débutant au développeur expérimenté.

Date de parution : 22/08/2018 - Éditeur Dunod - 4ème édition - 560 pages - EAN13 : 978-210078283 - Lien livre LabVIEW sur le site Amazon

Cet ouvrage permet progressivement au lecteur de s’initier aux bases du langage de développement LabVIEW puis aux techniques avancées afin de pouvoir réaliser une application dans les règles de l’art. Il dévoile des précieuses astuces d’un développeur professionnel pour obtenir un code performant et comprendre les concepts nécessaires à la préparation de l'examen Certifié LabVIEW Développeur (CLD). Au fil du livre des exemples concrets et tous téléchargeables gratuitement permettent d'illustrer en détail les domaines abordés.

Cette quatrième édition s’enrichit d’un chapitre consacré à  LabVIEW NXG, la nouvelle génération de l’environnement de développement LabVIEW. Les principes de la programmation en code G restent identiques entre les deux versions de LabVIEW. Mais l’éditeur a été révolutionné pour être plus intuitif, plus moderne, plus ergonomique et s’éloigner du concept de l’instrument physique. De puissants nouveaux concepts apparaissent.

• Description des nouvelles fonctionnalités ;
• Apprentissage de l’utilisation du nouvel éditeur ;Interfaces interactives pour réaliser des mesures sans programmation et System Designer ;
• Zoom, Unicode et objet vectoriel ;Applications Web avec les WebVIs, génération de code HTML, feuille de style CSS et intégration JavaScript ;
• Capture des données, exportation et importation ;
• Analyse détaillée de la méthodologie d’une migration de code de LabVIEW Standard vers NXG, à partir d’un projet ;
• Glossaires de synthèse ;

Le livre  aborde de façon très pédagogique les capacités spécifiques de LabVIEW pour l’acquisition, l’analyse et la présentation des données.

• L'acquisition de données sur les cartes National Instruments (driver DAQmx, utilisation MAX, assistant DAQ, acquisition point à point & fini & continu);
• Le pilotage d'instruments (série, GPIB, LXI, PXI, PCI) en VISA & IVI et la réalisation de driver Plug & Play VISA;
• Introduction aux systèmes temps réel RT & FPGA;
• Le traitement du signal, filtrage et analyse mathématique;
• La sauvegarde des données (fichier texte, tableur, ini, base de données);
• La génération de rapport professionnel au format Microsoft Office (report generation toolkit)
• L'échange de données via TCP IP;
• et autres...

Des techniques de programmation suivantes sont abordées :

• Flux de données ;
• Modèle d’architecture  de programme ;
• Respect des bonnes règles de développement de National Instruments ;
• Gestion des erreurs ;
• La gestion des données : locale, globale, nœud de propriété, variables fonctionnelles (FGV), Action Engine (AE), programmation Objet (OOP), DVR;
• Les modèles de projet (VI général, machine à états, producteur/consommateur événementiel, boite de dialogue)
• Réalisation d’une Interface Homme Machine (IHM) simple et esthétique ;
• Sauvegarde des mesures dans un fichier tableur
• Réalisation d’un rapport d’essai sous Excel, avec mise en forme et directement imprimable ;
• Génération exécutable.

 exemple du contenu du livre 

LabVIEW NXG : Mes 7 fonctionnalités préférées

LabVIEW NXG et les WebVIs : Introduction à utilisation du module LabVIEW NXG Web

De LabVIEW à NXG, la nouvelle génération de LabVIEW : Et vous, êtes-vous prêt pour cette révolution

Bonjour à tous, je vous présente la présentation que j'ai faite au LUGE 2018 sur LabVIEW NXG : mes 7 fonctionnalités préférées.

La présentation est détaillée dans un article sur mon blog LabVIEW : ici.

Retour rapide sur cette très belle journée du jeudi 15 juin 2018, pour le LUGE 5.0 : le User Group des développeurs LabVIEW / TestStand en Rhône-Alpes. 

La journée du LUGE 2018 a été une très belle réussite. Le contenu technique des présentations a été très riche (LabVIEW NXG, WebVI, méthode Agile, Malleable VI,…), le nombre des développeurs présents a atteint un record avec une quarantaine de passionnés, l’échange de retour d’expérience a été bouillonnant et l’ambiance a été autant conviviale que chaleureuse

Bonne lecture et A+ Luc

Retour rapide sur cette très belle journée du jeudi 15 juin 2018, pour le LUGE 5.0 : le User Group des développeurs LabVIEW / TestStand en Rhône-Alpes. 

LUGE 5 retour sur une journée riche en échange

La journée de hier a été une très belle réussite. Le contenu technique des présentations a été très riche (LabVIEW NXG, WebVI, méthode Agile, Malleable VI,…), le nombre des développeurs présents a atteint un record avec une quarantaine de passionnés, l’échange de retour d’expérience a été bouillonnant et l’ambiance a été autant conviviale que chaleureuse.

Le LUGE s’impose indéniablement comme la rencontre incontournable pour les développeurs LabVIEW / TestStand de la région Rhône-Alpes.

Merci encore aux équipes SAPHIR et MESULOG pour l’organisation et les présentations.

Merci à National instruments France pour le parrainage du repas de clôture de cette belle journée.

LUGE : LabVIEW User Group des développeurs en Rhône-AlpesLes développeurs en Rhône-AlpesLuc Desruelle présente LabVIEW NXG et les WebVILes développeurs en Rhône-AlpesLes développeurs en Rhône-Alpes

Un an après la sortie officielle de la première version de LabVIEW NXG, à NIWeek 2017, et après avoir bien travaillé avec les versions 1.0, puis 2.0, et actuellement la 3.0 beta, je vous présente mes 7 fonctionnalités préférées. Ce sont souvent des fonctionnalités que les développeurs réclamaient sur le forum « LabVIEW idea exchange ».

1- Le zoom et les objets vectoriels font leur apparition

C’est la fonctionnalité la plus acclamée, voir la plus applaudie, lors des présentations dévoilant la nouvelle génération de LabVIEW.

• Sur l’interface : Avec NXG les objets graphiques sont vectoriels et il devient possible de zoomer sur l’interface avec un rendu de très grande qualité.
• Sur le diagramme : Zoomer dans un diagramme est une demande autant décriée par certains que réclamée avec insistance par d’autres. Les détracteurs l’associent à un manque de modularité. Les partisans réclament de pouvoir gérer la visualisation globale ou sur un détail du code. LabVIEW étant un langage graphique, qui représente le code par un schéma, je pense qu’il est légitime de permettre de zoomer

Le zoom et les objets vectoriels font leurs apparitions

2 - Construire une application Web avec les WebVIs. Disponible dans le module LabVIEW NXG Web.

C’est surement la deuxième fonctionnalité la plus attendue. Avec la généralisation des tablettes et smartphones, les développeurs réclament la possibilité d’utiliser leur logiciel au travers d’une interface Web. Mais toujours dans l’esprit de LabVIEW donc sans faire de code textuel. Depuis la version 2.0, NXG répond à cette demande. L’éditeur permet de placer des contrôles HTML5 et de générer le code. Il est possible de modifier le code source HTML, soit pour ajouter des fonctionnalités avec du code JavaScript, soit pour personnaliser l'apparence des contrôles en utilisant une feuille de style CSS (Cascading Style Sheets). Dans la version standard, il existe déjà une fonctionnalité permettant de se connecter à la face-avant d’un VI depuis une interface web. Mais cette fonctionnalité nécessite d’installer le RunTime LabVIEW, qui ne supporte pas toutes les plates-formes, et d’activer un plugin Web qui n’est compatible qu’avec certains navigateurs internet. Avec NXG finit les limitations. Les WebVIs peuvent être déployés sur toutes les plateformes, sur n'importe quel navigateur et sans plug-ins.

La fonctionnalité est très bien. J'adore! Il est possible de connecter très facilement l'application Web à un vi LabVIEW ou à un gvi LabVIEW NXG.    

Construire une application Web avec les WebVIs sous LabVIEW NXG

3 - L’Unicode devient natif.

Malgré la réalisation d'applications qui devaient gérer plusieurs langues (à l'affichage), je n'ai jamais sollicité cette évolution. Mais beaucoup de développeurs réclamaient cette évolution depuis plusieurs années!!

L’intérêt de l’Unicode est de pouvoir gérer de façon unique un caractère indépendamment de la langue. Dans la version standard de LabVIEW, il faut changer les paramètres du système d’exploitation pour gérer correctement les différentes langues. NXG gère le standard Unicode en natif (UTF8). Il est maintenant possible d’afficher des textes en français ou chinois ou russe en même temps et sans changer les paramètres de l’OS.

L’Unicode devient natif

4 - Génération de rapport Excel, sans Excel.

Permet de générer des rapports Excel sans Excel... permet de limiter l'achat de licence, donc forcement cela permet de généraliser l'utilisation de cette technologie.

Amélioration des outils de génération de rapport au format Microsoft, sans avoir Word ou Excel installés sur l’ordinateur. Vous avez la possibilité d'exporter vos mesures dans un fichier au format Microsoft Excel existant ou de créer un nouveau fichier par programmation.

5 - NI Package Manager (NIPM).

C’est le nouveau gestionnaire de paquets de National Instruments.

Il remplace l’incontournable VI Package Manager (VIPM). Le gestionnaire automatise le processus d’installation, de désinstallation et de mise à jour de paquets. Avec la nouvelle version NXG, National Instruments modifie sa philosophie de gestion des fichiers informatiques en généralisant l’utilisation de ce format.

NI Package Manager (NIPM) remplace le VIPM

6 - SystemDesigner.

C'est la fonctionnalité mise en avant par National Instruments. 

En mode En Ligne : Rechercher, identifier, configurer et documenter les éléments de votre système matériel à partir d’une interface interactive, et intégrée à NXG.

En mode Conception, il est possible de créer une configuration, avec du matériel non connecté, en utilisant l'intégralité des produits du catalogue de National Instruments.

Intégré dans NXG : Rechercher, identifier, configurer et documenter les éléments de votre système matériel

7 - Capture et analyse des données de l’environnement de développement.

Pour finir, ma fonctionnalité préférée.

Sa portée est très vaste, puisqu’elle est utilisable dans l’ensemble de l’environnement NXG. Elle permet aussi bien la capture et l’analyse de signaux d’acquisition sur le matériel connecté que la mise au point de code pour le développeur. Je trouve cette fonction très bien pensée. Les données collectées sont ensuite disponibles dans la fenêtre d'affichage des données capturées (Data Viewer).

Je me demande encore comment j'arrivais à mettre au point une application sans (?)

Capture et analyse des données de l’environnement LabVIEW NXG

Pour en discuter...

Cet article est détaillé dans le Chapitre 7 de la prochaine version du livre 
"LabVIEW programmation et application - Introduction à LabVIEW NXG" - 4ème édition
qui sortira le 22/08/2018, aux éditions DUNOD - 560 pages - EAN13 : 978-210078283 Lien livre LabVIEW sur le site Amazon. Description détaillée du livre ici

 LabVIEW User group de la région Rhône-Alpes prochaine rencontre à Barraux (38), dans les environs de Grenoble

La prochaine rencontre aura lieu le 14 juin 2018 de 13h à 18h à Barraux (38) dans les environs de Grenoble

• Inscription --> https://doodle.com/poll/hi98r87ptwrdq45g
• Lien vers la discussion

Le groupe est encadré par une équipe de développeurs passionnés et compétents. Convivialité rime avec compétence. Sont présents à nos rencontres des certifiés architectes / développeurs LabVIEW et TestStand, ainsi que des LabVIEW Champion.

Le seul mot d'ordre : "partager, apprendre, découvrir ce que permet LabVIEW, avec enthousiasme et bonne humeur" !

 Venez apporter votre pierre à la réussite de ces rencontres.

Dans le partage et la convivialité, l’objectif est d’amener les participants à franchir des paliers dans leur pratique de LabVIEW. Sont régulièrement au programme les bonnes règles de développement, l’utilisation des exemples de projets, la découverte de nouvelles technologies, l’analyse de code, l’assistance sur un code problématique, les interfaces utilisateurs.

A+

LabVIEW User Group de la région de Grenoble (LUGE)

Disponible depuis LabVIEW NXG 2.0, l'utilisation du module LabVIEW NXG Web permet de réaliser des applications Web à partir des WebVIs. 

Cet article est détaillé dans le Chapitre 7 de la prochaine version du livre 
"LabVIEW programmation et application - Introduction à LabVIEW NXG" - 4ème édition
qui sortira le 22/08/2018, aux éditions DUNOD - 560 pages - EAN13 : 978-210078283 Lien livre LabVIEW sur le site Amazon. Description détaillée du livre ici

C’est surement une des fonctionnalités les plus attendues de LabVIEW NXG 2.0.

Avec la généralisation des tablettes et smartphones, les développeurs réclament la possibilité d’utiliser leur logiciel au travers d’une interface Web. Mais toujours dans l’esprit de LabVIEW donc sans faire de code textuel. LabVIEW doit permettre de créer facilement des applications Web en s’appuyant sur des technologies standards.

Depuis la version 2.0, NXG répond à cette demande. L’éditeur permet de placer des objets HTML5 et de générer le code. Il est possible de modifier le code source HTML, soit pour ajouter des fonctionnalités avec du code JavaScript, soit pour personnaliser l'apparence des contrôles en utilisant une feuille de style CSS (Cascading Style Sheets). Vous pouvez modifier des propriétés telles que la police, la couleur, la forme ou la disposition d'un contrôle.

Dans la version standard de LabVIEW, il existe déjà une fonctionnalité permettant de se connecter à la face-avant d’un VI depuis une interface web. Mais cette fonctionnalité nécessite d’installer le RunTime LabVIEW, qui ne supporte pas toutes les plates-formes, et d’activer un plugin Web qui n’est compatible qu’avec certains navigateurs internet. Avec NXG finit les limitations. Les WebVIs peuvent être déployés sur toutes les plateformes, sur n'importe quel navigateur et sans plug-ins.

Application Web avec les WebVIs de LabVIEW NXG

Figure 7.10 –NXG permet de concevoir et de déployer des interfaces web

L'utilisation du module est décrit en détail dans le livre "LabVIEW Programmation et applications - Introduction à LabVIEW NXG"  – 4iéme édition parution 2018 aux éditions DUNOD.

Cet article est détaillé dans le Chapitre 7 de la prochaine version du livre 
"LabVIEW programmation et application - Introduction à LabVIEW NXG" - 4ème édition
du 22/08/2018, aux éditions DUNOD - 560 pages - EAN13 : 978-210078283 Lien livre LabVIEW sur le site Amazon. Description détaillée du livre ici

7.1.1 - L’annonce de la Nouvelle génération en 2017

Chaque année, la société National Instruments organise sa grande manifestation « NIWeek » au Texas. NIWeek consiste en un grand show d’une semaine pendant lequel alternent, autour d’une salle d’exposition, des conférences de presse (« keynotes ») et des conférences techniques. Des experts reconnus y présentent en détails les produits matériels et logiciels de l’entreprise. Lors de la conférence d’ouverture de la manifestation, National Instruments annonce ses grandes nouveautés. Pour les ingénieurs et scientifiques qui utilisent des systèmes de test automatisé, c’est un peu Noël avant l’heure, c’est l’évènement de l’année à ne pas manquer.

Lors de la NIWeek 2017, National Instruments a dévoilé une très grande nouveauté, que la société préparait depuis quelques années. En effet, alors que nous étions habitués depuis 2009 à avoir une version de LabVIEW par millésime, National Instruments a présenté deux nouvelles versions : LabVIEW 2017, la version « Standard », et LabVIEW NXG 1.0, la « Nouvelle génération » (NeXt Generation).

LabVIEW 2017 est l’évolution annuelle de LabVIEW. C’est la version « Standard » (figure 7.1). L’environnement de développement est totalement dans la continuité de son prédécesseur LabVIEW 2016, ou que de son successeur LabVIEW 2018. En tant de développeur professionnel, mon avis est qu’elle n’apporte pas d’améliorations majeures. Je découvre quelques nouvelles fonctionnalités, certaines très intéressantes, mais que je qualifierais « de petites améliorations ». Les versions suivantes du LabVIEW millésimé resteront dans cette branche logicielle dite « standard ».

LabVIEW 2017

 Figure 7.1 – LabVIEW 2017 est l’évolution annuelle de LabVIEW. C’est la version « Standard ».

LabVIEW NXG est la nouvelle génération du logiciel LabVIEW. Il n’est plus question d’évolutions mais de révolution (figure 7.2). Fruit de plusieurs années de recherche et développement, cette première version de NXG est bien le lancement de la nouvelle génération de LabVIEW. Au fil des années, elle doit devenir une « Better LabVIEW », une version plus crédible, plus ergonomique et plus performante de LabVIEW.

Pour des raisons évidentes le nom LabVIEW a été conservé. Mais ne nous y trompons pas, nous sommes bien sur deux versions indépendantes et incompatibles de l’environnement de développement. Le code de la version « standard » doit être migré, via un utilitaire, pour être utilisé sur la version « NXG ». Suite à cette conversion un « VI » devient un « GVI ». Par contre, il est impossible de faire le chemin inverse. Il n’est pas possible de convertir un code compilé dans l’environnement « NXG » vers la version « Standard ».

 LabVIEW NXG Panneau de mesureLabVIEW NXG exemples

Figure 7.2 – LabVIEW NXG est la nouvelle génération du logiciel LabVIEW.

7.1.2 L’anecdote historique, par les yeux du professionnel

NXG est né de la volonté d’un retour aux idées d’origine de la création de LabVIEW. Les idées « encore à implanter » que décrient Jeff KODOSKY dans la préface du livre, « revenir en mode invention, avec la possibilité d’aboutir à une réalisation aussi innovante que l’était LabVIEW 1 ».

Au détour de petites confidences faites par des membres de National Instruments, nous trouvons trace de l’idée de faire une « Better LabVIEW » ou nouvelle génération de LabVIEW au début des années 2000. Dans les années 2010, le programme prend de l’ampleur pour accélérer en 2014 avec les premières présentations à un cercle restreint de partenaires.

C’est un avis qui n’engage que moi (Luc DESRUELLE), mais je mets en parallèle l’effort énorme de NI pour développer cette version qui doit révolutionner « LabVIEW », et le sentiment que la version « standard » n’a plus d’ajout de fonctionnalités majeures depuis 2014.

Dès 2015, en tant que « Certifié Architect LabVIEW », j’ai eu le privilège de participer aux tests de la version « préliminaire » de NXG. Avec d’autres confrères, j’ai ainsi intégré le programme « Platform Developper Preview (PDP) ». La finalité de ce programme était d’ouvrir les tests de la version « Alpha » à des développeurs extérieurs à la société National Instruments. Je me souviens notamment avoir été sollicité, avec mon ami Olivier JOURDAN (LabVIEW Champion), pour la nouvelle traduction en français de « front-panel ». En effet par référence à la face-avant d’un instrument physique, la version « standard » utilise le terme anglais « front-panel » pour désigner l’interface utilisateur du programme, qui est un « Instrument Virtuel » en LabVIEW. La nouvelle version anglaise de NXG utilise le terme « Panel », dans l’objectif d’éloigner LabVIEW du lien trop étroit avec l’instrumentation physique et d’affirmer le code G en tant que langage de programmation plus général. Dans la version française fallait-il utiliser Panneau ? Face ? Panel ? UI ? Après de longues conversations, à peser les mots et leurs conséquences, la « face-avant » va devenir « Interface » (figure 7.3). C’est l’interface visuelle du programme, dans l’éditeur c’est l’interface entre le code et le développeur. Participer à cette aventure, même modestement, voire comment était géré un nouveau logiciel prochainement utilisé par des milliers d’utilisateurs dans le monde, a été un réel plaisir et une expérience enrichissante.

Peu à peu le programme de test de la version « Beta » a été ouvert à un public élargi au travers du « Software Technologie Preview ». Fin 2016, National Instruments a subtilement orchestré les fuites d’une nouvelle génération de logiciel. Des fonctionnalités très attendues par les développeurs ont été annoncées « En développement » sur le forum « LabVIEW idea exchange », l’espace de discussion des suggestions d’évolutions.

La nouvelle génération NXG version 1.0 a été officiellement annoncée le 23 mai 2017 lors du salon NIWeek. Cette première version ne présentait pas encore toutes les fonctionnalités de LabVIEW Standard, loin de là. Sous le slogan « Aussi productif que LabVIEW, la programmation en option », elle focalise l’attention sur le premier pilier de cette version qui est une nouvelle approche de l’automatisation des mesures, dans un seul logiciel et sans programmation. Cette première version est incomplète. Elle ne possède pas l’ensemble des fonctionnalités nécessaires à la programmation, ni l’ensemble du support matériel. Elle n’est qu’une première étape. Avec cette version incomplète, le public interprète parfois, et à tort, que cette version est juste un nouvel outil pour faciliter l’acquisition de données.

En 2018, elle sera suivie par la version NXG 2.0 et vraisemblablement par une autre version (dévoilée) lors de NIWeek 2018. Cette deuxième version amène véritablement les outils de développement nécessaires à la programmation en code G. C’est le deuxième pilier de la révolution. De nouvelles fonctionnalités sont dévoilées, comme les WebVIs. Cette révolution est tellement ambitieuse, qu’elle se déroule par étapes successives. Il faudra attendre 2019 pour avoir une grande partie des concepts et toolkits équivalents à la version standard, dans cet environnement innovant, modernisé et résolument tourné vers le futur de LabVIEW.

A l’heure où j’écris ces lignes, il est toujours possible de s’inscrire au programme « Aperçu Technologie des logiciels de NI » pour obtenir et tester la version « Béta » la plus récente du logiciel LabVIEW NXG. Il est ainsi possible de faire des commentaires et proposer des idées qui auront un impact direct sur le développement du logiciel.

Et vous, êtes-vous prêt pour cette révolution ?

La peur de ne pas retrouver l’outil de ses rêves.

En 2015 lors d’une avant-première de la version Alpha de NXG, dans une salle feutrée au public confidentiel, ma première pensée aura été la peur. Cela peut sembler exagéré. Mais lorsque nous maitrisons un outil, que nous l’utilisons au quotidien, que nous prenons beaucoup de plaisir à l’utiliser, c’est bien la peur du changement qui est le premier sentiment qui me vient. La peur de ne plus retrouver ses habitudes. La peur de ne pas retrouver l’outil de ses rêves. Mais il faut accepter le changement. Sortir de sa zone de confort. A l’identique de la théorie de l’évolution de Charles Darwin, « Dans la lutte pour la survie, les espèces les plus fortes sont celles qui s’adaptent le mieux au changement de leur environnement ». Il est vrai que pour survire il faut s’adapter, évoluer pour s’améliorer. Cela est également vrai dans le monde du logiciel.

7.1.3 Ce qui n’a pas changé : LabVIEW reste LabVIEW

« Vous avez aimé LabVIEW, vous aimerez LabVIEW nouvelle génération », sont les premiers mots que les ingénieurs de National Instruments prononcent lorsqu’ils dévoilent le nouvel environnement. Cette promesse doit nous rassurer. C’est évidemment un des premiers piliers du cahier des charges de NXG. Avant de décrire en détail ce qui a changé avec LabVIEW NXG, commençons ce chapitre par ce qui n’a pas changé.

Pour faire un petit rappel théorique du chapitre 1 sur « les concepts et l’environnement de programmation », LabVIEW propose un cadre de programmation graphique, basé sur le principe de « flux de données » et enrichi des deux extensions « mémorisations » et « structures de programmation ». Ce langage de programmation est appelé « langage G » ou « code G ». L’intérêt premier de la programmation graphique est que le code est représenté par un « schéma », par opposition aux « mots » du langage textuel. Le code obtenu est ainsi plus intuitif et naturel. Comme il a été également détaillé dans le chapitre 3, LabVIEW est un langage compilé. La compilation signifie que le code G est traduit en code machine, et qu’il est exécuté directement par l’ordinateur. Ce processus travaille pour nous en optimisant fortement le code pour améliorer la gestion mémoire et les performances d’exécution (cf §3.1.2).

L’environnement de développement LabVIEW permet de manipuler une grande variété de concepts, tel que :

• Les terminaux, représentent la production et consommation de données ;
• Les nœuds, traitement à effectuer qui sont représentés par une figure, et possèdent des connexions d’entrée et de sortie ;
• Les fils de liaison, relient nœuds et terminaux, ils permettent le passage des données ;
• Le flux de données, propagation des données, par les fils de liaison entre les terminaux et les nœuds. Un nœud ne s’exécute que si l’ensemble des données d’entrées sont disponibles ;
• La mémorisation des données, pouvoir réutiliser des données produites ;
• Les structures de programmation, gérer des choix et des itérations ;
• La programmation objet, la gestion évènementielle, l’encapsulation, le typage de données, etc.

La nouvelle génération NXG reste LabVIEW (voir figures 7.3 et 7.4). Un environnement de développement, orienté test et mesure, qui permet de programmer en code G dans un diagramme. Le code graphique reste. L’ensemble des concepts qui en font la puissance reste inchangé. Les terminaux, les nœuds, les structures, la propagation du flux de données sont présents (ou seront présents dans les versions prochaines). Les bibliothèques d’intégration du matériel d’acquisition (DAQmx) et des instruments (VISA, IVI) restent. Les outils sont toujours disponibles au-travers d’une palette.  Le principe et la philosophie de la programmation en code G restent inchangés. Un point également très important à retenir, le compilateur est le même (cf §3.1.2).

LabVIEW NXG reste LabVIEW Figure 7.3 – LabVIEW NXG reste LabVIEW

Le même code en LabVIEW Standard et NXG

 Figure 7.4 – Le même code en LabVIEW Standard et NXG.

LabVIEW reste le même LabVIEW que celui que nous aimons. Lorsque j’entends cette nouvelle et je l’écris avec beaucoup d’humour, et en tant qu’auteur du livre je pousse un soulagement. Je n’ai pas besoin de réécrire l’ensemble du livre.

• En effet le chapitre 1 qui décrit les concepts et l’intérêt de la programmation graphique, qui permet de représenter du code par un schéma, reste inchangé.
• De même le chapitre 3 qui décrit les « bonnes règles » de développement afin que le code soit maintenable, évolutif, performant et compréhensible par d’autres concepteurs d’applications est toujours valable.
• Pour les chapitres 4 et 5, là encore, les principes et structures pour acquérir, analyser et présenter les données par programmation sont toujours vrais.

Sur le fond, les compétences que doit avoir « un bon programmeur G » s'appliquent toujours. Pour aller dans ce sens les certifications délivrées par National Instruments et qui ont été obtenues avec la version standard de LabVIEW sont toujours valables : certifications développeur « CLAD » & « CLD » et certification architecte « CLA ». Les fondements de LabVIEW sont inchangés. Un LabVIEW Champion est toujours compétent sous NXG. Ce qu’un développeur peut faire dans LabVIEW 2018, il sera capable de le faire dans LabVIEW NXG, dans quelques années lorsque cette version aura toutes les fonctionnalités.

Sur la forme, l’éditeur de l’environnement NXG a évolué pour être plus intuitif et s’éloigner du concept de l’instrument physique. De nouveaux concepts apparaissent, comme des interfaces interactives pour réaliser des mesures sans programmation. Le développeur devra donc changer quelques habitudes. Le chapitre 2 qui présente les éléments de base de la programmation LabVIEW, ainsi que la démarche à suivre pour l’élaboration d’un programme dans l’environnement « Standard » vont donc être repris dans ce chapitre, avec la version NXG.

Bousculer les habitudes, pour apporter une amélioration

Dans le domaine du test et de la mesure, la plate-forme de développement LabVIEW est le logiciel de référence. « Bousculer » les habitudes des utilisateurs est un exercice qui peut s’avérer parfois périlleux. National Instruments prend des risques avec cette version. Tout en gardant la philosophie et les principes du succès de LabVIEW « Standard », la nouvelle version a l’ambition de révolutionner deux concepts :

• Pour les non développeurs, permettre de réaliser simplement des mesures sans faire de code ;
• Pour les développeurs, moderniser l’environnement de développement et ajouter des nouvelles fonctionnalités très attendues.

1) Introduction Simple : Par OPC il y a la notion de serveur et de client.

pour faire très simple

• Le serveur gère la publication des informations entre les clients et les équipements (classiquement un driver communique avec des équipements et permet la lecture / écriture des données, via un nom unique le tag),
• les clients vont se connecter aux Tags du serveur (nom unique) pour faire une lecture ou écriture de la donnée.

 L'article suivant est très bien "Connexion à des systèmes OPC avec LabVIEW"

http://zone.ni.com/reference/fr-XX/help/371361N-0114/lvconcepts/opc_intro/

La fondation OPC définit 8 spécifications :

• OPC Data Access (DA)
• OPC Alarms and Events
• OPC Batch
• OPC Data eXchange
• OPC Historical Data Access
• OPC Security
• OPC XML-DA
• OPC Unified Architecture (UA)

2) LabVIEW en client OPC :

Si vous avez à disposition un serveur OPC, qui permet donc de publier les données d'un équipement, vous avez besoin d'utiliser LabVIEW comme client OPC.

Il y a un bon article : Développement de clients OPC dans LabVIEW (Windows uniquement)

http://zone.ni.com/reference/fr-XX/help/371361N-0114/lvconcepts/opc_dev_clients/

Pour résumer :

NI LabVIEW gère la compatibilité avec 2 spécifications OPC. Il faut donc identifier si le serveur est de type :

• DA : OPC Data Access (DA)
• UA : OPC Unified Architecture (UA)

2.1 Si le serveur est OPC DA

OPC DA est la plus ancienne, et il existe 3 versions, en fonction des versions des possibilités avec LabVIEW

• Version 1.0 : 1 possibilité : il faut utiliser l'API DataSocket pour faire un Client OPC.
• Version 2.x— 3 possibilités : Possibilité d'utiliser l'API DataSocket, ou (Module DSC payant) DSC OPC Client,
• Version 3.0 — 2 possibilités : (Module DSC payant) DSC OPC Client.

2.2  Si le serveur est OPC UA

OPC UA : il faudra les toolkits payant DSC ou RT pour utiliser l'API OPC UA (en client ou serveur)

3) Faire un serveur OPC avec NI LabVIEW

Pour faire un serveur OPC avec LabVIEW il faudra s'orienter vers

• Serveur OPC DA 2.x et 3.0 utiliser le serveur de variable partagée
• Serveur OPC UA utiliser DSC ou RT OPC UA

plus d'informations sur le Moteur de variable partagée (MVP) ou Shared Variable Engine (SVE) en serveur OPC Data Access

http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/opc_conn_from_tpclients/

LabVIEW 8.0 or later contains an OPC server called the Shared Variable Engine (SVE). The SVE supports OPC Data Access 2.x and OPC Data Access 3.0. You can publish data from the SVE using shared variables.

To connect to the SVE from a third-party OPC client, use the ProgID National Instruments Variable Engine. If the OPC client allows you to browse for OPC servers, you can locate the National Instruments Variable Engine under OPC version 2.x or 3.0, depending on which versions the client supports.

In the third-party OPC client, you can browse all data items published by the SVE. The SVE allows connections to scalars and arrays of scalars but does not recognize data items of complex data types, such as clusters. You can browse FieldPoint and DAQ data items under their device categories.

4) un exemple de lecture de données OPC : Client OPC LabVIEW via DataSocket

Personnellement pour communiquer avec des serveurs OPC, comme j'ai très souvent des serveurs OPC DA version 1 ou 2.x, alors J'utilise l'API DataSocket

avec

Un exemple dans les exemples de LabVIEW

C:\Program Files (x86)\National Instruments\LabVIEW 2015\examples\Data Communication\DataSocket\DataSocket OPC\Monitor OPC Items with DataSocket.vi

Ou via l'aide

http://zone.ni.com/reference/fr-XX/help/371361N-0114/lvcomm/datasocket_read/

Exemple Reportez-vous au fichier Simple DataSocket.lvproj, dans le répertoire labview\examples\Data Communication\DataSocket\Simple DataSocket, pour obtenir un exemple d'utilisation de "DataSocket Lire".

5) Décoder le code qualité OPC de la valeur

Il existe des OPC DA Quality Codes que nous pouvons lire via la variable "qualité" de l'API DataSocket

Cet article est constitué d’extraits du livre français sur LabVIEW : « LabVIEW programmation et applications ». Il ne traite que de la réalisation d’un driver d’instrument en VISA. Pour des informations plus complètes sur DAQmx, IVI, les commandes E/S directes, dll externe, la réalisation de driver Plug & Play LabVIEW, la recherche de driver IDNet, etc… je vous conseille le chapitre 4 qui aborde cela en détail.

1      Rappel : Le driver (ou pilote) et le logiciel d’application

Les architectures des instruments et des cartes d'acquisition (DAQ) font apparaître deux éléments communs que sont le driver et le logiciel d’application.

Le logiciel d’application (ou l’application principale) 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 de génération de signaux : National Instruments fournit un driver unique qui est compatible avec toutes les cartes, qui est NI-DAQmx.
• Les instruments : nous utiliserons le driver VISA ou IVI ou un driver spécifique livré par le fabricant avec le matériel. Sous LabVIEW, un driver d’instrument est un ensemble de VIs contenant des fonctions de haut niveau qui permettent de contrôler cet instrument, telles que la configuration, la lecture des mesures, etc. Il inclut et rend donc transparent les commandes de l’appareil et le protocole de communication spécifique au bus. La liste des commandes est décrite dans le manuel de programmation de l’instrument et elle va permettre de coder le driver de l’instrument.

2      Rappel VISA - Virtual Instrumentation Software Architecture

Au début des années 1990 le consortium VXIplug&play Systems Alliance a développé la spécification du logiciel d’E/S VISA, pour Virtual Instrumentation Software Architecture. VISA définit des fonctions d’entrées/sorties standard pour la programmation d'instruments. Ces fonctions :

• s’interfacent toujours de la même manière quel que soit le matériel de connexion (GPIB, Série, USB, Ethernet, PXI, VXI) ;
• sont indépendantes de la plate-forme matérielle et système d’exploitation.

Par exemple, un programme développé sur PC Windows pour piloter un oscilloscope en liaison GPIB sera identique à un programme développé sous Linux pour le piloter par une liaison série.

Les drivers « LabVIEW Plug & Play » et « IVI » utilisent la puissante librairie d’entrées / sorties de VISA VISA I/O.

Les drivers LabVIEW plug&play et IVI s’appuient sur la puissante librairie VISA. VISA permet d’avoir des fonctions logiciels identiques quelle que soit la connexion (GPIB, Série, USB, Ethernet, etc.).

3      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 VIs et de propriétés.

Dans la réalité, seulement 6 fonctions sont nécessaires pour écrire la très grande majorité des drivers : Ouverture, fermeture, temps d'attente, lecture, écriture et paramètrage.

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 :

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 ;

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é ;

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

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

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 3 conditions est présente :

• Un caractère de terminaison est arrivé ;
• Le nombre d’octets dans le buffer de réception est égal à celui passé en paramètre à la fonction VISA Read ;
• Le temps d’attente a dépassé le TimeOut. 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.

Paramétrage du port série

6. Il faut configurer les paramètres du port série de l’ordinateur pour être en adéquation avec la configuration du protocole de l’instrument, via la fonction VISA Configure Serial Port.vi de la sous-palette Série. En effet, la communication série autorise des options de paramétrages, comme le baud rate, le nombre de bits de données, la parité, le timeout mais également l’activation et la définition du type de caractères de fin de communication.

Nom de la ressource VISA

L’API VISA est une interface capable d’appeler automatiquement les fonctions bas niveau de communication appropriées, grâce à un seul paramètre Nom de la Ressource VISA.

Nom de la Ressource VISA	Exemple	Description du BUS
GPIB ::adresse ::INSTR		GPIB
Alias VISA		Série, ALIAS configuré dans MAX.
TCPIP ::adresse ::INSTR		LXI sur le LAN Ethernet

seulement 6 fonctions sont nécessaires pour écrire la très grande majorité des drivers.

4      Exemples Pilotage d’un instrument avec lecture d’un nombre fixe d’octets

Dans cet exemple, nous allons illustrer la lecture du nom d’indentification d’un appareil. L’appareil est à l’adresse GPIB 12 sur le bus et il répond « 73 octets » à la commande « *IDN ? » :

1. Ouverture d’une communication avec l’appareil de mesure sur le port GPIB à l’adresse 12 (GPIB ::12 ::INSTR) ;
2. Configuration du timeout de communication à 2 000 ms ;
3. Écriture de la commande « *IDN ? » qui permet de demander le nom d’identification à l’appareil ;
4. Attente de la réponse de l’appareil. Cette réponse est composée de 73 octets et sera disponible au format ASCII dans le « buffer de lecture ». Si l’appareil ne répond pas 73 octets en 2 secondes, nous aurons une erreur LabVIEW ;
5. Fermeture de la session.

Exemple du pilotage d’un instrument GPIB via VISA.

5      Exemple Pilotage d’un instrument Série avec caractère de fin de communication

Dans cet exemple, nous allons illustrer la lecture du nom d’indentification d’un appareil sur le bus série. Le port série utilisé sera le port « COM2 », les réponses de l’instrument seront formatées avec un caractère de fin de communication :

1. Permet l’ouverture d’une communication avec l’appareil de mesure sur le port COM2 ;
2. La configuration des paramètres du port série est réalisée par la fonction VISA Configure Serial Port.vi de la sous-palette Série. Elle permet de définir le baud rate, le nombre de bits, la parité, le timeout mais également l’activation et la définition du type de caractère de fin de communication. Dans cet exemple, le caractère de fin est le code ASCII 0xA, soit le code « LF » pour « retour à la ligne » ;
3. Écriture de la commande « *IDN ? » qui demande à l’instrument son nom d’identification ;
4. Attente de la réponse de l’instrument. Nous avons configuré le driver pour attendre un caractère de fin de transmission. Nous allons donc paramétrer un nombre d’octets à attendre supérieur au nombre réellement attendu. En effet, si nous nous rappelons les 3 conditions d'arrêt possibles (nombre de caractères attendus reçus, time-out et caractère de fin présent), le code dans cet exemple stoppera uniquement sur le caractère de fin ou le time out. Dans le cas du time-out, si l’instrument ne retourne pas une réponse en 2 secondes, nous aurons une erreur LabVIEW. ;
5. Fermeture de la session.

Figure 4.57– Exemple du pilotage d’un instrument série via VISA.

L’encapsulation dans un VI LabVIEW des fonctions de pilotage d’instrument permet de réaliser un driver d’instrument. Dans ces exemples simples, nous avons mis en évidence la facilité avec laquelle la palette VISA permet de piloter un instrument. Cependant, et comme toujours, facilité ne veut pas dire qu’il n’y a aucune règle à suivre.

Si vous avez besoin de réaliser des rapports d'essais, il est possible d'ajouter des fonctionnalités à LabVIEW grâce au « Toolkit Report Generation for Microsoft Office ». Le Toolkit ajoute un ensemble étendu de VI pour générer des rapports par programmation dans Microsoft Word ou Excel. 

Il y a principalement 3 méthodes pour réaliser un rapport avec le toolkit

1. Un VI Express Microsoft Office Report permet de rapidement découvrir l'ensemble des possibilités. Personnellement je ne l'utilise pas, je n'utilise pas le VI Express, mais il permet de découvrir les possibilités.
2. Une autre possibilité est d'utiliser les fonctions bas niveau, ou sous-VIs, pour générer complètement l'apparence du rapport, en partant d'une feuille vierge. Cette méthode nécessite plus de code et plus de temps.
3. Sinon il est très facile de réaliser un classeur modèle sous Microsoft Excel, qui contient la présentation finalisée du rapport d'essai. Il suffit alors d'écrire les données au bon emplacement directement depuis LabVIEW. Lorsqu'il y a plusieurs campagnes de mesure pour un même test, il est possible dans le classeur modèle, d'avoir un onglet modèle à dupliquer pour chaque essai. Dans mon modèle, j'utilise alors la puissance du tableur "Microsoft Excel" pour ajouter des formules pour convertir des données brutes, calculer des statuts à partir de limites, afficher un graphique. Il est possible d'insèrer des macros VBA, et de les exécuter depuis LabVIEW.

La solution 3 a ma préférence.

Un exemple très simple peut être rapidement construit en réalisant un classeur Excel modèle, à partir de mesures. Dans le classeur modèle, nous réalisons toute la mise en page.

La figure suivante présente le « Diagramme »  d'une application qui permet d'importer les mesures dans un classeur Modèle.

Les fonctions utilisées sont très simples.

• « copier » un fichier, de la palette d'E/S sur fichier afin de dupliquer le classeur Excel modèle sous un nouveau nom.
• Les mesures sont dans un tableau à deux dimensions de numérique, qui doit être converti en tableau de chaînes de caractères par la fonction « Nombre en chaîne fractionnaire ».
• Pour insérer les données dans le classeur, la fonction de haut niveau « nouveau Rapport », avec le paramètre « Excel », permet d'ouvrir le fichier.
• Puis la fonction spécifique « Excel insérer un tableau » copie les mesures à l'emplacement désiré, soit dans les cellules de coordonnées [2 ; 25].
• L'appel de la fonction « Fermer le rapport » avec le paramètre « sauvegarder le classeur » finalise l'importation des données.

Le rapport est alors complet, échangeable par e-mail et peut être directement imprimé.

Les plus grosses erreurs? d'un code sous LabVIEW ???

1) Gestion de projet

journée LUGE 1.0 : Les outils qui nous veulent du bien

Plus de temps pour développer en LabVIEW, gestion «projet»

Exemples d’erreurs : bombe à retardement ou Grosses erreurs autour du développement logiciel (?)

• Ne pas savoir où trouver de l’aide

• Pas de logiciel de gestion de version

• Pas de centralisation de l’information

• Pas d’analyse ni de test du code source

• Attendre la fin du projet pour générer l’exécutable

• Pas de gestion de la machine de développement

• Autres ?

Utiliser les logiciels de gestion code source (TortoiseSVN, Subversion), Machine Virtuelle, bug tacker, Forge, VI Analyzer, VI Package Manager

2) Technique, Gestion des données, accès concurrents, mémoire sous LabVIEW

Journée LUGE 3.0 : Darwin appliquée à LabVIEW : l’évolution de la gestion des données

version "full" en EN Darwin applied to LabVIEW: The evolution of the data management

Elle traite de l’évolution

• du concept « mémorisation » du flux de données,
• de la gestion des données sous LabVIEW
• des accès concurrents

avec Contrôle vers indicateur -Locale -Globale -FGV -AE –SEQ -DVR -OOP –SM –QDMH.

La présentation vous permet de répondre à la "simple question" Pourquoi il faut éviter une locale, globale, nœud de propriété... et comment faire.

3) Architecture : Les modèles de projet sous LabVIEW, zoom sur le QDMH (ou QMH)

 Journée rencontres LUGE 2016 : Les modèles sous LabVIEW, zoom sur le QDMH

• Faire un point sur le modèle QDMH qui couvre un grand nombre d’application en restant abordable techniquement
• Discussion sur Améliorations
• Discussion sur Faiblesses / limitations
• Continuer la discussion sur d’autres modèles connus, utilisées et avoir vos avis dessus.
• Le but : Débuter avec le bon modèle…

De l'aide sous LabVIEW? Lorsqu'un développeur débute, il est normal qu'il se pose de nombreuses questions et qu'il ait besoin d'aide. S'il est seul, comme c'est souvent le cas, il peut rapidement se trouver dans une impasse et perdre beaucoup de temps. Il est très important de connaître les bonnes méthodologies à appliquer pour trouver les bonnes réponses.

The survival of the fittest applied to the LabVIEW Dataflow model...

PS : You can download the presentation  Darwin applied to LabVIEW V2.2.pdf attachment and LabVIEW examples code.

Recently, I made a new presentation (LabVIEW User group LUGE) "Darwin applied to LabVIEW: the evolution of the data management." subtitle “The survival of the fittest applied to the LabVIEW Dataflow model ”.

With deep humor this presentation makes the link between the evolution of the LabVIEW data and the Darwin's Theory of Evolution.

The presentation deals with the evolution of the concept of "Data communication" of the LabVIEW dataflow model:

lDataflow element to Variable Interfaces, to Buffer Interfaces

lTo store a value in memory/ To access the value

lTo prevent Race Condition, buffer copies

The presentation does answer the following questions:

lWhy avoiding local, global, Property Node? How to avoid Race Conditions? Does FGV prevents Race Condition (realy!) ?

lWhich method to use? Why?

lWho is the survival of the fittest? (the survival of the most scalable)

• LabVIEW follows a dataflow model
• In dataflow programming, you generally do not use variables. For a literal implementation of this model.
• Dataflow models describe nodes as:
  • consuming data inputs,
  • producing data outputs.
• Advanced concepts : LabVIEW contains many data communication methods.
• For example, local and global variables are not inherently part of the LabVIEW dataflow execution model.

• LabVIEW contains many “data communication” methods, each suited for a certain use case.
• Can by order into 3 types:

lDataflow elements, the primary methods

lVariable Interfaces

lBuffer Interfaces

For diner tonight: Functional Global variable (FGV, LV2), Action Engine (AE), DVR, OOP, State Machine and QMH. Speed demonstration, UI thread, memory management (buffer copies) and Race Condition with simple and downloadable examples.

source: http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/data_comm/

http://zone.ni.com/reference/en-XX/help/371361L-01/lvconcepts/data_comm/

for example, (CLAD exam): Which of the following is the best method to update an indicator on the front panel? And explain WHY please!!!

1. Use a Local variable
2. Wire directly to the indicator « Data Out »
3. Use an implicit « value » property node
4. Use an explicit « value » property node (reference)

A+

Luc Desruelle | | Voir mon profil | Mon blog LabVIEW

CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW

Co-auteur livre LabVIEW : Programmation et applications

LabVIEW Champion

Contact

Un Instrument virtuel (ou VI) sous LabVIEW, C'est quoi? 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 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 (figure suivante). Cette notion sera reprise en détail dans le chapitre 3 du livre "LabVIEW programmation et applications.

• 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. Cette partie de l'application est ce que l'on appelle le code source par opposition à l'interface utilisateur.

LabVIEW ? Vous avez dit LabVIEW ? Le flux de données?

Luc Desruelle | | Voir mon profil | http://fr.linkedin.com/in/labviewcertifiedeveloppeurMon blog LabVIEW

CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW

CTD : certifié TestStand Développeur

Co-auteur livre LabVIEW : Programmation et applications

LabVIEW Champion

Contact

Pour une expertise, un audit, une optimisation, une urgence, de l'assistance, un problème critique, un besoin ponctuel ou pour sous-traiter un développement complet sous LabVIEW, nous vous conseillons de faire appel aux partenaires National Instruments du Programme Alliance.

Moi, Luc DESRUELLE, (certifié LabVIEW Architecte, LabVIEW champion, TestStand Développeur, auteur du livre français "LabVIEW" et rédacteur de ce blog), serait ravi de vous apporter mon expertise et mon aide.

Retour sur NIDays 2016 : Pour la première fois, lors de cet évènement, un stand était dédié à un libraire. Il a présenté, entre autre, la nouvelle édition du livre « LabVIEW : programmation et applications », aux éditions Dunod.

Je développe des logiciels sous LabVIEW dans plusieurs langues : Russe, Chinois, portugais, français, .... pour afficher les texte, menu, gestion erreur,... .Cette question revient souvent sur le forum. Ce post est une compilation de mes réponses du forum sur le sujet.Cela permet de "centraliser" les réponses sur ce sujet.A la fin du post je donne les liens vers les réponses du forum cela permet de laisser la place à la vision d'autres développeurs sur le sujet.

I] Histoire ASCII, code Page, unicode et non unicode

I.1) Histoire

A l'origine du système actuel de codage des ordinateurs se trouve le standard ASCII (American Standard Code for Information Interchange). Il représente le codage numérique de 128 signes. Il est assez évident que ce nombre réduit de signes, s'il suffit pour le codage des caractères usuels de l'anglo-américain, ne permet pas le codage des graphèmes spécifiques d'autres langues européennes, ni même d'une.

A partir du moment où les logiciels de traitement de texte se sont développés et diffusés dans le monde, il a fallu l'étendre à 256 numéros de code : ASCII étendu puis ANSI.

Par la suite les OS ont gérés plusieurs langues différentes : Attribution d'un code unique à tous les caractères utilisés dans les différentes langues du monde et donc la définition d'un jeu unique, universel, de caractères : c'est le standard Unicode. Dans cette idée un caractère est codé sur un U8, U16, U32

Il ne faut pas confondre le multi-byte et unicode. En unicode le caractère est unique dans n’importe quel OS, en multi-byte le caractère a une valeur mais est affiché en fonction des paramètres de l’OS.

Par exemple il existe un Chinois simplifié, écrit de la gauche vers la droite.

I.2) LabVIEW ne supporte pas l'unicode

LabVIEW supporte les caractères « multi-byte » et pas Unicode en natif (en option via fichier ini avec LV2011). Il interprète et affichedonc les caractères Unicode selon l’OS et surtout l’option « Options régionales et linguistiques -> langues pour les programmes non Unicode ».

Si vous tapez du chinois sur votre clavier (ou copier-coller depuis la traduction de google…) vous pouvez mettre du chinois, et même faire un soft mulitlingues.

L'avantage avec l'unicode serait de pouvoir affiché Russe et Chinois sur le même logiciel, comme Internet Explorer.

Mais LabVIEW ne supporte pas l'unicode en standard.

I.3) si vraiment vous voulez utiliser l'unicode

voila des trucs pour y arriver : https://decibel.ni.com/content/docs/DOC-10153

Soutenir l'unicode dans LabVIEW sur le forum idea exchange : http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-Unicode/idi-p/921449

Il est possible d'ajouter le support de l'Unicode dans LabVIEW. Pour cela tu peux editer le LabVIEW.ini et ajouter "UseUnicode=TRUE" (sans les guillemets 😉

Voici un lien qui explique un peu plus en detail l'utilisation de l'Unicode dans LabVIEW.

I.4) Je déconseille d'utiliser l'unciode avec LabVIEW car non supporté

Mais comme LabVIEW ne supporte pas l'unicode en standard, je déconseille de l'utiliser.

par exemple : un Message To User (?) une boite de dialogue? si c'est cela, la boite de dialogue standard n'est pas unicode donc faire comme indiquer dans mon retour, cf une boite de dialogue Russe, sinon tu fais une boite de dialogue "maison", avec une string en unicode.

II] Exemple chinois

Configuration Windows XP pour prise en charge caractères non Unicode

Démarrer -> Paramètres -> Panneau de configuration -> Options régionales et linguistiques ->

• Langues -> Prise ne charge langue supplémentaires -> Installer les fichiers pour les langues d’Extrême-Orient
• Options avancées -> langues pour les programmes non Unicode -> Chinois (république de chine (RPC)
• Redémarrer l’ordinateur

III] Un exemple pour le Russe

IV] Mise en garde sur le nom des VI

Le code LabVIEW est compilé, mais le fichier de l'exe contient la liste des fcihiers. Si dans cette liste, un caractère n'est pas transposable dans la liste des caractères non unicode de la langue de l'OS, l'exe est brisé.

la solution est comme toujours de suivre la régle d'être en ASCII court, donc utiliser les caractères non unicode universels sur les OS, donc les caractères Anglais!

pas de é ou è ou ç ou à dans les nomns de VI ou autres! bonne chance

V] quelques liens sur le forum

quelques liens

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Afficher-des-textes-en-chinois/td-p/2761932

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Texte-chinoix-sur-face-avant/td-p/1855663

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Menu-unicode-codepage/td-p/2688015

VII] Localizing Your LabVIEW Application to Different Languages

Les conseils de National instruments pour la localisation

http://www.ni.com/tutorial/3603/en/ 

VIII] TestStand LabVIEW UI Crashes When Using Chinese Characters

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001DrabCAC&l=fr-FR

Issue Details

• I am localizing TestStand™ to Chinese. When I try to run the shipped TestStand LabVIEW™ User Interface (UI), it crashes. Why?
• TestStand is using Chinese localization but the Chinese characters aren't appearing correctly. How can I fix this?
• After modifying the INI language files in TestStand and running the source code for the LabVIEW UI, LabVIEW crashes. Can I fix this?
• Using UTF-8 Unicode to display Chinese causes my TestStand LabVIEW UI to crash. Is this expected behaviour?

Luc Desruelle | Voir mon profil | Mon blog LabVIEW

CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW

Co-auteur livre LabVIEW : Programmation et applications

LabVIEW Champion

Contact

Extrait du livre "LabVIEW : Programmation et Applications" chapitre 4 Applications : Construire et piloter un système ..."

on branche deux fils et ça fonctionne ?....Construire un système de mesure ou de génération de signal est l’origine de la création de LabVIEW pour acquérir, analyser et présenter les données.

Il est ainsi le langage de développement le plus efficace pour réaliser un tel système.

Nous allons :

• Rappeler les éléments important à prendre en compte lors de la définition du système d’instrumentation sur ordinateur ;
• Expliquer comment réaliser le logiciel avec LabVIEW, aussi bien avec des cartes d’acquisition (DAQmx) qu’avec des instruments de mesure sur table (VISA et IVI) ;
• Introduire l’acquisition de données sur les systèmes Temps Réel (RT) et FPGA.

I] Caractéristiques d’un système de mesure

La réalisation technique se compose en général des éléments suivants :

1. Les capteurs ;
2. Le conditionnement des signaux ;
3. Le câblage ;
4. Le matériel de numérisation / génération de données ;
5. Le driver et logiciel d’application ;
6. L’ordinateur.

II] Quelques rappels

• La tension est la différence de potentiel électrique entre deux points, souvent noté « + » et « – » ;
• Le point de référence est le niveau de tension auquel la mesure est référencée. La Masse est la référence des potentiels électriques. Elle n'est pas forcément reliée à la terre.
• Le Common ou COM est un point de référence du circuit électrique.
• Le GND est le terme anglais Ground pour Masse.
• La Terre est reliée à la terre "physique", et a un potentiel de 0 V. C'est un point de référence du circuit éléctrique avec un potentiel particulier de 0V;
• La définition légale française est : « Terre : masse conductrice de la terre, dont le potentiel électrique en chaque point est considéré comme égal à zéro. »
• Lorsque la Masse est reliée à la Terre, alors la référence des potentiels électriques du circuit est à 0V;

III] A prendre en compte pour faire une mesure

Lors de la connexion de plusieurs sources de tension sur le même système de mesure, il convient d’avoir une référence de masse, physiquement unique et commune afin de ne créer aucune « boucle de masse ».

En effet, deux points de masse distants et connectés entre eux donneront naissance à un courant résiduel entre ces deux points. Ce courant résiduel générera du bruit et altérera la mesure.

Pour comprendre "comment effectuer une mesure ?" Il faut connaître :

1. L’origine électrique des sources de signaux à mesurer : référencé à la masse ou flottant
2. En déduire la connexion sur l'entrée du systéme de mesure: Différentiel, RSE ou NRSE
3. Il faut toujours un référencement à la masse, direct ou via une resistance de polarisation

Pour faire une mesure il convient de connaître la nature du signal à mesurer, au sens de l’origine électrique des sources de signaux. Il en existe deux types:

• Référencé ou relié à la masse
• Non Référencé ou flottant

Dans le cas des cartes d’acquisition de National Instruments, elles sont configurables en :

• Différentiel, aucune des entrées de l'amplificateur d'instrumentation n'est référencée à la masse d'un système. Les mesures effectuées en mode différentiel nécessitent davantage de voies, puisque chaque mesure demande deux voies d'entrées analogiques.
• RSE ou asymétrique référencé à la masse : les mesures ne nécessitent qu'une seule voie d'entrée car le second fil est commun, utilisé par toutes les voies et relié à la masse du système de mesure.
• NRSE ou asymétrique non référencé: comme le mode référencé, mais le point commun n’est pas relié à la masse du système de mesure.

Cet article est en écriture

Quelques règles sur les problèmatiques de temps de chargement des projets. Le texte est une compilation d'informations internet (Pas de moi.)

Some rules to reduce project load time. This text is a blog posts compilation. (i'm not the author). Links at the end (LAVA or NI website).

I] LV project... and VI in memory

http://forums.ni.com/t5/LabVIEW/How-to-reduce-project-load-time/td-p/936487

The project is a list of the files that you included and their locations :

1. VIs that are listed by the project are not loaded into memory.
2. All library files listed in the project are full loaded into memory when the project loads. But...
   • LVClasses and XControls are both types of libraries. These two types will load all of their member VIs into memory whenever they themselves are loaded into memory.Therefore...
   • A project which loads classes or XControls will -- indirectly -- load all the VIs of those classes or XControls into memory.

3. Any VI that is loaded will load all of its subVIs, whether the subVIs are explicitly listed in the project or not.

II] Loading XXX into memory causes XXX to be loaded into memory or not!

• Loading a vi into memory also causes all (statically) dependent vis to be loaded into memory as well (par exemple le VI Tree). SubVIs are not automatically loaded into memory until the top-level VI is called.
• Loading a library member (*.vi, *.ctl, etc.) always causes the owning library file (*.lvlib, *.lvclass, etc) to be loaded into memory.
• Loading a class file (*.lvclass) into memory causes all class members (*.vi, *.ctl, etc.) to be loaded into memory.
• Loading a project library file (*.lvlib) does not cause all library members (*.vi, *.ctl, etc.) to be loaded into memory.
• Loading a library file (*.lvlib, *.lvclass, etc.) also causes all sub library files (*.lvlib, *.lvclass, etc.) to be loaded as well.

III] To improve the performance

Put all your VIs and classes into a .llb file

To improve the performance (about LV R&D, Aristos Queue) : Put all your VIs and classes into a .llb file. The .llb optimizes the contents of the file and significantly improves load speed when a block of VIs must load as one.

https://lavag.org/topic/14174-extremely-long-load-time-with-lvoop-supanels-and-vi-templates/

The .lvlib is likely having minimal impact on your project load time. The expense is generally from the large number of dependencies that your main VI has.

Move your files to an inner sector of your hard disk.

No, I'm not joking. We have found that hard drives these days are so wide in diameter that location on disk has a massive impact on seek times. Of course, this isn't generally under user control.

Get a solid state drive : SSD

Blazing fast load speeds regardless of what you're working on. Gets rid of the diameter of disk issue.

Save VIs inside .llbs.

The single biggest hit during load is disk seek time, and LLBs solve that by making one file, one file which is optimized for loading the parts of a VI hierarchy. This only helps if you are actually using most or all of the VIs in that LLB.

Turn on "Separate compiled code from source file"

Turn on "Separate compiled code from source file" on all your member VIs and libraries. Makes the VIs you are loading much smaller because the code segment is now in a separate database.

IV] LV project : Is there a performance difference between autopopulated and static folders?

I assume so. I consider autopopulate folders to be way more trouble than they are worth, so I never use them. But every time the project loads it would have to scan the entire directory and rebuild instead of just reading the file, and then any items that are in libraries have to be moved from their place in the autopopulate directory to their place in the library. That could be a lot of work.

website links

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

http://www.ni.com/white-paper/3574/en/

http://forums.ni.com/t5/LabVIEW/How-to-reduce-project-load-time/td-p/936487