Discussions au sujet de NI LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Variable globale avec un grand nombre d'éléments ... Dangereux ?

Solved!
Go to solution
Highlighted

Bonjour,

 

Dans mon programme, je souhaiterai mettre en oeuvre une variable globale :  elle me permettrait de stocker tous les éléments nécessaires pour les étapes suivantes (gestion des valeurs à envoyer ou à mesurer avec les instruments étalons, calcul des incertitudes, etc.)

 

Le programme aura pour but de fournir un compte rendu excel avec toujours les mêmes paramètres à quelques exceptions près (il y aura un ou deux paramètres supplémentaires pour certaines fonctions).

 

L'appareil à étalonner comporte un grand nombre de fonction, et il y a plusieurs calibres pour chaque fonction, ce qui rend le nombre d'élément très grand (80 fonctions avec pour la plupart d'entre elles, 2 calibres).

Pour moi, le plus simple serait de faire un tableau de cluster pour chaque calibre de chaque fonction même si cela impliquera la construction de près de 160 tableaux.

Si vous avez une idée d'une alternative plus rapide et plus efficace je suis preneur !

 

Le programme doit être le plus flexible possible donc je compte chercher les données correspondantes à chaque fonction depuis 1 fichier excel.

 

Voici à quoi ressemblerait ma variable globale (il n'y a qu'une partie des tableaux de cluster)

 

J'ai essayé d'être le plus clair possible mais si vou savez des questions n'hésitez pas Smiley Happy

Merci à vous Smiley Wink

0 Kudos
Message 1 of 11
(267 Views)
Solution
Accepted by topic author Lablasc

Bonjour, la réponse courte est oui c'est dangereux. La version longue... va être très longue : gestion de la mémoire avec des copies, bug à cause d'accès concurrents, mauvaise gestion des données, pas évolutifs car le code n'est pas segmenté, problèmes si plusieurs développeurs....

 

J'ai écrit un post de blog sur le sujet

pour ta question il y a le présentation N°2 sur Technique, Gestion des données, accès concurrents, mémoire sous LabVIEW

Elle traite de l’évolution

  • du concept « mémorisation » du flux de données,
  • de la gestion des données sous LabVIEW
  • des accès concurrents

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, nœud de propriété... et comment faire.

A+ Luc

 

 

Message 2 of 11
(218 Views)

Bonjour Luc et merci de ton retour rapide.

 

Je viens de bien décortiquer les supports que tu m'as conseillé de lire mais il me reste quelques zones d'ombres. Pour mon besoin je pense que partir sur une state machine pourrait suffire. Or, j'ai pu lire qu'il était fortement recommandé d'utiliser une QDMH. Pour moi (n'hésitez pas à me corriger si je dis des bêtises) une QDMH permet seulement de réaliser 2 actions simultanément. L'affichage de messages "dynamiques" peut tout ausi bien être fait avec une state machine tout en restant simple (via des popups). De plus, je recherche une automatisation "assez poussée" avec peu d'interventions sur la face avant. Je voudrai que lorsque le programme se lance, il puisse se dérouler de manière autonome.

 

Ensuite, quelque chose que je n'ai pas compris également, c'est le passage des diapos sur la machine à états à l'OOP by data et by ref. Quelles sont leurs buts ? 

(Diapo 59 : Darwin Labview Evolution des données)

 

Dernières questions concernant la state machine, peut-elle être un modèle adéquat pour gérer les erreurs ? Et enfin, tout le code doit-il être contenu dans la state machine ? ou on peut avoir du code en "sortie de state machine" ?

 

Merci d'avance Smiley Wink

 

0 Kudos
Message 3 of 11
(184 Views)

 

Utiliser des variables globales pour des paramètres n'est pas du tout un problème, car tu les utilises pratiquement uniquement en lecture. Il faut juste garder en tête que l'appel d'une variable globale prend plus de temps que l'appel d'une variable locale ou d'une valeur. Il faut donc éviter de placer la variable dans une boucle à grand nombre d'itérations. L'immense avantage, c'est que c'est facile à visualiser et à manipuler, contrairement à toutes les autres solutions.

 

Cela dit, les variables globales sont surtout déconseillées aux débutants pour ces raisons:

- Danger de race concurrence si on ne contrôle pas l'écriture

