• lvrt-schroot : pour LabVIEW 2014, la version initiale
• lvrt20-schroot : pour la future LabVIEW 2020 ?
• lvrt19-schroot : pour LabVIEW 2019 ?

Si l’on essayait ensemble d’installer lvrt19-schroot sur un Raspberry Pi 4 tout neuf ?

Introduction

Avant de commencer, il nous faut un Raspberry Pi (>2) fonctionnel avec la dernière version de Raspbian (Buster à l’heure où ce test a été mené). Pour ma part, je profite de la sortie du Raspberry Pi 4 pour le prendre en main et profité de la connexion WiFi (enfin!).

Installation de LINX 3 pour LabVIEW 2019

Nous sommes prêts? Allons-y !

Tout se passe en ligne de commande. Ouvrez un terminal SSH et connectez-vous sur le Raspberry Pi.

Commençons par mettre à jour notre installation:

• sudo apt-get update
• sudo apt-get dist-upgrade -y

Ensuite activons les modules i2c et spi:

• sudo raspi-config nonint do_i2c 0
• sudo raspi-config nonint do_spi 0

Ajoutons le dépôt d’installation de LINX:

• sudo sh -c ‘echo « deb [trusted=yes] http://feeds.labviewmakerhub.com/debian/ binary/ » >> /etc/apt/sources.list’
• sudo apt-get update

A ce stade, la magie n’a pas encore opéré. Installons donc le paquet lvrt19 (tuto extrait du forum NI, modifié pour LabVIEW 2019) :

• sudo apt-get install -y lvrt19-schroot
• sudo mv /etc/systemd/system/multi-user.target.wants/nisysserver.service /lib/systemd/system
• sudo mv /etc/systemd/system/multi-user.target.wants/labview.service /lib/systemd/system
• sudo schroot -c labview -d /usr/lib — ln -s liblinxdevice_rpi2.so liblinxdevice.so
• sudo systemctl enable nisysserver.service
• sudo systemctl enable labview.service
• sudo systemctl start nisysserver.service
• sudo systemctl start labview.service

Vérification de l’installation avec LabVIEW 2019

Avant d’aller plus loin, nous allons vérifier la bonne installation du runtime 2019 sur le Raspberry Pi.

Créons un nouveau projet LabVIEW vide et ajoutons une cible temps réelle compatible (cRIO 9039 au hasard) en spécifiant l’adresse IP du Raspberry Pi.

Ensuite, nous connectons le projet à la cible: clic droit sur la cible -> Connect.

LabVIEW déploie le projet et vérifie la connexion à la cible.

Comme nous avons défini la cible comme étant un compact RIO, LabVIEW cherche automatiquement à détecter les modules d’acquisitions présents dans el châssis. Nous avons un Raspberry Pi, donc LabVIEW échoue à détecter les modules, mais pas de panique, tout est normal.On continue la procédure en écrivant un petit code de test qui renvoie la version de LabVIEW et la version du système :

Confirmation du fonctionnement (ctrl + R), après déploiement et exécution, nous voyons la version 2019 et la version de l’OS (ici Linux raspberry 1.19.97) :

Vous trouverez le projet de test ici : test.zip

Ajout de la cible Raspberry Pi dans LabVIEW 2019

Pour ajouter le Raspberry Pi comme cible de déploiement dans LabVIEW, il faut ajouter des Providers. Ils sont fournis dans le paquet d’installation VIPM de LINX. Il est possible de récupérer l’archive zip intéressante en décompressant le fichier .vip ou en la téléchargeant ici : InstallProviders.zip

Quittez LabVIEW, décompressez cette archive et lancez la commande suivante :

• UpdateLinxProvider.bat « C:\Program Files (x86)\National Instruments\LabVIEW 2019 »

Une fois installé, le Raspberry Pi apparait dans la liste des cibles disponibles :

Conclusion

En attendant la sortie officielle de LabVIEW 2020 avec le support LINX inclus, il est possible de profiter d’un runtime 2019 sur un Raspberry Pi. Pour preuve, voici un pilotage moteur en CanOpen utilisant CanOpenSocket:

Cet article Le Raspberry Pi se propulse vers LabVIEW 2019 (et 2020) ! est apparu en premier sur Electronique et Informatique.

Comme je vous l’ai expliqué dans l’article précédent, il est possible de déployer une application LabVIEW dans le Raspberry Pi. Il fonctionne alors en mode autonome, sans interface utilisateur. Je vais aujourd’hui vous présenter l’une des solution qui permet de communiquer avec son programme en utilisant un simple navigateur internet: le service Web.

