From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Discussions au sujet de NI LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Paramétrage d'un buzzer

Bonjour, j'ai réalisé un programme qui, en bref, consiste a compter le nombre d'appuis. Le programme fonctionne très bien avec le bouton poussoir labview. Ceci dit, quand j'affilie le buzzer a l'assistant DAQ (pour remplacer le bouton poussoir), le programme compte le temps d'impulsion et non le nombre de front montant comme je voudrais.

Savez vous comment je pourrais configurer la DAQ pour compter le nombre de front montant et non pas le temps ?

Download All
0 Kudos
Message 1 of 5
(2,858 Views)

       Bonjour Branly,

 

Plusieurs points à prendre en compte :

  - Le VI "VIprincipale.vi" ne sert ici à rien car il manque tous les sous-VI qu'il appelle, je te conseille d'organiser ton programme dans un projet incluant tous les VI et sous-Vi définis de façon hiérarchique. Lorsque tu envoies ton programme, fait un zip de l'intégralité de ton projet, VIs et sous-VI.

  - En se concentrant uniquement sur le VI "Jeu de fréquence.vi", plusieurs problèmes apparaissent, qui peuvent, ou pas, être la source de l'erreur que tu expérience, mais qui méritent dans tous les cas d'être corrigés :

       > Il faut éviter à tout pris l'utilisation de nœud de propriétés et de variables locales, leur utilisation coupe le flux de données LabVIEW et peut être source de conflits d'écriture. Plusieurs méthodes sont à privilégier, comme l'utilisation de registres à décalage.

       > Aucune programme ne devrait comporter 2 structure événements dans la même boucle While. En outre, je ne comprends pas l'intérêt d'aucune des deux boucles While ici.

       > Le code tient sur un seul écran et c'est une très bonne chose. Il faudrait également rendre le diagramme plus lisible en éviter que les fils se croisent où qu'ils soient cachés derrière des structures. La condition "Game" est particulièrement difficile à lire. L'utilisation de commentaires facilite également la lecture d'un code.

       > L'assistant DAQ n'est sans doute pas la fonction la plus pratique ici et sans doute serait-il plus fonctionnel d'utiliser une fonction DAQ de bas niveau mais cela n'est indispensable dans un premier temps..

 

En espérant que cela aide,

Bonne journée,

 

Message 2 of 5
(2,820 Views)

@Jun'  a écrit :

       Bonjour Branly,

 

Plusieurs points à prendre en compte :

  - Le VI "VIprincipale.vi" ne sert ici à rien car il manque tous les sous-VI qu'il appelle, je te conseille d'organiser ton programme dans un projet incluant tous les VI et sous-Vi définis de façon hiérarchique. Lorsque tu envoies ton programme, fait un zip de l'intégralité de ton projet, VIs et sous-VI.

  - En se concentrant uniquement sur le VI "Jeu de fréquence.vi", plusieurs problèmes apparaissent, qui peuvent, ou pas, être la source de l'erreur que tu expérience, mais qui méritent dans tous les cas d'être corrigés :

       > Il faut éviter à tout pris l'utilisation de nœud de propriétés et de variables locales, leur utilisation coupe le flux de données LabVIEW et peut être source de conflits d'écriture. Plusieurs méthodes sont à privilégier, comme l'utilisation de registres à décalage.

       > Aucune programme ne devrait comporter 2 structure événements dans la même boucle While. En outre, je ne comprends pas l'intérêt d'aucune des deux boucles While ici.

       > Le code tient sur un seul écran et c'est une très bonne chose. Il faudrait également rendre le diagramme plus lisible en éviter que les fils se croisent où qu'ils soient cachés derrière des structures. La condition "Game" est particulièrement difficile à lire. L'utilisation de commentaires facilite également la lecture d'un code.

       > L'assistant DAQ n'est sans doute pas la fonction la plus pratique ici et sans doute serait-il plus fonctionnel d'utiliser une fonction DAQ de bas niveau mais cela n'est indispensable dans un premier temps..

 

En espérant que cela aide,

Bonne journée,

 


Le programme évolue tout les jours donc je m'occuperai de la lisibilité a la fin.

J'ai du mettre deux événement car on avait pas la même base de temps pour le retour menu. De plus vu que ça fonctionne je ne vois pas ou est  le problème.

Sinon je ne sais toujours pas comment parametrer le bouton pour récuperer les fronts montants.

 

Merci

 

0 Kudos
Message 3 of 5
(2,804 Views)

Bonjour Branly,

 

Jun' est expérimenté tu devrais suivre ses conseils. Les bonnes pratiques s'apprennent avant que les mauvaises habitudes apparaissent.

 

Pour ton problème : Pendant le temps d'appui sur le bouton, ton programme a le temps de regarder l'état de l'entrée digitale de multiples fois et donc d'incrémenter le compteur à chaque fois. 

Pour éviter ça, une solution est de vérifier que le bouton a été relaché entre chaque incrémentation de compteur. Avec un registre à décalage tu pourras comparer l'état actuel et l'état précédent.

 

Yddet

0 Kudos
Message 4 of 5
(2,790 Views)

to branly,

 

Ton programme est à 95% un cas d'école de tout ce qu'il ne faut jamais faire en langage G.

Jun's  t'a donné une liste de très bons conseils pour améliorer ton code et surtout pour améliorer ta "façon" d'utiliser LabVIEW ... ou plus simplement pour apprendre LV, peut-être faudrait-il commencer par là !

 

"Le programme évolue tout les jours donc je m'occuperai de la lisibilité a la fin."

Cette phrase est monstrueuse. La lisibilité, que ce soit avec LabVIEW, ou avec n'importe quels autres langages est absolument fondamentale. Avec une telle phrase on se fait foutre à la porte de n'importe quel cours d'informatique.

Pour le reste ... pour essayer de t'aider je suppose que les lecteurs de ce Forum n'ont pas d'autres choix que de se satisfaire de ton brouillon ... ils n'ont qu'à se débrouiller pour s'y retrouver après tout ! c'est ça ?

"De plus vu que ça fonctionne je ne vois pas ou est  le problème."

Et bien le problème est que le paramètre "fonctionne" n'est absolument pas suffisant pour qu'un code soit du beau code, efficace, performant ... mais également, maintenable, évolutif, et j'en passe.

 

bon code à tous.

Message 5 of 5
(2,782 Views)