Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

Lenteur acquisition données par VISA serie

Bonsoir,

 

Je vais essaye rd'être aussi clair que possible même si ce n'est pas vraiment évident.

 

Je suis en train de développer un vi pour faire l'acquisition des valeurs d'un inclinomètre en utilisant les outils VISA.

Je dois envoyer différentes commandes avant de faire l'acquisition qui se termine toutes par quelques lignes de commentaires suivi de $EOT! ou $KO!.

Si c'est $EOT! c'est que la commande est bien passée, si c'est $KO! c'est que non.

Je me suis servi de ces termes pour soritr de la boucle de lecture.

 

Une seule commande ne se termine pas par ces termes, c'est celle de l'acquisition des données, "U 0" et il me faut lire le buffer de lecture en continu dans ce cas.

Pour arreter cette acquisition, il faut envoyer la commande "R"

 

J'ai plus au moins réussi à faire cela sauf que pour arreter l'acquisition, il me fallait envoyer la commande "R" plusieurs fois et en plus attendre environ 15 sec pour que cela soit vraiment réalisé.

J'ai pensé à rajouter une boucle condition dans le cas de l'utilisation de "R" pour vider le buffer avec l'outil VISA Flush I/O Buffer et sortir de la boucle lecture. Cela fonctionne très bien.

 

Mais en testant plus longuement, je me suis aprecu que cette latence de 15 sec était en fait le temps de réaction entre mon capteur et mon vi... Si la valeur de l'inclinomètre change, il faut 15 secondes à labview pour me l'afficher en moyenne.

 

J'ai essayé de réduire la taille du buffer avec l'outil VISA Set I/O Buffer Size mais c'est sans effet.

 

Avez-vous une idée de comment améliorer la réactivité de mon vi? Je vous joins mon vi ainsi que le sous-vi qui me converti l'hexa en mm.

Merci d'avance à ceux qui pourront m'aider.

 

Tout télécharger
0 Compliments
Message 1 sur 8
4 216 Visites

Bonjour,

Pourrais tu mettre ton vi dans une version de labview moins récente (2011, ou 2014), car beaucoup de personnes ne passent pas tout de suite au dernière version, cela limite donc le nombre de personne pouvant t'apporter de l'aide.

 

Sans voir le VI, le premier point que je vérifierais correspond au "timeout" de ta liaison. Comment configures tu le nombre d'octer à lire ?

Afin d'optimiser le temps de travaille, je te conseillerais le schéma suivant:

 

-Envoi de la commande

-Temporisation de 100 ms

- Utilisation Noeud de propriété "bytes at serial port"

- Cablage de la valeur à la fonction "Read".


Cdt,


Michael

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 2 sur 8
4 213 Visites

Oui pardon, je les met en version 11.

 

Le schema que tu donnes est celui que j'utilise deja.

 

Merci

Tout télécharger
0 Compliments
Message 3 sur 8
4 210 Visites

Bonjour,

J'ai fait quelques optimisations dans ton code, pour améliorer l'exécution.

Je ne pense pas que cela corrigera le problème, mais cela peut aider à mieux l'identifier.

Cdt,


Michael

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
Tout télécharger
0 Compliments
Message 4 sur 8
4 189 Visites

Bonjour Michael,

 

Merci pour les améliorations.

 

- pour le Vi ExtractionAngleINCLINO, ce n'est pas la dernière valeur en hexa qu'il faut prendre, mais celle du milieu de la chaine. J'ai donc désactivé ton amélioration et remis la mienne.

 

- pour le Vi VISA Test Inclino V1.4, maintenant entre chaque commande je suis obilgé d'executer complement le programme. Cela n'a rien changé au temps de latence. J'ai remarqué qu'en plus ce temps de latence avait tendance à augmenter avec le temps...

 

J'ai remarqué quand remplacant la boucle while de lecture par une boucle for avec 20 itérations par exemple. La réactivité était grandement améliorée, de l'ordre de 5 sec.

 

Mon inclinomètre envoit des données toutes les 20 ms, du coup je pense qu'avec la boucle while, il accumule du retard dans la lecture du buffer. Alors qu'avec une boucle for il doit le remettre à zéro avec chaque 20 itérations.

Je sais pas si tu connais le logiciel Termite pour communiquer par port serie. J'essaye de reproduire ce programme avec labview. Quand je teste sous termite, le changement de valeur de mon inclinomètre est quasi-instantané.

Comment fait il pour lire les données envoyées? Quelle est la différence avec labview?

 http://www.compuphase.com/software_termite.htm

 

 

 

 

0 Compliments
Message 5 sur 8
4 181 Visites

Je continu mes tests depuis ce matin.

 

Si je remplace le noeud de retroaction par le noeud de retroaction que j'ai trouvé dans le vi Lire et ecrire en continue. La réactivité est vraiment meilleure. c'est pas instantané mais c'est beaucoup mieux.

 

Par contre au niveau du buffer de lecture je n'ai pas toutes les réponses, seulement la 1ere ligne sauf pour la 1ere commande envoyée ou la c'est complet...

Si je lance la commande pour faire l'acquisition, au niveau du buffer j'ai bien toutes les trames qui passent...

 

Je m'y perds...

 

 

 

 

 

 

0 Compliments
Message 6 sur 8
4 171 Visites

Pour gagner en vitesse d'exécution, je te conseillerais de travailler avec une structure Producteur/Consommateur.

 

La boucle "Productrice" inspecte en permanence la liaison de série à une période maximum, et quand des données sont à traiter, la boucle "Consommatrice" génère l'exploitation des données, et le traitement de la valeur à la période que tu souhaites.

 

Pour des ajustements de ce type, il est difficile de t'aider car il s'agit aussi de la sensibilité de ton équipement.


Regarde ce que préconise la documentation du constructeur. N'est il pas possible de modifier la récupération des données en attendant un caractère de terminaison plutôt qu'un nombre d'octet ?

Il se peut que tu ne récupères pas la trame commplète en 1 seul itération, pouvant générer du travail supplémentaire dans ton programme.


Cdt,

Michael.

“En science, la phrase la plus excitante que l'on peut entendre, celle qui annonce des nouvelles découvertes, ce n'est pas "Eureka" mais c'est "drôle"
Isaac ASIMOV
0 Compliments
Message 7 sur 8
4 162 Visites

Merci encore de prendre le temps de m'aider.

 

Pour tes questions :

- Je n"ai aucune référence pour ce capteur donc pas de documentation...

N'est il pas possible de modifier la récupération des données en attendant un caractère de terminaison plutôt qu'un nombre d'octet ? Si justement toutes les commandes sauf celle d'acquistion se termine par $EOT ou $KO.

 

Sinon je suis reparti de l’exemple « lire et écrire en continu. » et j'’ai réalisé un autre vi donc les commandes s'enchainent automatiquement jusqu'à l'acquisition des mesures. Il faut cliquer sur STOP pour arreter l'acquisition.

Dans ce vi, la réactivité est parfaite! mais ce n'est plus la meme facon de faire avec une chaine déroulante de choix pour lancer les commandes une à une à chaque appuie sur le bouton ENVOI

 

J'ai l'impression que c'est la meme chose mais en éclater.

Quel est la différence qui fait que l'un est réactif et l'autre pas?

 

 

Tout télécharger
0 Compliments
Message 8 sur 8
4 157 Visites