- Gros capharnaum dans le projet si les références sont brisées. Par exemple si on renomme une variable, on devra mettre manuellement tous les VIs à jour. Cela peut complètement pourrir un projet.

 

Cela dit c'est une fonctionnalité à part entière. D'ailleurs en regardant de près on peut s'apercevoir que certaines fonctions standard de Labview utilisent des variables globales, notamment les serveurs.

 

La solution du "Fonctional Global Variable" permet de gérer les accès en écriture, c'est donc la solution la plus sûre et qui est recommandée, pour des valeurs simples uniquement. Dès qu'on travaille avec des clusters, cela perd de sont intérêt.

 

La solution du Data Value Reference fonctionne aussi, mais n'est pas toujours élégante dans le code.

 

Il faut aussi remarquer, que le très restrictif langage C# utilise un dictionnaire d'objets en guise de paramètres, et qui se trouve à la racine du projet et qu'on peut tout à fait assimiler à une variable globale.

Message 4 of 11
(160 Views)

Salut Lablasc, désolé de ma réponse tardive, je n'avais pas vu ta réponse.

 

Une state machine est une structure case (permet de définir les état). Les transitions sont réalisées via un enum. L'enum est une valeur. La transition est donc vers 1 seul état. Il n'y a pas de FIFO pour empiler plusieurs états à réaliser à la suite.

 

Le QMH est l'évolution de la state machine. La transition est réalisé par une FIFO Queue. Il est possible d'enchainer plusieurs états, en empilant les états dans la FIFO. Q : queue ; M = Message : Un message est un cluster "Etat = case" + "Data = variant qui est optionnel et qui contient les données à passer à l'état.

 

Le QDMH est un QMH mais dans lequel nous avons une boucle "Driven" qui est une structure évènementielle, qui détecte les actions utilisateurs (clique sur un bouton) et va empiller dans la FIFO queue le/les états (les actions) à réaliser.

 

L'avantage du QDMH c'est que la solution est recommandée par NI, sous LabVIEW il y a un projet accessible directement sous nouveau projet (modèle). La solution est maintenable, évolutive, performante, connu des autres développeurs.... C'est le projet à connaitre, et je pense le projet à utiliser. J'ai même écrit un chapitre dans un livre sur les qualités de ce modèle de projet... :-)

 

Vous voulez un programme avec peu d'interventions... donc vous voulez enchainer des actions logiciels, donc des états via des transitions (diagramme classique de Moore!). Un QDMH n'est pas forcement indispensable, mais rien n'impose d'avoir la structure évènementielle, donc d'avoir un QMH (machine à état avec FIFO queue). Tu ne veux pas empiler les actions... tu peux garder une simple State Machine (machine à états). Mais attention, elle est moins évolutive que celle avec une FIFO Queue.

Message 5 of 11
(147 Views)

ok... je ne sais pas. Il faut que je regarde la diapo avant... je trouve cela super que tu es bien analysé les présentations. je vais trouver le temps de répondre, mais pas ce soir. Relance moi, si je tarde trop

 


Ensuite, quelque chose que je n'ai pas compris également, c'est le passage des diapos sur la machine à états à l'OOP by data et by ref. Quelles sont leurs buts ? 

(Diapo 59 : Darwin Labview Evolution des données)

Merci d'avance Smiley Wink

 


 

Message 6 of 11
(144 Views)

oui, tu peux évidement gérer les erreurs, mais cela n'est pas aussi simple que dans le Template de projet QDMH livré par NI dans LabVIEW : tu as un case erreur, et tu décides ce qu'il faut faire sur l'erreur (log, afficher, supprimer, fermer l'application)

Le code en sortie de la state machine est le code "exit, close ou fermeture" de l'application (code à faire sur fermeture)

 

Dernières questions concernant la state machine, peut-elle être un modèle adéquat pour gérer les erreurs ? Et enfin, tout le code doit-il être contenu dans la state machine ? ou on peut avoir du code en "sortie de state machine" ?

 

 


 

Message 7 of 11
(139 Views)

salut Walker34

sur certains points, je suis en accord avec toi


@Walker34 wrote:Utiliser des variables globales pour des paramètres n'est pas du tout un problème, car tu les utilises pratiquement uniquement en lecture.
- Danger de race concurrence si on ne contrôle pas l'écriture

