Curriculum and Labs for Engineering Education

cancel
Showing results for 
Search instead for 
Did you mean: 

Darwin appliqué à LabVIEW : l’évolution de la gestion des données

Bonjour à tous, je livre ma présentation du LUGE 3.0 « Darwin appliqué à LabVIEW : l’évolution de la gestion des données » ou « Evoluer pour s’adapter »

PS : Il existe une version Anglaise plus complétehttps://decibel.ni.com/content/servlet/JiveServlet/download/38-113555/Darwin%20applied%20to%20LabVIE..., que vous pouvez télécharger Darwin applied to LabVIEW V2.2.pdf. Darwin applied to LabVIEW:  The evolution of the data management

Elle traite de l’évolution du concept « mémorisation » du flux de données, avec Contrôle vers indicateur -Locale -Globale -FGV -AE –SEQ -DVR -OOP –SM –QDMH.

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

2.png

1.png

Pour ceux qui liront la présentation, la technique SEQ n’est pas traité. La prochaine fois, ou pour les plus curieux.

Luc Desruelle | avatar_ld.gif | Voir mon profil

Auteur livre LabVIEW "Programmation et applications" édition Dunod, jusqu'au niveau pour l'examen CL...


CLA : Certified LabVIEW Architect / Certifié Architecte LabVIEW
CLD : Certified LabVIEW Developer / Certifié Développeur LabVIEW

Contact

A+

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

Comments
Solutest-Brice_Blanc
Member
Member
on

Merci Luc! J'osais pas te la demander. Du coup j'ai acheté ton bouquin! Mais ta présentation va tout de meme un peu plus loin, notament avec ce qui m'interesse (DVR et OOP by ref). A bientot !

La solution test et mesure
Desruelle_luc
Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast
on

salut Brice,

Il était peut-être question de proposer cette présentation à NIDays, mais elle n’a pas été retenue. Pas assez originale. Je plaisante, évidement,… elle n’était pas assez technique (elle ne parle pas de SEQ, pas de SEQ pas de présentation). 🙂

merci beaucoup pour ton commentaire. Très sympa. J’ai eu des bons retours pour cette petite présentation. (Je reçois souvent des messages privés, les personnes n’osant pas laisser un commentaire.)

Merci aussi pour le livre, je vais te faire une belle dédicace. Au départ j’ai commencé cette présentation pour mon blog. https://decibel.ni.com/content/blogs/Luc_Desruelle

Elle a directement inspiré le livre. Pour la DVR, il y a plus d’explication dans le livre mais c’est vrai que je n’y aborde pas la programmation OOP by Ref. Pour faire un peu de pub, dans le chapitre en question, le N°3, j’aborde avec détails les règles d’architecture et les modèles de conceptions les plus utilisés. J’analyse et j’explique notamment les techniques nécessaires pour un CLD.

En plus avec le livre tu as accès à l’ensemble du code téléchargeable gratuitement.

Sinon as-tu remarqué le nom des vi’s utilisés dans les modèles de conceptions ? à partir de la page 229 ? les VI’s d’un driver d’instrument en page 312…

A+

Luc

PS : je suis sûr que tu es dans le brouillard…

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

Nicolas_Bats
Member
Member
on

Bonjour Luc,

Comme demandé, voici les quelques questions sur lesquelles on a eu l'occasion d'échanger et qui développent les notions d’OOP.

Utilisation de DVR ou de SQE :

- Quelle technique préférez / utilisez-vous chez Mesulog ?

- Bilan comparatif entre les 2 (performance, usabilité ...).

Comparaison des performances OOP by Value / by Reference :

- Avez-vous un retour à faire sur les performances entre programmation OOP by value et by reference ?

- A l'heure actuelle la RAM ne coûte pas très cher cependant pour certaines applications on peut être amené à essayer de l'optimiser. Sur un projet j'ai été étonné de constater que les appels aux DVR (pas seulement pour l'OOP d'ailleurs) étaient extrêmement lents (rapport de 1000) par rapport à une programmation by value. Je pensais qu'il s'agissait d'un "simple pointeur" mémoire mais visiblement non (temps de lock/délock ? autre chose ?).

Encapsulation des DVR par une classe tierce ou transport de la référence explicite :

- La réponse dépend probablement des habitudes de chaque développeur mais simplement pour savoir : Quelle est la philosophie chez Mesulog ?

- Comparaison des 2 techniques : usabilité, encapsulation, rapidité à coder …

A bientôt,

Nicolas

Arcale - CLA, CLED, CTD - LabVIEW 2b || !2b
Desruelle_luc
Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast
on

