le 03-12-2015 04:04 AM
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.
03-12-2015 07:04 AM - modifié 03-12-2015 07:05 AM
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.
le 03-12-2015 10:56 AM
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.
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.
le 03-12-2015 02:22 PM
@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.
le 03-13-2015 02:44 AM
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
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+
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
le 03-13-2015 05:15 AM
@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)
le 03-16-2015 09:47 AM
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
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
le 03-16-2015 09:51 AM
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
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
le 03-16-2015 09:55 AM
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é...
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
le 03-16-2015 10:02 AM
et le dernier
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