Principe de fonctionnement

L’exécution d’une application LabVIEW sur une cible embarquée repose sur le moteur d’exécution (Run-Time Engine). Ce moteur fournit l’environnement d’exécution de l’application. Il fournit également un serveur de débogage distant, des modules d’accès aux ressources systèmes (réseau, fichiers, interpréteur de commande, …), le Vi Server et bien d’autres choses.

Il se trouve qu’il y a également a disposition des développeurs un serveur web. Il s’agit d’un environnement d’exécution particulier qui permet d’interroger un VI via une requête HTTP.

Comme illustré sur l’image d’introduction, ce serveur Web est dissocié de l’application principale. Cependant, il est possible de communiquer avec elle en utilisant le Vi Server ou d’autres mécanismes. Dans l’exemple qui va suivre, j’utiliserai des variables globales pour échanger de simples valeurs courantes.

Créer un Service Web

Pour créer un service Web sur une cible LabVIEW (PC ou embarquée), il suffit de faire un clic droit sur cette dernière et de choisir Nouveau > Service Web.

Un nouvel objet apparait alors dans le projet. Il contient deux sous sections, Ressources Web et VI de Démarrage. Nous nous intéresserons exclusivement à la première.

Ce service Web va servir de point d’entrée pour les requêtes HTTP. On va maintenant ajouter de nouvelles ressources. Chaque ressource sera liée d’une part à une URL, d’autre part à un VI.

Pour ajouter une ressource, il suffit là encore de faire un clic droit sur l’objet Ressources Web, puis Nouveau VI. Chaque nouveau VI sera lié à une URL. Il est également possible d’ajouter une Ressource Web. Ces ressources permettent simplement de structurer le service Web (un peu comme des dossiers pour un serveur Apache). Il faudra alors spécifier le nom de la ressource Web dans l’URL.

Pour chaque VI, il est possible de définir le type de requête HTTP associé: GET, POST, PUT ou DELETE. Cela permet par exemple de développer des API REST.

De manière générale, le VI sera accessible par l’URL suivante:

http://xxx.xxx.xxx.xxx:8001/RessourcesWeb/NomDuVi

Formater une réponse HTTP

Les VI ajoutés dans un Service Web sont exécutés dès qu’une requête HTTP est reçue sur l’URL associée. Voyons maintenant le type de code que peut contenir une ressource Web, et surtout comment formater la réponse HTTP.

1 – Formatage automatique

Pour un simple échange de valeurs courantes, il est possible de déléguer à LabVIEW la création de la réponse. Pour cela, il suffit de câbler les données à envoyer sur le terminal du VI.

Le diagramme du VI est lui chargé d’élaborer les données à transférer. Dans mon cas, je remonte simplement trois mesures. Le VI lit donc simplement trois variables globales et les envoie dans des indicateurs.

Le code source pourrait être bien plus complexe, par exemple en réalisant des calculs, ou en interprétant la requête HTTP. Gardez cependant une chose à l’esprit: ce VI est exécuté pour chaque requête. Plus il est long, plus la réponse sera longue à obtenir…

Mais comment LabVIEW envoie les données ?

Et bien, on peut choisir ! En faisant un clic droit sur le Service Web dans le projet puis en allant dans Propriétés on obtient tous les paramètres voulus dans la section HTTP Method VI Settings:

Les paramètres sont réglés VI par VI.

La première sous section correspond à la mise en forme de l’URL d’accès et au type de requête attendu.

La deuxième sous section permet de configurer la réponse HTTP.

Par défaut, le VI est configuré pour une sortie sur Terminaux avec un format HTML. Pour faire un formatage automatique, il faut impérativement choisir une sortie sur Terminal.

LabVIEW va prendre tous les terminaux du VI et mettre leurs valeurs dans une table HTML. Voici la page affichée par un navigateur Web pour mon VI simpliste:

<html>
    <body>
        <h1>URL: /WebService/RawData/HTTPMethod_Html</h1>
        <h2>Output Terminals</h2>
        <table  border=1.0>
            <tr>
                <th>Terminal Name</th>
                <th>Terminal Value</th>
            </tr>
            <tr>
                <td>Temperature</td>
                <td>25.32916641235352</td>
            </tr>
            <tr>
                <td>Hygrometrie</td>
                <td>30.240014152</td>
            </tr>
            <tr>
                <td>Pression</td>
                <td>907.505615234375</td>
            </tr>
        </table>
    </body>
