FGV (utilsation)

[ouadji]

Une question du même ordre que l'autre à propos de la variable locale ...

mais j'ai préféré créer 2 post différents ... c'est du même ordre ... mais sans plus.

Dans une boucle j'ai un sous-VI.

Je dois passer une donnée à ce sous-VI ... qui se trouve en arrière de là ou je suis ...

c'est à dire que ce sous-VI doit avoir cette donnée pour la prochaine itération.

Je peux :

utiliser un Shift-Registre ... et je cable une entrée du sous-VI sur ce SR

ou

J'utilise une FGV ...( un Set là où je suis ... un Get dans le sous-VI)

c'est une question de "densité"

Le connecteur d'entrée du sous-VI est déjà bien rempli ... et le diagramme aussi.

Au niveau clarté du code, une variable globale fonctionnelle m'apporte un plus.

Mais est-ce de bonnes pratiques ?

merci à tous.

[tinnitus]

re,

"Je dois passer une donnée à ce sous-VI ... qui se trouve en arrière de là ou je suis ...

c'est à dire que ce sous-VI doit avoir cette donnée pour la prochaine itération."

je vois pas .

les deux ont leurs avantages/inconvenients:

1) le cablage directe permet de bien identifier les commandes necessaires à l'execution du sous vi  / augmente le nb de fils

n'ya t'il pas des entrées qui pourraient etre gouper dans un cluster et passer ce cluster ?

2) FGV , on perd la notion de flux , mais les données modifiées sont accessibles par d'autre process sans sortir du vi

qui applique les modifs , on profite aussi des specificite de la FGV,  fonctions dediées à la structure, pas de conflit d'acces lecture/ecriture

Cdt

Tinnitus

[ouadji]

merci tinnitus

oui, ici aussi ... le flux visuel disparait.

Le Cluster ..

oui ... mais je ne sais pas trop pourquoi, je n'aime pas "bundle/unbundle" ... j'ai l'impression que ce sont des opérations

qui "bouffe" du code et dans lesquelles on perd (inutilement) du temps machine.

Fausse idée, à priori ?  ton avis ?

(et accessoirement ces fonctions prennent vite de l'espace écran)

Pour le reste, je n'ai pas besoin (ici) des spécificités d'une FGV (accessibilités, pas de conflit ...)

On y revient toujours, quand cela est possible ... rien ne vaut un SR.

Ce que je vais faire (avec éventuellement ton "option" Cluster)

[tinnitus]

oui cela peut sembler inutile tant que le projet reste bien circonscrit

tout est question de contexte,

Le cluster est l'equivalent d'une sructure en C ou autre

En terme de maintenance c'est toujours pratique de savoir rapidement sur quelle donnée on travaille 

en terme de temps d'acces au données , j'ai pas fait de test mais je pense que la question a du etre etudiée et

j'ai jamais rencontré de cas ou cela soit devenu critique, il ya aussi la structure element en place afin d'optimiser ces accès.

dans le cas de vi qui travaille sur  plus de 5 proprietés (parfois une vingtaine) , je preferer cabler un cluster 

Tinnitus

[ouadji]

dans le cas de vi qui travaille sur  plus de 5 proprietés (parfois une vingtaine) , je preferer cabler un cluster

ah oui ... là ... ...le luxe du choix n'existe même plus.

merci à toi.

[Florent_A]

Bonjour,

Au niveau mémoire, la FGV permet de cibler un espace mémoire, on travaille ainsi "en place" lorsqu'on lit la valeur, la modifie, puis l'écrit au sein de la FGV. L'utilisation des Globals va majoritairement induire des copies en mémoire.

Lorsqu'il s'agit de lire/écrire une donnée, on peut être tenter d'utiliser les globales plutôt que des FGV, pourtant, il ne s'agit pas en règle générale de ne faire que lire ou écrire, il s'agit aussi de traiter, d'enregistrer, de comparer des données. Dans ce cas là, la FGV est un vrai plus (on parle alors aussi d'AE: Action Engine). En effet, derrière la FGV, il y a aussi l'idée d'encapsuler la donnée (oops, on aborde l'orienté-objet...), c'est-à-dire masquer la donnée, définir le lieux où elle est accessible et donc traitable (uniquement dans la FGV donc). Ma donnée n'a alors pas (ou peu) d'existence au niveau du diagramme principal, seul la FGV peut la manipuler.

Ceci permet alors de:

- simplifier grandement le développement à plusieurs

- alléger les diagrammes de plus hauts niveaux

- améliorer la lecture du code

- focaliser sur l'architecture plus que sur le traitement des données en premier lieu

Bonne journée

A+