Merci Nicolas pour tes retours. Je trouve tes questions très intéressantes, et je suis persuadé qu’elle mérite une conversation dans la prochaine journée LUGE ou autre rencontre développeur.

Tes questions sont très techniques. Il est difficile de faire des généralités. Il est possible que « quelqu’un » me réponde « oui mais dans mon application et bien moi… ». Oui question performance (rapidité) entre un type double et tableau 4D de cluster, pas de généralité.

Utilisation de DVR ou de SQE :

SEQ (Single Element Queue) a été une méthode de programmation par référence, en utilisant une « Queue » d’un seul élément. Elle était utilisée avant l’arrivée de la DVR. Depuis elle n'est plus vraiment utilisée. Donc depuis la DVR, j’utilise les API DVR.

Même si je n'ai jamais eu de lenteur avec les DVR, la littérature ne va pas dans le sens de la rapidité, mais l'optimisation de la mémoire. J’utilise toujours la DVR pour l’optimisation mémoire et éviter les accès concurrents (Race conditions), mais sur des "grosses strucutres".

Par exemple, je ne vais pas utiliser une DVR sur une application de 20 VI's, pour partager les données d'un fichier ini (1 writer et N readers), j'utilise une FGV. Par contre pour mettre à jour les données de 100 modules d'acquisition, dans 32 process parallèles, j'utilise une DVR.

Je n’ai jamais « personnellement » constaté de lenteur sur l’accès mémoire. Sauf s’il y a concurrence sur la données (N writers) alors la DVR gère l’accès à la ressource (premier arrivé = premier servit) donc forcément il y a « une file d’attente » ! Mais c’est voulu. La question est alors « combien y a-t ’il de writers sur la variable » ?

Comparaison des performances OOP by Value / DVR:

Je n'ai pas abordé le côté performance entre DVR, et OOP by Data.

L'une est plus optimisation mémoire et l'autre méthodologie Objet. Avec un dispatch dynamique et héritage, la finalité n'est pas vraiment la même.

Comparaison des performances OOP by Value / by Ref:

Alors si je combine DVR et OOP... La rapidité n'est pas forcement là.

Même si je n'ai jamais eu de lenteur avec les DVR, la littérature ne va pas dans le sens de la rapidité, mais l'optimisation de la mémoire.

Sans tirer un théorème universel, à l'heure où la RAM ne coûte rien, une application qui utilise moins de RAM grâce à une meilleures gestion des données est plus évolutive, plus réactive, et mieux architecturée. (oui, quelqu’un a vu l’homme qui vu l’ours. mais généralement c’est comme cela).

Pour info une « grosse globale » native LabVIEW peut être 1000x plus rapide qu’une FGV. Inversement en gestion mémoire 1000 globales de type Tableau 4D vont utiliser XXX buffers de plus.

Encapsulation des DVR par une classe tierce ou transport de la reference explicite : Quelle est la philosophie chez Mesulog ?

J’ai envie de répondre « Autant que de philosophe. »

Si je me permets de reposer la question, la question est-elle ? Pour la programmation OOP par référence, utilisez-vous

  1. 1.     une classe  dont la donnée est de type « référence DVR, qui est du type de la données de travail »
  2. 2.     une classe by value (qui est du type de la donnée de travail) qui est appelée par une deuxième classe par référence (du type DVR de la classe objet by value)

Si la question est cette dernière, je préfère la 2.

Plus longue à coder, car 2 classes

Plus réutilisable, car je peux facilement réutiliser uniquement la classe by Value

LabVIEW est naturellement by value, alors je code naturellement by value, et j’encapsule ensuite une classe de gestion à l’accès par une classe by Ref (via DVR).

Si quelqu’un d’autre veut échanger sur le sujet, cela sera avec plaisir.

Je pense que nous avons un sujet pour la prochaine rencontre LUGE

A+

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

Desruelle_luc
Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast
on

salut à tous, pour les plus motivés, il existe une version en Anglais de cette présentation.

Elle est beaucoup plus technique, précise et complète.

Darwin applied to LabVIEW: The evolution of the data management

subtitle “The survival of the fittest applied to the LabVIEW Dataflow model ”.

Bonne lecture

A+ luc


 

 

banniere Luc Livre NXG Champion.png

Luc Desruelle | Mon profil | Mon blog LabVIEW | Auteur livre LabVIEW : Programmation et applications - G Web
Certified LabVIEW Architect (CLA) & Certified TestStand Developper (CTD) | LabVIEW Champion

MESULOG - LinkedIn site | NERYS - NERYS Group
| directeur CEO MESULOG
| CODIR - NERYS group

Contributors