</html>

Les autres formats de sortie sont les suivants:

• XML

<Response>
    <Terminal>
        <Name>Temperature</Name>
        <Value>25.375</Value>
    </Terminal>
    <Terminal>
        <Name>Hygrometrie</Name>
        <Value>30.10982604800001</Value>
    </Terminal>
    <Terminal>
        <Name>Pression</Name>
        <Value>907.39013671875</Value>
    </Terminal>
</Response>

• JSON

{
    "Temperature":25.39583396911621,
    "Hygrometrie":30.247509352,
    "Pression":907.404296875
}

• Texte brut

Temperature=25.46249961853027
Hygrometrie=30.04304245000001
Pression=907.55322265625

La seule précaution à prendre pour ce type de Service Web est de ne pas utiliser de caractères accentués dans les étiquettes des terminaux.

Bien que LabVIEW renvoie du HTML par défaut, il est cependant préférable de se cantonner au XML ou au JSON, bien que le XML généré par LabVIEW soit assez mal organisé (requête XPath complexes à cause du manque d’utilisation de tags).

2 – Formatage manuel

Avec ce mode de formatage, il est possible de fabriquer par programme la réponse HTTP. Pour passer en formatage manuel, il faut choir une sortie de type Stream dans la fenêtre de propriétés du Service Web. Le diagramme du VI est un peu plus complexe: on utilise la sous palette Web Service de la palette Connectivity pour fabriquer toute la réponse HTTP:

• Code de la réponse
• type MIME
• Contenu
• …

Il devient alors possible de générer du code HTML plus évolué, d’ajouter du style CSS, d’envoyer des images, … Pour l’exemple, je me suis contenté d’une feuille HTML de base:

<!DOCTYPE html>
<html>
    <body>
        <h1>Température</h1><p>25.5 °C</p>
        <h1>Pression</h1><p>907.6 hPa</p>
        <h1>Hygrométrie</h1><p>30.2 %HR</p>
    </body>
</html>

Ce mode de création de la réponse HTTP permet par exemple de générer un code XML mieux organisé que celui de base.

Déploiement

Pour déployer un service Web en source, il suffit de faire un clic droit sur ce dernier et de choisir Démarrer. Cependant, il semble y avoir un problème avec LINX: quelques fois, il y a une erreur au déploiement (LabVIEW ne trouve pas le serveur web et échoue à démarrer l’application). Du coup, je préfère tester mes services Web directement en compilant mon application. Pour cela, il convient de modifier les spécifications de construction de l’application:

Il faut alors choisir les services Web à inclure dans l’application, recompiler l’ensemble, déployer et redémarrer le Raspberry Pi.

Conclusion

Les services Web sont une solution relativement simple pour communiquer avec une application LabVIEW.

Ils peuvent être utilisés pour surveiller une application ou consulter des valeurs courantes.

Ils peuvent également servir pour communiquer avec un système distant, tel qu’une base de données, une application Android, un site Web, … Les applications sont nombreuses et puissantes. Je n’ai qu’effleuré l’aspect « Service » pour me concentrer sur l’implémentation sous LabVIEW.

Si le sujet vous intéresse, vous trouverez plus d’informations sur OpenClassRoom.

La seule contrainte liée au formatage automatique est d’éviter les caractères ASCII étendus.

Enfin, il faut garder à l’esprit que les VI des services Web sont exécutés de manière asynchrone, et par conséquent ont un impacte important et non prédictible sur les performances globales du système.

Cet article LINX 3.0 – Création d’un Service Web avec LabVIEW est apparu en premier sur Electronique et Informatique.

Cependant, LabVIEW permet de faire bien plus. Une application embarquée va être amenée à fonctionner de manière autonome, dans un lieux potentiellement inaccessible. Il est alors indispensable que l’application soit téléchargée dans la cible et démarre automatiquement.

Déployer son application en mode autonome

Une fois le programme mis au point, il est possible de le déployer à demeure dans la cible. Un petit peu comme on flasherait une programme dans un microcontrôleur. Pour ce faire, il faut créer une spécification de construction de type Real Time Application (bien que cette dernière n’ai pas le déterminisme d’une vrai application RT, du fait des limitations du Raspberry Pi).

