Discussions au sujet de NI LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problème décalage READ/WRITE VISA

Solved!
Go to 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 Kudos
Message 1 of 18
(162 Views)
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 Kudos
Message 2 of 18
(131 Views)
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 Kudos
Message 3 of 18
(128 Views)
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 Kudos
Message 4 of 18
(122 Views)
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 Kudos
Message 5 of 18
(94 Views)
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 Kudos
Message 6 of 18
(85 Views)
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 Kudos
Message 7 of 18
(81 Views)
Highlighted

Bonjour Walker,

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

GDB

 

0 Kudos
Message 8 of 18
(72 Views)
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 Kudos
Message 9 of 18
(70 Views)
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 Kudos
Message 10 of 18
(66 Views)