La globale va avoir 2 grands inconvénients :

  • duplication de la donnée (copie mémoire de la globale donc augmentation mémoire) sur le nombre de globales
  • Race condition

La FGV ou fonctional global variable ne protège pas en écriture, c'est l'AE (ou Action Engine) qui a cette capacité. La FGV est un VI global qui va donc éviter la duplication des données (copie mémoire de la globale), puisqu'il n'est pas réentrant et est réutilisée.

Je suis d'accord avec toi, une FGV avec 1 seule définition de variable n'aura pas d'accès conçurent. Mais la finalité de la FGV est d'éviter les copies mémoires.

Je ne suis pas d'accord avec toi, lorsque tu écris que lorsque l'on travaille avec des clusters, cela perd de son intérêt. La FGV permet de partager des données, dans toutes l'application, elle est donc globle, et elle permet d'éviter les copies mémoires. Dans un QDMH se sera le contexte. C'est donc une solution recommandée par NI, pour la mémorisation des données (registre à déclage non initialisé, ou variable LV2).

 

Dans les présentations que j'ai donné un lien, j'illustre le bug des FGV en race condition, qui sera protégé par l'AE (action engine)

A+

Message 8 of 11
(138 Views)

Merci à tous de vos réponses et de votre temps !

 

J'étais parti sur une state machine car plus facile et je l'avais déjà utilisée plus ou moins correctement auparavant. Cependant, j'ai peur de me retrouver bloqué ensuite par un modèle trop "basique" (oui je me souviens que dans les diapos, il était fortement conseillé d'utiliser le bon modèle dès le début pour éviter les problèmes Smiley Very Happy)

 

Je vais essayer de passer par une FIFO queue, ça sera un bon entrainement. Si j'ai le temps j'essayerai de vous faire un retour sur le forum même si je vais devoir cacher 2 3 choses (confidentialité blablabla). Si quelqu'un a le temps de me répondre ça pourrait être intéressant de voir ce qu'il doit être amélioré dans mon code.

 

Je vais passer ce sujet en résolu car au final ma réponse je l'ai eu dès le début: oui c'est bel et bien dangereux les variables globales donc j'essaierai d'être prudent

C'est quand même fort dommage que tout ce qui est pratique à utiliser soit dangereux (noeud de prop, var locale, var globale) ... --'

 

Merci de vos retours instructifs Smiley Wink

0 Kudos
Message 9 of 11
(107 Views)

salut, dangereux... il ne faut pas exagérer :-) Là n'est pas mon message

  • une Ferrari est une superbe voiture, mais il faut savoir la piloter, elle sera difficile mais puissante. Si tu fais n'importe quoi, tu vas dans le mur.
  • une clio est plus simple à utiliser, plus abordable techniquement, mais tu ne pourras pas en faire une Formule1.

 

mon message est que chaque technique de développement répond à un objectif. Il faut comprendre l'objectif de ton projet, pour sélectionner la bonne technique. Simple va avec base, évolutif va avec une technique de développement plus "évoluée". 

 

La route de l'objet face-avant, nœud de propriété, la locale, globale, FGV, AE, DVR, Single Element Queue vers la State machine, QMH, QDMH, Actor Framework.... la route est longue, mais si tu comprends... ton code sera super.

 

OS RT, FPGA, DAQmx, pilotage de plusieurs instruments, application R&D sur un coin de table ou application pour 1000 clients.... il n'y a jamais une réponse. Chaque détail peut me faire changer de technique.

Une application simple, avec lecture de paramètres, puis une boucle de pilotage d'instruments sans action utilisateur, pourquoi pas ne pas faire une FGV, ou une globale (1 écriture - 1 lecture donc pas d'accès concurrent) avec une simple State Machine. Mais s'il faut ajouter la visualisation des paramètres des instruments, que l'utilisateur peut modifier quand il le désire...

 

Mon objectif est de te permettre de comprendre l'intérêt de chaque technique, pour que tu puisses prendre celle que tu préfères. Tu dois être "à l'aise" avec la technique de développement que tu vas, choisir, et en comprendre les avantages et les inconvénients.

 

Il n'y a aucun problème à actualiser des indicateurs sur une IHM via une locale, ou un nœud de propriété. Mais si tu veux faire un simulateur de capteurs qui doit répondre en 10ms... la technique ne sera pas bonne. Une question de dosage!

+A Luc

Message 10 of 11
(93 Views)