Sous-vi trop gourmand en ressources

[Geoff54]

Petites infos complémentaires, j'ai réalisé ma programmation avec une commande à onglet comme tu peux le voir :

test components : je génère une excitation que je lis pour voir si mon entrée analogique est bien fonctionnelle et présente.

reference psd design : c'est ici que l'on rentre les points de cassures

control vibrations : génération de mon accélération en fonction de ma fréquence

[fab1]

Houla !

Bon j'ai ouvert le main,... Il me faut 3 écrans en hauteur et 8 mini en largeur pour suivre le vi -> Impossible de debuger quoi que ce soit.

Des petites choses en vrac :

- Le projet c'est utile, ça permet de maintenir le lien entre les vi dans un dossier. Comme ça quand j'en ouvre un, il trouve les autre vi par rapport au projet. Labview ne va pas me les chercher n’importe où sur le PC.

- Dans ton main tu as des structures séquences déroulé, dedans des boucles while avec en parallèle d'autre séquences déroulé. C'est impossible de comprendre quoi que ce soit sans se faire des nœuds au cerveau.

Il y a effectivement des acquisition un peu partout dans le main, j'ai pas regardé en détail mais peut être que plusieurs sessions sur les mêmes ressources sont réalisé en même temps.

Il faudrait peut-être changer la structure pour y voir plus clair :

As-tu regardé les machines à état? Il faudrait peut-être que tu regardes la machine à état standard (fichier - nouveau - from template framework - design pattern- standard state machine)

Tu as différentes structure évènement dans une même étape de ta séquence déroulé, tu ne pourrais pas les intégrer dans une seul structure évènement ?

Tu pourrais aussi structurer tes différents éléments (notamment tout la partie DAQ) dans des sous vi, le vi ppal serait plus lisible.

[Geoff54]

C'est moche à dire mais je m'attendais à ce genre de réponse ! Je vais essayer de faire sa plus propre. j'ai aussi beaucoup de while qui s'execute en parallèle le problème vien peut etre de la aussi

[Geoff54]

Au début de mon programme je cherche à réinitialiser un certain nombre de variable, comment puis coder sa d'une manière différente?

[fab1]

Si c'est leur valeur par defaut pourquoi ne pas utiliser la methode 'default value reinit all' ?

[Geoff54]

Voila j'ai un peu tout recompacté supprimer des boucles inutiles et commenté briévement les étapes principales de mon programme. J'ai également colorié en gris la partie qui à l'aide des valeurs générés par mon précédent bloc va les executées une à une.

Je pense que c'est de la que vien le problème.

Les étapes qui précede le bloc ' sweep spectrum" sont bonnes et ne génère aucuns problèmes de t'en occupe pas. Le problème est situé entre le sweep spectrum et le Vs trace plot.

[Geoff54]

Je suis sur que le problème provient de la partie grisée, quand on contrôle le nombre d'itérations pour 2 cycles ou 40 l'execution de la boucle est bien plus lente ce qui ressemble aux syptomes de mon programme

[fab1]

Bonjour,

L'exécution de la boucle est plus longue peut être dû aussi au faite que les tables sont plus importantes.

Je viens d'ouvrir ton dernier vi. C'est toujours le 'fouillis' 7 écrans en largeur pour lire le code et 3 en hauteur.

Si tu veux progresser, il faut que tu regardes les structure proposé par NI pour la programmation.

Il y a beaucoup trop de choses partout au même niveau pour y voir clair.

Par ex : A la fin tu as 2 structures évènement dans une boucle while. Chacune avec un seul evt : la 1er 'stop value change'; la seconde 'bouton Ok value change'.

As-tu bien compris le fonctionnement de la structure évènement? Ces deux évènements peuvent être regroupé dans une seul structure.

Dans ta partie grise, de nouveau une boucle while, a l’intérieure création d'une tache DAQ, pas de surpression de celle-ci. Ce n'est pas propre.

Ton programme en regardant comme ça semble fonctionner de la manière suivante :

1 Init

2 attente bouton

3 suivant bouton de config changement d'onglet

4 attente bouton

5 démarrage acquisition

Je me trompe? Il faudrait vraiment que tu prennes du temps pour regarder les machines à état, ton programme serait plus clair.

---

Geoff54 a écrit :

. j'ai aussi beaucoup de while qui s'execute en parallèle le problème vien peut etre de la aussi

---

Effectivement ça risque de te poser problèmes. Dans chaque boucle des variables local qui tournent en parallèle. As-tu entendu parler des situations de compétition ?

Autre exemple : A différentes endroit tu utilises le nœud de propriété pages de ta commande onglet pour rendre visible ou non certaines pages. Ce code est répété à x endroits.

Pourquoi ne pas mettre cela dans un sous vi ? As-tu entendu parlé des FGV (Variable Global Fonctionnel) ? Tu pourrais garder la référence de ta tab onglet et dans le sous vi affiché ou non les pages.

[Geoff54]

Je viens de modifier la structure evenement c'est vrai que je n'avais fait attention. J'ai également supprimé la création de la tache DAQ dans la partie grise. Si les tables sont plus importantes n'y a-t'il pas de solutions car j'ai beau supprimé des parties de mon programme et remettre en forme je ne voix aucuns changements au niveau de la vitesse d'execution.

Le problème vien de la partie grise, on voit bien que le nombre d'itérations ne varie pas de manière linéaire et que quelque chose la ralentie. j'ai casi supprimé tous les élements de cette boucle et rien ne change. Je commence à penser que le problème est vraiment due à l'accumulation de données.

Comment procéder ?

Mon programme fonctionne de la manière suivante : 

- On rentre les points de cassures

- On passe par le sousVi generate Sweep spectrum ou l'on calcul l'ensemble des points suivant le nombre de cycle et la "frequency lines"

- Une fois que l'on appuie sur le bouton "OK" on passe au sous VI "profile" on l'on définie les limites hautes et basses et on l'on init

- On arrive à la séquence empilée "0" ou l'on incrémente de manière progressive l'accélération pour arriver jusqu'a notre premier point, une fois l'accélération atteinte on quitte cette boucle et on arrive sur la séquence empilée "1"

-Celle-ci va receptionnée les valeurs en accélération et fréquence fournie par le vi "profile" et ainsi distribuée la fréquence et l'accélération au fur et à mesure à notre sortie analogique

-On a un bouton "lecture" qui lui nous permet de passer en mode automatique ou manuel, le mode manuel stop l'incrémentation de l'accélération et de la fréquence et nous permet d'incrémenter manuellement ces 2 paramètres afin de tourner autour d'un point qui peut nous interesser en passant par la seconde boucle while de la séquence empilée "1"

[fab1]

Il y a beaucoup de choses partout qui ne vont pas, la structure évènement n'était qu'un exemple.

Il faut recoder ton programme.

Ton fonctionnement est bien séquentiel : etape 1 puis etape 2 puis etape 3, etc,...

Je t'invite à modifier ton main en utilisant une architecture plus propre, comme proposé précédemment. Il y a des exemples sur ces structures aussi dans l'aide en ligne :

http://www.ni.com/tutorial/14120/fr/

http://www.ni.com/tutorial/7595/en/

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/fr/pg/1/sn/catnav:tu/q/state%20machine/

Une fois le code plus lisible, plus épuré tu trouveras plus facilement les optimisations à apporter