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

La source du décalage devrait probablement trouver explication dans le manuel de l'usager. Pourquoi y aurait-il du data avant la première commande? L'appareil envoie-t-il quelque chose lorsqu'on initialise une communication série? Dans ce cas le Flush I/O Buffer du début (que je disais de conserver) devrait éliminer ce décalage. Je serais surpris qu'il y ait un \n sans \r dans le data. Autre chose possible à essayer: avant la première commande un pourrait insérer un noeud Bytes at Port et lire ce data (si > 0) et voir de quoi il s'agit.

 

Ben64

0 Kudos
Message 11 of 18
(713 Views)

J'ai regardé rapidement le manuel et il est recommandé d'utiliser un temps d'attente minimum de 150 ms entre les commandes. Ce pourrait être un problème.

 

Ben64 

0 Kudos
Message 12 of 18
(707 Views)

En effet, j'avais lu cette indication aussi mais le Wait 150ms n'est pas suffisant ?

Alors mettre un Time Delay en Flat sequence ... ?, ou alors le Stall data flow (j'ai très peu utilisé ce dernier ...)

 

Edit : Même avec la flat sequence et les Time Delay, le premier WRITE et READ pour FLOW retourne une chaine vide qui donc me décale tout je pense.

0 Kudos
Message 13 of 18
(703 Views)

Le stall data flow est préférable.

 

Edit: il y a donc un \r\n présent avant la première lecture. Tu as essayé ce que j'ai proposé dans mon message précédent? Garder le 1er flush buffer ou utiliser le noeud bytes at port?

0 Kudos
Message 14 of 18
(694 Views)

Le timeout entre l'envoi et la réception de chaque trame.

 

Par exemple avec une stack sequence, ou bien le vi Wait de la librairie OpenG :

 

Walker34_0-1600183063759.png

 

0 Kudos
Message 15 of 18
(690 Views)

J'ai testé avec le Stall Data Flow idem ...

Le READ du FLOW arrive dans le 2e READ et décale les autres.Capture6.JPG

 

PS: j'ai remis le FLUSH avant le premier WRITE et un Stall data flow de 150ms mais j'ai juste perdu le READ de FLOW qui est maintenant à \r\n.

0 Kudos
Message 16 of 18
(684 Views)
Solution
Accepted by topic author GDB21

OK j'ai trouvé!

 

Extrait du manuel:

 

To query a value: Send the command with no extra characters
followed by a carriage return and line feed. The ICE450 responds by
sending a CR, LF and a 15-character string of information, which is an
ASCII-formatted representation of the requested value with as many
spaces as required to make the string 15 characters.

 

Donc lorsque l'instrument répond il commence en envoyant \r\n, donc ce n'est pas utilisé comme caractère de terminaison (et c'est donc pour ça qu'il y a décalage).

 

Voici ce que je propose pour régler ça:

  • On met Enable Termination Character à FAUX
  • On lit 17 caractères (Bytes to Read) et on élimine les espaces blancs au début et à la fin à l'aide du vi Trim Whitespace de la palette String

Trim Whitespace.png

 

Ben64

 

note: plutôt étrange et non conventionnel comme protocole

 

Message 17 of 18
(673 Views)

Merci Ben !!

 

Honte à moi de ne pas avoir tout lu ou assez bien lu le user manual ...

 

En effet, j'ai appliqué ce que tu m'as conseillé et cela fonctionne maintenant. Sauf si je fais un Abort, il décale d'un cran il faut bien entendu fermer les VISA proprement et après ils reviennent à la normale.

 

Capture7.JPG

 

PS: il n'y a pas de FLUSH I/O, ni de Clear et juste un Wait de 150ms. Les WRITE/READ sont mis à la suite.

0 Kudos
Message 18 of 18
(664 Views)