Centrale d’acquisition de données embarquée dans une rame de métro

Embarqué sous un train d’une rame de métro de Paris, le système d’acquisition doit transmettre des données sans fil, dans un environnement ou les occultations de réseau sont fréquentes.

Retrouvez l’article complet ici

Command Pattern

Depuis quelques années maintenant LabVIEW permet de programmer des application « Orienté Objet » que l’on appelle LVOOP (LabVIEW Object Oriented Programming)

Ce design pattern se présente sous la forme d’une architecture de type producteur consommateur, c’est-à-dire qu’une boucle produit des données (classe enfant de la classe Actor_Generic) et les empile dans une file d’attente. La boucle consommatrice dépile la file d’attente et envoie l’élément lu vers un VI nommé « Core » qui est un VI de la classe parent Actor_Generic qui en fonction de la classe enfant reçue appel le VI « Core » de cette classe (c’est le dynamic dispatch).

.

Grâce à cette architecture simple à mettre en place, nous avons une application facilement évolutive on peut facilement modifier une classe sans impacter le fonctionnement global de l’application.

Dans cet exemple nous avons deux types de messages empilés dans la file d’attente un message « Stop » qui appel le VI Core de la classe Stop qui ne fait que passer une constante Vrai pour stopper la boucle consommatrice. Et le second type de message appelés ici Actor qui exécutent une tâche particulière, ici renvoyer un signal sinus ou carré en fonction des paramètres d’entré.

Nous allons maintenant présenté quelques sections du code:

Sinus:

On récupère les valeurs de l’amplitude et de la fréquence pour les passer à des VIs dits « accesseurs » ( ils permettent juste d’écrire une valeur dans la classe comme pour un cluster), évidemment LabVIEW dispose d’une méthode de génération automatique des accesseurs afin que la tâche ne soit pas fastidieuse… Les données sont donc stockées dans la classe Actor_Sinus qui est passée à la file d’attente. Dans la boucle consommatrice on va récupérer cette classe (enfant de Actor_Generic) ce qui permet de rediriger les données vers le bon VI.

Carré:

Comme pour la fonction sinus

Le dynamic dispatch permet d’accéder à différents VI de manière dynamique (cela revient à créer une machine d’état)

Présentation de l’architecture dans le projet LabVIEW:

Design Pattern: Producteur/Consommateur

Bonjour,

Dans ce nouvel article je vais vous présenter un modèle de conception simple et courant pour l’acquisition de données. Grâce à cet article les débutants pourront créer des applications plus efficaces, plus simple, et plus robustes sans se creuser la tête…

Le principe est simple, si je dois faire de l’acquisition de données, mais que je veux traiter ou afficher ces données en différé ou à un cadencement plus lent, soit par ce que l’acquisition est trop rapide pour l’oeuil humain, ou trop gourmande pour l’IHM en terme de ressources PC, il est intéressant d’utiliser une architecture en producteur/consommateur. Pour cela on utilise deux threads en parallèle (deux boucles while), une appelée « producteur » elle produit les données et les empile dans une file d’attente (voir articles précédents) et l’autre boucle appelée « consommateur » dépile les éléments pour les afficher ou les traiter etc…

Dans l’exemple ci-dessous, l’architecture est divisée en 6 sections:

1-Créer une file d’attente (pour y placer nos données)

2-Dans le producteur:Créer des données (ici un nombre aléatoire, mais typiquement on placera une tâche DAQmx)

3-Dans le producteur: On empile la donnée dans la file d’attente

4-Dans le consommateur: on dépile une donnée et on l’affiche (on peut rajouter un code de traitement, d’enregistrement, etc..)

5-On détruit la file d’attente

6-Dans le consommateur: on a câblé le fils d’erreur à la condition d’arrêt, cette technique assez classique mérite une petite explication, quand la boucle productrice est arrêtée, la file d’attente est détruite, donc quand il n’y a plus d’éléments à dépiler dans le consommateur, la fonction va retourner une erreur, et c’est cette erreur qui arrête la boucle consommatrice. notez que si vous ne souhaitez pas arreter votre programme sur erreur il est possible de mettre en œuvre des solutions plus ou moins complexes.

Bon code à tous!

PS: je pense faire un prochain article sur l’acquisition de données car c’est très utilisé et souvent assez laborieusement par les débutants, et comme le but de ce blog est de les aider…

Design pattern: machine d’état avec file d’attente

Bonjour,

Nous avons vu dans des articles précédents la file d’attente (FIFO), ainsi que le design pattern de base, la machine d’état. Nous allons donc les combiner pour avoir un design pattern plus puissant. La file d’attente permet de stocker les différents états sans les perdre par exemple si un état empile plusieurs actions successives a effectuer. Pour cela on créé une file d’attente, on empile l’état initialisation (afin de rentrer dans le code d’initialisation au début du programme), ensuite dans une boucle while les éléments (ordres) sont dépilés, une structure condition permet de choisir le code a exécuter. le code contiens une fonction pour empiler l’ordre ou les ordres permettant de choisir le code a exécuter.

Dans cet exemple, j’ai choisi de mettre mes commandes sous le format d’une chaine de caractère, mais on pourrait utiliser un énum ou un cluster…

Bon code à tous!

Synchonisation et communication

Quelques notions avancées pour ceux qui préparent le CLAD. Le but de cet article est juste de montrer que ces notions existent et vous donne juste ce qu’il faut pour passer la certification, mais il est conseillé de creuser la question pour les utiliser dans des architectures avancées.

FIFO

