Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Comportement - proposition

oui, il y a probablement beaucoup de (petites) choses que tu connais grâce à ta position "interne".

 

Je parle surtout des "pourquoi" ... les "comment", eux, sont en génarale accessibles via la doc publiée.

 

La connaissance des "pourquoi" doit probablement venir d'un accès aux docs concernant le compilateur lui-même.

 

La curiosité ... je n'en manque pas.

 

Les formations ... là, oui, aussi ... on apprend plus de choses en 2hrs de cours qu'en lisant 50 pages de doc.

 

il n'est pas possible de poser une question à une doc ... et une incompréhension peut tenir à peu de choses.

 

Si ton incompréhension tient au fait que ton raisonnement est trop "à côté" de la réalité ...

 

tu peux lire toutes les docs que tu veux, tu ne trouvera pas la réponse (déblocage).

 

Alors qu'en une seule question ... ton interlocuteur "sentira" de suite l'élément qui te fait défaut ... et te donnera la "clef" en 3 mots.

 

Je schématise, mais c'est un peu ça ..... d'où l'intérêt des formations !

 

 

ok Eric, curiosité native, formations directes, accès internes, esprit ouvert ... tout cela est cohérent.

 

(il me manque les éléments 2 et 3)

 

J'ajouterai personnellement un dernier élément ... qui serait de l'ordre "du milieu professionnel et  l'interactivié". (le premier entrainant quasi d'ofice le second)

 

Cela t'oblige a t'intéresser à des domaines (aspects, approches) que tu n'aurais pas forcément abordés seul.

 

 

voilou. Merci Eric.

 

 

 

 

 

 

 

0 Compliments
Message 51 sur 63
387 Visites

Je viens de relire une réponse de JB (à propos des variants)

 

à savoir:

 

Je ne voudrais pas démarrer un nouveau débat mais les variants sont très pratiques même sans recourir au descripteur de type.

Par exemple pour transmettre des données de types différents par une même queue comme cela est décrit ici ou encore ici.

 

oui, JB, je suis d'accord.

Mais dans ces exemples tu "transportes" en dur le type dans le Cluster .. qui se trouve dans un variant.

 

Cela revient un peu au même ....

On embarque le type en "clair", ou on le décode à l'arrivée (avec le descripteur)

Le constat est le même ... si tu n'as pas le type de la donnée, tu ne sais rien faire du contenu du variant.

 

Tu peux écrire des pages de code qui manipulent un variant ...

si tu dois "traiter" la donnée y contenue, tu seras bien obligé à un moment donné de la sortir du variant.

 

je veux dire quoi ?

 

Embarquer le type, ou le retrouver à l'arrivée ... c'est une "autre façon de", mais pour moi cela ne change pas grand chose.

 

oui, d'accord ... tu n'utilises pas "directement" le descripteur, ok.

Disons que l'architecture est différente, mais le concept est (pour moi) identique.

 

 

0 Compliments
Message 52 sur 63
376 Visites

En utilisant un enum (évidemment un typed def) pour définir les quelques types utilisés, le code est très lisible et compréhensible car il s'autodocumente.

Avec le descripteur, c'est nettement moins clair.

 

Queue variants.jpg

 

Comme visible dans cette capture d'écran, j'ai pour habitude de mettre dans une Diagram Disable Structure de la Case Structure correspondante, le VI avec lequel ce type de données est transmis.

La raison ? Deux clics suffisent alors pour localiser tous les endroits de l'application où ce type est envoyé en effectuant une recherche de toutes les instances de ce VI.

Message 53 sur 63
362 Visites

@JB

 

ok pour la lisibilité

 

j'ai pour habitude de mettre dans une Diagram Disable Structure de la Case Structure correspondante, le VI avec lequel ce type de données est transmis.

La raison ? Deux clics suffisent alors pour localiser tous les endroits de l'application où ce type est envoyé en effectuant une recherche de toutes les instances de ce VI.

 

ça c'est malin !!! kudo.

0 Compliments
Message 54 sur 63
354 Visites

Salut à tous,


Eric.M a écrit :

La publication est pour quand d'ailleurs ? Vu que le rêve est en partie déjà exaucé 🙂


salut @eric, oui il semblerait... Je deviens co-auteur de la troisième version du livre LabVIEW (édition Dunod). Je n’ai pas écrit le livre, mais participé à l’aventure (tu le sais Eric mais c’est pour les autres). Il faut « rester à sa place », écrire un livre comme celui-ci c’est 1000 heures, participer c’est… (déjà beaucoup Smiley très heureux

 

J’ai écrit 2 chapitres :

LabVIEW avancée (style du code, gestion des données de la locale vers la DVR en passant par OOP, modèles de conception et faire une application avec le QMH),

et pilotage des systèmes de mesure (DAQmx, VISA, IVI).

 

et J’ai actualisé un troisième chapitre sur les fichiers, base de données, outils indispensable (par exemple OpenG), faire un rapport Microsoft Office, partage données TCP/IP et MVP.

 

Pour les autres chapitres, je crois avoir simplement « harcelé » l’autre co-auteur, qui a accepté avec beaucoup de gentillesse, pour avoir des Diagrammes LabVIEW que je juge « propre ». Mais vous savez combien la notion de code « propre » est variant (variant ? encore un variant LabVIEW? non peut varier) entre développeurs.

 

La sortie est pour fin mai. J’ai une première épreuve papier sur mon bureau. Il me reste des correctifs à finir.

 

Dans cette version LabVIEW ne sera plus un logiciel de simulation...

bonne journée à tous car j'ai un driver à faire... dans les régles de l'art en utilisant le projet modéle de driver...

A+

 

banniere Luc Livre NXG Champion.png

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

Message 55 sur 63
346 Visites

@Luc :

 

Bonjour Luc,

 

Mais vous savez combien la notion de code « propre » peut varier entre développeurs.

 

Cette phrase (me) donne l'impression qu'il y a réellement plusieurs façons d'aboutir à du code propre avec Labview ... pas trop d'accord.

 

Un code propre est définit par des règles, sans trop réfléchir, une dizaine grand maximum.

 

Cette notion n'est pas subjective, elle n'est pas de l'ordre d'une notion ou d'une perception personnelle, elle est structurée et parfaitement définie.

 

Quand ces règles sont respectées scrupuleudement, on abouti à 100% à du code propre.

 

La rigueur personnelle est variable entre développeurs ... le concept de code propre, lui, est un invariant.

 

(Juste mon avis perso)

 

 

0 Compliments
Message 56 sur 63
340 Visites

ouadji a écrit :

 

alors ? d'où vient cette Connaisance "C+1" ? un accès à de la doc "interne" ? des cours et formations "C+1' (interne, de NI pour NI ?)

 

Est-il "autorisé" de répondre à une telle question ?

 

 


salut Application note 154

banniere Luc Livre NXG Champion.png

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

0 Compliments
Message 57 sur 63
318 Visites

en PJ

This document describes the following concepts:

• How LabVIEW stores data in memory

• How LabVIEW converts binary data for file storage on disk

• Relationship of type descriptors to data storage

 

banniere Luc Livre NXG Champion.png

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

Message 58 sur 63
317 Visites

je pense que tu dois pouvoir retrouver les documents sur internet (c'est un scan) j'avais découvert cela en 2003 et j'avais bcp aimé...

banniere Luc Livre NXG Champion.png

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

Tout télécharger
Message 59 sur 63
316 Visites
0 Compliments
Message 60 sur 63
314 Visites