Un assistant de configuration s’ouvre. La première page vous permet de nommer votre application et de choisir dans quel dossier elle sera construite.

La section la plus importante est la suivante: Source Files. Elle permet entre autre de choisir le VI de démarrage. Il s’agit du premier VI lancé par le Run-Time au démarrage de l’application. Autrement dit, il s’agit du Main de l’application.

Une autre page intéressant est celle concernant les options avancées. On y trouve notamment la possibilité de compiler l’application en mode Debug, qui permet de connecter LabVIEW à l’application compilée pour la debugguer in situ.

Une fois la spécification de construction terminée, ne cliquez pas directement sur Build, mais plutôt sur OK. Enregistrez ensuite l’intégralité du projet. En effet, la configuration de la spécification de construction est sauvée dans le fichier .lvproj lui-même. La spécification apparait alors dans le projet. Il est possible de la compiler via le menu du clic droit en choisissant Build.

Une fenêtre faisant apparaitre la progression de la compilation s’ouvre:

Quand la compilation est terminée, cliquer sur Done.

A ce stade, l’application n’est pas encore dans le Raspberry Pi. LabVIEW a juste généré le fichier binaire exécutable. Pour télécharger l’application dans la cible et faire en sorte qu’elle démarre automatiquement à la mise sous tension, il fait repasser par le menu du clic droit et choisir Run as startup.

LabVIEW télécharge alors le binaire dans le Raspberry Pi et configure ce dernier pour le lancer au démarrage. Un popup apparait alors pour vous proposer de redémarrer la cible. Acceptez et votre application devrait se lancer an quelques dizaines de secondes.

Conclusion

Une application compilée sera plus économe en ressources systèmes. Elle peut démarrer automatiquement, sans le recours à LabVIEW pour lancer le code. Cependant, il n’y a plus d’interface graphique, donc certaines fonctions sont inopérantes: les popups, les message d’erreurs, … Il faut donc trouver d’autres solutions pour communiquer, mais cela sera l’objet d’un autre article.

Bon dév à tous !

Cet article LINX 3.0 – Déploiement d’une application LabVIEW sur Raspberry Pi est apparu en premier sur Electronique et Informatique.

Ce toolkit permet donc de développer une application avec LabVIEW, de la compiler et de la télécharger dans la cible pour lui permettre de fonctionner de manière autonome!

Le Contexte

National Instruments, la société qui développe et maintient l’environnement LabVIEW, a récemment choisi une distribution Linux RT (Real Time) pour animer ses systèmes embarqués (cDAQ, cRIO, PXI…). Elle supporte actuellement les plateformes Zynq de Xillinx (ARMv7) et Intel Atom (x86). Or il se trouve que les Raspberry Pi 2 et 3 ainsi que la BeagleBone ont un jeu d’instruction ARMv7… Partant de ce postula, un portage du noyau d’exécution LabVIEW (Run-Time Engine) sur ces plateforme n’était qu’une question de temps.

C’est maintenant chose faite ! Une chose manque cependant à l’appel: le support du serveur graphique.

En effet, depuis l’arrivée des cRIO 903x, NI propose l’utilisation d’un serveur XFCE pour ajouter une interface graphique aux applications embarquées. Ceci n’est à ce jour pas encore supporté par LINX.

ATTENTION: Le Raspberry Pi N’EST PAS A CE JOUR UNE CIBLE LabVIEW TEMPS RÉEL!

LINX: Le toolkit LabVIEW

Digilent, une société acquise par National Instruments, a développé LINX, une solutions permettant le fonctionnement d’application LabVIEW sur certaines cibles telles que les Arduino ou Raspberry Pi.

Depuis la version 3.0 de LINX, la cible (Raspberry Pi ou Beagle Board) devient autonome!

L’idée de Digilent est brillante de simplicité: installer le Run-Time LabVIEW RT dans un environnement chroot à l’intérieur de l’OS d’origine. Sur le Raspberry Pi, Digilent recommande l’utilisation de Raspbian Jessy.

Configuré pour booter en mode console sans environnement graphique, l’application développée avec LINX 3.0 démarre en quelques dizaines de secondes à partir de la mise sous tension; les performances sont donc au rendez-vous!

Les premières versions fonctionnaient en mode supervisé:  un daemon installé sur la cible recevait des commandes d’un PC qui exécutait le VI LabVIEW. Une perte de communication entre les deux et le programme se plantait.

Mise en place de l’environnement

