Discussions au sujet de NI LabVIEW

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

Problème décalage READ/WRITE VISA

Résolu !
Accéder à la solution
Highlighted

Bonjour,

 

J'ai un soucis pour la lecture des VISA Read. Je dialogue avec un laser Ultra de Lumibird via les commandes rs232 propriétaires.

Via un hyperterminal comme Termite, je n'ai aucun soucis mais sous labview oui ...

Il me retourne bien des valeurs mais elles sont tronquées je n'ai que la moitié de la valeur attendue. Puis, si je demande trois WRITE/READ le dernier se retrouve affiché dans le premier appel ...

Le Bytes at Port, ne m'affiche rien ... chaque fois que je l'utilise il ne fonctionne pas alors je mets en dure... mais même en testant plusieurs valeurs je n'ai toujours que la moitié de la valeur.

CaptureLabview.PNGCaptureLabview2.PNG

 

CaptureLabview3.PNG

 

Merci pour votre aide !

GDB

0 Compliments
Message 1 sur 18
309 Visites
Highlighted

Bon, je vais y aller d'une hypothèse: Les constantes de chaîne de caractères sont en mode d'affichage Normal. Si on les convertie en mode Code alors FLOW\r\n devient FLOW\\r\\n ce qui peut expliquer les problèmes de communication.

 

solutions possibles: change le mode d'affichage pour code display avant d'écrire les commandes ou utilise la fonction concaténation comme dans l'image suivante:

 

VISA Read.png

 

Ben64

--------------------------------------------------
The best way to say thanks is to give kudos!
0 Compliments
Message 2 sur 18
278 Visites
Highlighted

Merci Ben de ta remarque, c'est vrai j'ai oublié d'afficher les Display Style des indicateurs et commandes. Par contre, tout est bien sûr en \ Code. Donc c'est pas çà. J'ai en effet eu le soucis avec le doublage des \\ mais ce n'est pas le cas ici.

CaptureLabview4.PNG

GDB

0 Compliments
Message 3 sur 18
275 Visites
Highlighted

Ce que j'essaierais: garder uniquement le Flush I/O buffer du début et ajouter un délais de 300 ms avant d'envoyer la première commande, éliminer les autres Flush I/O buffer (il n'y en a pas lorsque tu utilises Termite). Le Bytes at Port qui retourne 0 ne m'inquiète pas, il est immédiatement après l'envoi de la commande alors il est possible qu'il n'y ait encore rien dans le return buffer. Essaie également de monitorer les échanges à l'aide de NI I/O Trace (dans MAX -> Logiciels)

 

Ben64

--------------------------------------------------
The best way to say thanks is to give kudos!
0 Compliments
Message 4 sur 18
269 Visites
Highlighted

Dans la doc, il parle de laisser au moins 150ms. J'ai finalement enlever tout les FLUSH I/O. Je peux récupérer l'intégralité du message mais pas dans les bons indicateurs... J'ai joué sur le Byte Count et à 32bits tout ce positionne bien pour 3 WRITE/READ et 45bits pour 4 WRITE/READ. Puis si je Abort ou lieu de Close le VISA au redémarrage, la lecture ce décale d'un cran aléatoirement.C'est de la pifométrie et j'aime pas trop cela ... J'ai du enlever les Clear également sinon je perdais la lecture du prochain WRITE. Je n'ai ni donc de Flush ni de Clear. Je me souviens de mettre fait taper sur les doigts car c'était plus rigoureux et propre de les utiliser... Pourtant là cela marche mieux sans ...

 

CaptureLabview5.PNG

0 Compliments
Message 5 sur 18
241 Visites
Highlighted

Par défaut le vi VISA Configure Serial Port  a les entrées Enable Terminal Character = TRUE et Terminal Character = 10 (\n).

 

Dans ce cas le vi VISA Read attend en mode lecture que la première des 3 conditions suivantes se réalise:

  • l'arrivée du termination character \n
  • le nombre de bytes lu est égal à la valeur reliée à l'entrée Bytes at Port
  • un VISA timeout (10 secondes par défaut)

 

Comme ici le termination character est enabled (T), il suffirait normalement d'utiliser une valeur Bytes at Port supérieure à la plus longue chaine que l'on pourrait recevoir. Il faudrait également s'assurer que l'appareil envoie bien ce caractère de terminaison (\n). Il semble utiliser \r\n ce qui n'est pas un problème à moins que parfois l'appareil envoie \n sans le \r, alors il y aura décalage dans les lectures. Il faut noter qu'il n'est pas possible d'utiliser 2 caractères de terminaison \r\n avec la fonction VISA Read.

 

Les utilitaires de type terminal (Termite, Hyperterminal, ...) fonctionnent différemment ils n'utilisent pas de caractère de terminaison et de timeout. Ils sont en mode lecture en continu du nombre de bytes at port dans une boucle while: si aucun byte alors délai et revérification du nombre de bytes at port, s'il y en a de disponible alors affichage. C'est utile mais pas pour extraire le message reçu à d'autres fins.

 

Ben64

 

--------------------------------------------------
The best way to say thanks is to give kudos!
0 Compliments
Message 6 sur 18
232 Visites
Highlighted

 

Pourquoi ne pas simplement attendre la fin réponse attendue? Selon ce que je vois, l'appareil termine sa réponse par \r\n? 

 

Est-ce que ça fonctionne mieux avec une boucle d'attente de ce genre ? :

 

Walker34_0-1600173900773.png

 

 

0 Compliments
Message 7 sur 18
228 Visites
Highlighted

Bonjour Walker,

J'ai testé ta solution mais j'ai très rapidement un e erreur Timeout du Visa READ.

GDB

 

0 Compliments
Message 8 sur 18
219 Visites
Highlighted

 

ah je remarque dans mon exemple il faut inverser la condition de sortie de la boucle while. Il faut continuer (et non pas stopper) tant que le résultat de la recherche du \r\n >= 0. 

0 Compliments
Message 9 sur 18
217 Visites
Highlighted

Même avec le >=0 j'ai le timeout aussi. (j'ai testé par acquis de conscience les autres cas, idem arrêt immédiat)

0 Compliments
Message 10 sur 18
213 Visites