Discussions au sujet de NI LabVIEW
boucle événement
Je me permets un rappel. La structure évènementielle a pour vocation « première » de gérer les actions utilisateurs, actions qui sont réalisées « par un clic souris » sur des objets « LabVIEW » de la face-avant (ou IHM). Le développeur va créer un état « valeur changée » ou autres, qui va réagir sur actions de l’utilisateur sur l’IHM.
Mais lorsque le développeur veut déclencher un état par programmation, si la valeur de l’indicateur est « uniquement » modifié via le flux de données, alors la structure évènementielle ne va pas détecter le changement (pas de clic sur l’objet via la face-avant).
Si tu veux le faire, le plus simple est d’utiliser la propriété « value (signaling) » de l’objet (clic droit -> créer propriété).
cf l’aide
Value (Signaling) Property
Short Name: Val(Sgnl)
Class: Control Properties
Sets the value of the control and generates a Value Change event.
This property updates the value of an object similar to the Value property. However, Value (Signaling) also causes LabVIEW to generate an event as if the user had interactively changed the value of the object. National Instruments recommends you use this property only when you rely on LabVIEW generating an event in response to the programmatic value change.
Dans ton cas la douchette USB émule les actions utilisateurs sur un clavier, tu auras donc le case « DouchetteUSB : valeur changée » qui va être exécuté. Par rapport au flux de données, il faut mettre le code dans l’état de la structure qui gère le changement d’état, et pas uniquement dans la boucle while (action parallélisée, et situation de bug ).
Pour les données du boitier de vissage connecté en RS232, il n’y a pas d’action utilisateur, ni d’action évènementielle. La structure évènementielle ne peut pas être programmée directement, via un évènement statique.
Tu peux faire un code parallèle, qui va générer un évènement dynamique, qui va provoquer l’exécution d’un autre code… mais pourquoi ne pas mettre un état « timeout » dans la structure évènementielle, état qui périodiquement va faire la lecture des données dans le buffer RS232 ?
Sans vouloir manquer de respect, tu peux « optimiser » le code via un évènement dynamique, mais je pense qu’il y a plus simple par rapport au niveau.
Pour le flux de données, je me permets également une remarque : "LabVIEW code G VS langages programmation classiques"
Une des différences fondamentales de LabVIEW (par rapport aux langages classiques) est que ce langage suit un modèle de flux de données, et non de flux d'instructions.
Cela signifie que pour un langage textuel ce sont les instructions qui ont la priorité, alors qu'avec LabVIEW ce sont les données.
Une fonction s'exécutera donc à partir du moment où elle dispose à ses entrées de toutes les données dont elle a besoin.
La solution revient souvent à répondre à 2 questions à quel moment et comment le flux de données transmet la variable à un indicateur ?
J’espère ne pas t’avoir « vexé », lorsque j’écris qu’il y a plus simple qu’une programmation dynamique. Je pense que dans ton cas, plus simple sera meilleur.
J’ai le sentiment que la difficulté que tu as, réside dans l’organisation dans ton code :
- Détection des actions utilisateurs
- Gestion des tâches périodiques (données RS232, …)
J’ai le sentiment que tu as un problème d’architecture.
Je me permets donc un dernier conseil, la lecture du lien suivant.
« LabVIEW : programmation et applications » ou comment apprendre à utiliser LabVIEW
Certes je me fais de la pub, mais :
- l’introduction définit les bases du flux de données,
- tu as la gestion des données avec les FGV
- les structures de programmes (Machine à états et surtout QDMH)
Je pense que le §VIII-C. Bien démarrer un projet LabVIEW avec le GMF (QMH) doit répondre à tes questions.
A+
Luc
sklod a écrit : Ps: Ton livre à l'air intéressant, est ce que tu pourrais me conseiller un pour des connaissances plus approfondis en Labview
soit tu me charries...
soit...
ok je réponds;
Si tu n'écris pas LabVIEW avec les majuscules, tu veux un livre ? alors je te propose un livre français 🙂
LabVIEW Programmation et applications
Si tu n'es pas CLD, FGV VS AE? tu veux de la programmation avancée, le chapitre 3 du livre... Il présente les techniques de programmation avancée de la locale vers la DVR (locale, globale, FGV, AE, OOP, DVR...)
tu peux trouver une présentation anglaise
https://issuu.com/lucdesruelle/docs/darwin_applied_to_labview_v2.1/1
ppt et code disponible sur mon blog
ou française "simplifiée"
https://issuu.com/lucdesruelle/docs/darwin_labview_evolution_des_donnee
Le troisième chapitre aborde la programmation avancée en LabVIEW en définissant des techniques et architectures permettant au code d’être maintenable, évolutif et performant. Il présente des concepts nécessaire à l'examen CLD (Développeur Certifié LabVIEW).
si tu veux une explication détaillée, le pourquoi, le comment, les exemples... alors va voir le livre
http://labview.developpez.com/livres/
+A
" Luc a raison, les événements dynamiques sont .... "
1er principe : Luc a toujours raison 
" Ces points sont vraiment la base de la programmation LabVIEW .... "
" ces " ... l'utilisation du "pluriel" me dérange un rien.
Il n'existe qu'une et une seule règle de base avec LabVIEW, c'est la règle du "flux de données" ... il n'y en a pas d'autres.
Ce principe qui de prime abord peut sembler simpliste ... est en réalité bien plus subtil ... et peut même s'avérer d'une très grande finesse.
Les débutants s'y laissent tous prendre ... avec labVIEW c'est même la définition intrinsèque d'un débutant.
Et pour les développeurs plus expérimentés, quand le code devient complexe ... le "piège" est toujours possible.
Au départ de ce seul et unique principe ... labVIEW se décline à l'infini.
Celui qui apprivoise ce principe, celui qui "fusionne" avec ce principe ... devient Magicien.
sklod a écrit : J'ai un peu chercher sur internet pour un tuto qui regrouperais les grands titres dont viens de parler Luc, mais sans succès.
- flux de données,
- FGV
- les structures de programmes (Machine à états et surtout QDMH)
si?
http://luc-desruelle.developpez.com/tutoriels/labview/extrait-livre-programmation-application/
flux de données, FGV, Machines à états et QDMH
sinon, en vrac
Darwin applied to LabVIEW: The evolution of the data management
Darwin appliqué à LabVIEW : l’évolution de la gestion des données
La Gestion des erreurs sous LabVIEW
LabVIEW noeud bloquant - Thread User Interface - Root Loop - priorité - interruption
Quand faut-il fermer une référence sous LabVIEW?
Un GIF animé pour éviter de faire du code
....
A suivre A+ Luc
Salut!!!! Cela me fait bien plaisir de te lire!
" ces " ... l'utilisation du "pluriel" me dérange un rien.
Il n'existe qu'une et une seule règle de base avec LabVIEW, c'est la règle du "flux de données" ... il n'y en a pas d'autres.
Ce principe qui de prime abord peut sembler simpliste ... est en réalité bien plus subtil ... et peut même s'avérer d'une très grande finesse.
Les débutants s'y laissent tous prendre ... avec labVIEW c'est même la définition intrinsèque d'un débutant.
Et pour les développeurs plus expérimentés, quand le code devient complexe ... le "piège" est toujours possible.
Au départ de ce seul et unique principe ... labVIEW se décline à l'infini.
Celui qui apprivoise ce principe, celui qui "fusionne" avec ce principe ... devient Magicien.
2iéme principe : Ouadji a toujours raison
A+ luc