Le première chose à faire est d’installer LabVIEW 2014 SP1 32bits. Une licence Home Bundle est disponible aux alentour de 50€ à destination des makers et autres amateurs. Digilent propose également des packs LabVIEW Physical Computing à moins de 100€ incluant la licence et la cible. Je vous recommande particulièrement d’installer la version anglaise de LabVIEW, l’essentiel des communautés d’utilisateurs faisant usage du jargon anglophone. Prévoir quelques Go d’espace disque, LabVIEW est relativement volumineux (mon installation fait plus de 4Go sans compter les modules additionnels), ainsi qu’une connexion Internet pour l’activation.

Une fois LabVIEW correctement installé et activé, il faut lui ajouter LINX 3.0. Pour cela, rien de plus facile: VIPM est là pour ça!

Mais qu’est donc? VIPM (VI Package Manager) est un outils développé par JKI pour donner accès à une bibliothèque de toolkits et plugins pour LabVIEW. Certains sont gratuits, voir Open Source (tels que l’OpenG ou encore LINX), d’autres sont soumis à licence. Du coup, pour installer LINX, il suffit de lancer VIPM, chercher LINX dans la liste des modules et cliquer sur Installer…

Pour vérifier la bonne installation de LINX, lancer LabVIEW et ouvrir le menu Outils. Vérifier la présence d’un sous menu MakerHub:

Installation de la cible

Je vais détailler ici l’installation de LINX 3.0 sur Raspberry Pi 2 ou 3, n’ayant pas de BeagleBone sous le coude… Pour ces dernières, je vous propose de regarder les tutoriaux vidéos de Digilent.

Commençons par installer Raspbian Jessy Lite sur la carte SD du Raspberry. Un petit coup de dd sous Linux ou de Win32DiskImager sous Windows et le tour est joué. Pour configurer le Raspberry, un petit sudo raspi-config. Il est utile d’activer l’UART, le SPI et L’I2C ainsi que d’étendre la partition système à toute la carte SD. Pour continuer, il va également falloir configurer le réseau: Ethernet pour le Pi 2, possiblement le WiFi pour le Pi 3. Notez bien l’adresse IP du Raspberry, nous en aurons besoin.

Retour sous LabVIEW. Aller dans le menu Outils > MakerHub > LINX > LINX Target Configuration…

Renseigner les champs comme suit:

Hostname or IP : xxx.xxx.xxx.xxx (l’adresse IP du Raspberry Pi sur le LAN)

Username: pi

Password: raspberry

Et cliquer sur Connect puis sur l’onglet Install Software.

Un simple appuie sur le bouton Install et le tour est joué. L’utilitaire d’installation se connecte sur les dépôts d’installation de NI pour récupérer le Run-Time et l’installer dans l’environnement chroot.

Programmer la cible avec LabVIEW

Pour attaquer une cible embarquée avec LabVIEW, il faut commencer par créer un projet. Pour l’exemple, je vais créer un projet vide, mais rien n’empêche de partir d’un modèle de projet. Pour ajouter le Raspberry au projet, faire un clic droit sur la racine du projet (et non sur My Computer, comme souvent commis par erreur…) et ajouter une nouvelle cible:

Spécifier l’adresse IP de la cible et choisir son type: LINX > Raspberry Pi / BeagleBone. Une nouvelle cible est ajoutée au projet. Tout les VI placés dans cette cible s’exécuteront sur celle-ci et non sur l’ordinateur.

Quand on édite un VI, on peut savoir sur quelle cible il s’exécute lorsque l’on clique sur la flèche d’exécution. Il suffit pour cela de regarder en bas à gauche de la fenêtre (face avant ou diagramme): un  champ texte précise le nom de la cible et permet de modifier ponctuellement celle-ci.

Par exemple, on développe un algorithme de calcul sur le Raspberry et l’on aimerait le tester rapidement: rien de plus simple! Un clic droit sur le champ texte et on choisi My Computer. LabVIEW va alors exécuter le code sur le PC plutôt que sur le Raspberry. Les conditions d’exécution sont différentes, mais on économise la phase de compilation et de déploiement qui peut prendre un peu de temps.

Les fonctions spécifiques au module LINX sont accessibles par la palette MakerHub. On y retrouve toute l’API: accès aux E/S tout ou rien, aux modules UART/SPI/I2C ainsi que tout un tas de drivers pour capteurs et afficheurs. On y trouve également une Toolbox qui propose des fonctions de support utiles.

