Pour une expériencenet et une sécurité optimale, mettez à jour votre navigateur. Mettre à jour maintenant
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
é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
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+
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
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.
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 :
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
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.
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.
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.
Dans cette présentation, je vous propose de
Le module Web de LabVIEW NXG, permet de réaliser une application web standard, conforme aux technologies Web, par exemple :
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.
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 :
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) :
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.
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 :
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.
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
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.
Le rapport est alors complet, échangeable par e-mail et peut être directement imprimé.
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".
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
Point |
Gestion |
Quoi ? |
Qui ? |
N°1 |
La partie évènementielle |
Définir l’agenda, la sélection des présentations + présentateurs, la relance via la liste de diffusion, contact avec interlocuteur de NI pour la publicité de l’évènement, gestion du site LUGE, etc.
|
Equipe « comité » organisation via le Forum du LUGE.
Les membres actifs du site LUGE. |
N°2 |
La partie technique |
Proposer et faire des présentations techniques
|
Toutes les personnes qui se proposent, et qui sont retenues via le Forum LUGE.
A la recherche de présentateur. |
N°3 |
L’intendance de la journée « Hôte réception » :
|
organiser la salle, validation vidéoprojecteur, contacter traiteur pour « repas ou collation », gestion des frais de remboursement avec NI, gestion horaire
|
Entreprise qui gère la salle de réception.
Elle reçoit.
Les User Group US parlent du « sponsor de la journée » |
Bon partage à tous, au plaisir d'échanger avec vous!
A+
Luc
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 ».
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 ».
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 :
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).
Figure 7.3 – LabVIEW NXG reste LabVIEW
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.
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 :
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.
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.
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.
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.
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.
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.
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.
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 (?)
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
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.
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.
Des techniques de programmation suivantes sont abordées :
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.
La prochaine rencontre aura lieu le 14 juin 2018 de 13h à 18h à Barraux (38) dans les environs de Grenoble
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+
1) Introduction Simple : Par OPC il y a la notion de serveur et de client.
pour faire très simple
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 :
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 :
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
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
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
URL | Exemple |
---|---|
opc |
opc:\National Instruments.OPCTest\élément1 opc:\\computer\National Instruments.OPCModbus\Modbus Demo Box.4:0 opc:\\computer\National Instruments.OPCModbus\Modbus Demo Box.4:0?updaterate=100&deadband=0.7 |
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
Utilisez la valeur du code qualité pour obtenir des informations sur l'état de la valeur OPC (192 = Good) |
Il existe des OPC DA Quality Codes que nous pouvons lire via la variable "qualité" de l'API DataSocket
0 |
0x00000000 |
Bad [Non-Specific] |
4 |
0x00000004 |
Bad [Configuration Error] |
8 |
0x00000008 |
Bad [Not Connected] |
12 |
0x0000000c |
Bad [Device Failure] |
16 |
0x00000010 |
Bad [Sensor Failure] |
20 |
0x00000014 |
Bad [Last Known Value] |
24 |
0x00000018 |
Bad [Communication Failure] |
28 |
0x0000001C |
Bad [Out of Service] |
64 |
0x00000040 |
Uncertain [Non-Specific] |
65 |
0x00000041 |
Uncertain [Non-Specific] (Low Limited) |
66 |
0x00000042 |
Uncertain [Non-Specific] (High Limited) |
67 |
0x00000043 |
Uncertain [Non-Specific] (Constant) |
68 |
0x00000044 |
Uncertain [Last Usable] |
69 |
0x00000045 |
Uncertain [Last Usable] (Low Limited) |
70 |
0x00000046 |
Uncertain [Last Usable] (High Limited) |
71 |
0x00000047 |
Uncertain [Last Usable] (Constant) |
80 |
0x00000050 |
Uncertain [Sensor Not Accurate] |
81 |
0x00000051 |
Uncertain [Sensor Not Accurate] (Low Limited) |
82 |
0x00000052 |
Uncertain [Sensor Not Accurate] (High Limited) |
83 |
0x00000053 |
Uncertain [Sensor Not Accurate] (Constant) |
84 |
0x00000054 |
Uncertain [EU Exceeded] |
85 |
0x00000055 |
Uncertain [EU Exceeded] (Low Limited) |
86 |
0x00000056 |
Uncertain [EU Exceeded] (High Limited) |
87 |
0x00000057 |
Uncertain [EU Exceeded] (Constant) |
88 |
0x00000058 |
Uncertain [Sub-Normal] |
89 |
0x00000059 |
Uncertain [Sub-Normal] (Low Limited) |
90 |
0x0000005a |
Uncertain [Sub-Normal] (High Limited) |
91 |
0x0000005b |
Uncertain [Sub-Normal] (Constant) |
192 |
0x000000c0 |
Good [Non-Specific] |
193 |
0x000000c1 |
Good [Non-Specific] (Low Limited) |
194 |
0x000000c2 |
Good [Non-Specific] (High Limited) |
195 |
0x000000c3 |
Good [Non-Specific] (Constant) |
216 |
0x000000d8 |
Good [Local Override] |
217 |
0x000000d9 |
Good [Local Override] (Low Limited) |
218 |
0x000000da |
Good [Local Override] (High Limited) |
219 |
0x000000db |
Good [Local Override] (Constant) |
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.
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 :
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 :
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.
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 :
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 |
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 ? » :
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 :
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.