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

Exemple d’IHM ARCALE

Voici un exemple d’IHM réalisée par ARCALE, d’autres suivront bientôt…

 

 

N’oubliez pas que l’IHM est la partie visible du logiciel, elle doit donc être travaillée…

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:

NI Days 2012

Mardi avait lieu le salon Ni Days, au CNIT à Paris, c’était l’occasion de rencontrer beaucoup de gens du domaine du test et de la mesure. Arcale était bien représenté avec une dizaine de développeurs et 4 commerciaux. N’hésitez pas à participer à la prochaine édition du salon si vous n’avez pas pu venir cette année.

 

 

Premier Poste

Bonjour,

Un petit mot pour informer ce qui suivent ce blog, je rejoindrais l’équipe d’ARCALE le 12 Septembre. J’ai fait ce choix par rapport à l’expertise technique d’ARCALE et mon souhait de continuer sur les technologies Nation Instruments notamment LabVIEW et TestStand. Ce sera mon premier poste: Ingénieur Test & Mesure

TestStand

Bonjour,

J’ai fait une petite vidéo de présentation sur quelques points de mon stage de fin d’études. Vous pourrez apercevoir ma palette de VIs que j’ai créé, et des IHM en actions notamment le mode production (IHM LabVIEW faisant tourner TestStand), un viewer de base de données PostGreSQL, et une interface custom d’édition de séquences TestStand.

 

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.