L’accès à l’API LINX s’effectue de la manière suivante:

1. Ouverture d’une référence en mode Local I/O
2. Initialisation des différents sous modules (typiquement le SPI)
3. Accès aux E/S, fonctionnement nominal de l’application
4. Fermeture des sous modules
5. Fermeture de la référence principale

Voici un exemple de communication sur bus SPI.

• Le premier VI ouvre une référence vers l’API LINX. Elle est nécessaire à l’accès aux ressources de la cible.
• Le deuxième VI initialise le module SPI 0
• Le troisième VI configure le module SPI: vitesse de communication, ordre des bits, mode de fonctionnement de l’horloge…
• Le quatrième VI écrit et lit des trames sur le bus
• Le cinquième VI ferme et détruit la référence à l’API LINX.

Il n’est pas nécessaire de fermer l’accès au module SPI.

Lancement du programme

Pour exécuter le programme, il y a deux méthode:

• En source
• En exécutable

La première solution est à privilégier pour la phase de développement. Il suffit simplement de cliquer sur la flèche d’exécution. LabVIEW compile le programme, le télécharge sur la cible et connecte la face avant restée sur le PC sur le Run-Time de la cible. Ainsi, on peut interagir avec le programme, utiliser les outils de debug usuels (sondes, loupiote, points d’arrêts…).

Cette solution est très pratique, mais gourmande en ressources sur la cible. En effet, une communication réseau permanente est établie entre la cible et le PC. en outre, le programme ne peut être lancé qu’à partir de LabVIEW. Cela signifie qu’il faut rouvrir les sources du programme, compiler, télécharger et exécuter celui-ci à partir de LabVIEW à chaque mise sous tension de la cible.

Conclusion

LINX 3.0 représente une petite révolution dans le monde National Instruments. Il devient en effet possible pour tout un chacun de développer une application embarquée avec LabVIEW pour un budget accessible. En effet, la licence Home Bundle est à 50€ et les Raspberry Pi oscillent entre 30 et 40€. Tout le monde a désormais accès à l’ergonomie du langage G et à la puissance de l’environnement LabVIEW.

A bientôt pour de plus amples informations sur le déploiement d’une application LabVIEW sur le Raspberry Pi.

Lancez-vous !

[EDIT du 03/12/2017] – Problème lié au déploiement de LINX sur le Raspberry Pi

Lors de l’installation du LINX sur un Raspberry Pi, il se peut que l’une des étapes ne se déroule pas complètement, probablement à cause de certains droits d’accès qui auraient changés dans la dernière version de Raspbian (Stretch au moment où j’écris ces lignes).

Le symptôme est le suivant: au déploiement d’un programme faisant appel à la bibliothèque LINX, un message d’erreur survient:

« LMH-LINX.lvlib:Local IO.lvlib:Load Device Channels.vi loaded with errors on the target and was closed. »

La cause probable est la suivante :

LINX installe une bibliothèque sur le Raspberry Pi : /usr/lib/liblinxdevice_rpi2.so

Cependant, pour assurer la compatibilité avec les BeagleBone Black, une deuxième bibliothèque est installée : /usr/lib/liblinxdevice_bbb.so

Le choix de la bonne bibliothèque est fait grâce à la création d’un lien symbolique: liblinxdevice.so -> ./liblinxdevice_rpi2.so. La coutume est courante sous Linux, mais dans notre cas précis le lien peut ne pas exister.

Pour s’assurer de la bonne installation de la bibliothèque, commencez par ouvrir un terminal SSH (soit dit en passant, Windows 10 est nativement doté d’un shell Linux…).

Ouvrir ensuite un accès à l’environnement chroot d’exécution LabVIEW: $ sudo schroot --run-session -c lv

Naviguer dans le dossier /usr/lib : # cd /usr/lib

Lister le contenu du dossier : # ls -l | grep linx

S’il n’y a que deux fichiers (le bbb et le rpi2), le problème de déploient du code viens de là.

Pour corriger le problème, il suffit de recréer le lien symbolique : # ln -s ./liblinxdevice_rpi2.so ./liblinxdevice.so

J’ai trouvé cette solution en parcourant le forum LabVIEW MakerHub (page d’origine). Nous la devons à Kryptman. Je me suis contenté de la tester et de la traduire en Français. Merci à lui.

Cet article LINX 3.0 – Ou comment programmer un Raspberry Pi avec LabVIEW est apparu en premier sur Electronique et Informatique.