Aujourd’hui j’aimerai introduire une notion sur ce blog, notion que je commence à beaucoup utiliser. Les queues, et donc la plus utilisées, la FIFO (First In First Out). Le principe est assez simple on crée une file d’attente (on peut en définir la profondeur), on viens écrire un élément dans la file (une chaine de caractères, un énum (par exemple l’état d’une machine d’état), un cluster, un variant, des numériques…) on peut ensuite « dépiler » un ou plusieurs éléments pour les traiter ensuite, dans une autre boucle par exemple, mais aussi dans un autre VI qui tourne en parallèle. Il suffit ensuite de détruire la file d’attente en fin de programme.

Les files d’attentes peut aussi être utilisées pour passer des données vers TestStand, file d’attentes qui existent aussi dans TestStand pour passer des données entre différentes séquences par exemple(elles fonctionnent de manière analogue à celles de LabVIEW).

Notifications

On peut utiliser un notificateur pour synchroniser des exécutions, un notificateur ne peut faire passer qu’un seul élément contrairement à une file d’attente. On l’utilise par exemple pour passer un booléen pour signaler qu’une action est terminée dans un autre thread et qu’il faut donc terminer une autre exécution.

Sémaphores

Un sémaphore est utilisé pour verrouiller une ressource afin que plusieurs tâches ne puissent accéder à une ressource simultanément, et donc éviter les « races conditions » deux tâches ne doivent pas écrire en même temps dans une variable.

 

Variables locales

Une variable locale permet de passer une donnée au sein d’un même VI (plus généralement au sein d’une même séquence dans TestStand). Cela permet par exemple de contrôler deux threads qui tournent en parallèle dans une exécution.

Variables partagées

Les variables partagées sont des variables stockées sur un serveur , et permettent de partager des données entre plusieurs VI.

CLAD

National Instruments propose 3 niveaux de formation pour LAbVIEW:

-Le CLAD Certified LabVIEW Associate Developer

-Le CLD Certified LabVIEW  Developer

-Le CLA Certified LabVIEW Architect

 

Je viens de recevoir mon certificat pour le CLAD… je voulais vous faire partager ma joie, et annoncer que le blog à dépassé les 500 visiteurs depuis sa création, j’espère qu’il continuera à être consulté. Merci à ceux qui passent dessus.

 

Dans les prochains articles je parlerais de TestSTAND et de mon parcours pour accéder au prochain niveau de certification, le CLD.

 

Microscope acoustique

Pour mon projet tuteuré j’ai travaillé sur la microscopie acoustique. Le principe consiste à envoyer un signal RF sur un piézoélectrique, il se déforme, ce qui crée une onde (le piézo est collé sur un barreau de silicium) cette onde se propage dans le barreau jusqu’à une lentille acoustique (analogue à l’optique (Snell Descartes)) pour focaliser l’onde à l’endroit voulu. Par réflexion on obtient un signal de faible amplitude que l’on analyse (effet inverse du piézoélectrique il sert de traducteur).

Cette méthode est utilisée pour le contrôle non destructif des matériaux (mise en évidence de phénomènes de délamination par exemple) mais aussi il peut servir à déterminer le module d’Young d’un matériau avec une précision supérieure aux méthodes de traction mécanique.

Je disposait d’un châssis PXI 1062Q, d’un contrôleur 8108, d’une carte IF RIO 5641R, d’un circulateur et d’un traducteur piézoélectrique:

Voici une copie d’écran du logiciel réalisé:

Zoom sur l'écho de lentille

On observe un signal large et modulé de forte amplitude c’est le signal d’exitation du piézo, le pic au centre est le premier écho de lentille, placé à 34microsecondes du signal source.

 

A cause des modulations ajoutées par la carte qui pour le moment n’a que le driver en mode quadrature et pas interpolation… le microscope n’est pas encore exploitable. J’ai aussi travaillé sur une méthode d’intercorrélation pour augmenter la résolution du microscope.

Point d’inflexion

Sur un forum, j’ai trouvé une question qui peut intéresser d’autres gens, il s’agissait de savoir calculer un point d’inflexion avec LabVIEW. J’ai donc fait un programme qui permet de calculer les points d’inflexion d’une fonction. Le point d’inflexion est le point d’une courbe ou la dérivée seconde s’annule et change de signe. Le programme réalisé n’est pas très optimisé mais je ne voulais pas mettre de sous VI afin de rendre mon code lisible sur une seule image. Dans un premier temps j’ai créé une fonction, Arctangeante, décalée de (1 ;1), puis j’ai calculé la dérivée seconde, et trouvé le point d’inflexion (sa marche pour plusieurs). Vous noterez que la dérivée seconde a des pics au début et à la fin, ceci est du à la méthode d’intégration numérique, et n’a pas de réalité physique. Ce programme utilise aussi quelques fonctions de base sur les tableaux ce qui le rend intéressant, de plus on pourrait éliminer les points « défectueux » de la courbe de la dérivée seconde (sa serait plus propre).

Ce diaporama nécessite JavaScript.

Exemples de programmes

Voici trois exemples de programmes/interfaces:

-Traitement du signal: filtrage, et FFT, détection de pic (à partir du cours LabVIEW in 6hours)

-Remplissage d’une cuve à partir de trois autres cuves

-Convertisseur de degrés Celsius en degrés Farenheit ou en Kelvin (très inspiré d’un cours récupéré sur internet)

 

 

Ce diaporama nécessite JavaScript.

Traitement d’images

Dans cet article je parlerais de traitement d’image basique en LabVIEW. Le programme que j’ai créé permet de créer une image, d’ouvrir une image sélectionnée par l’utilisateur, de l’afficher, d’obtenir les valeurs des pixels (en U32), puis de lui faire effectuer une rotation de 90 degrés. C’est très classique, mais sa permet de comprendre les bases de la vision en LabVIEW, et d’ensuite choisir ses propres fonctions de traitement d’images.

 

Ce diaporama nécessite JavaScript.