Discussions au sujet de NI LabVIEW
Problème décalage READ/WRITE VISA
Résolu !
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.
Merci pour votre aide !
GDB
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:
Ben64
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.
GDB
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
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 ...
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
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 ? :
