Problème décalage READ/WRITE VISA

[ben64]

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

[ben64]

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 

[GDB21]

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.

[ben64]

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?

[Walker34]

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 :

[GDB21]

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

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

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.

[ben64 · Accepted solution]

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

Ben64

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

[GDB21]

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.

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.