From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
le 09-15-2020 09:23 AM
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
le 09-15-2020 09:43 AM
09-15-2020 09:57 AM - modifié 09-15-2020 10:13 AM
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.
09-15-2020 10:14 AM - modifié 09-15-2020 10:19 AM
le 09-15-2020 10:18 AM
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 :
le 09-15-2020 10:24 AM
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.
le 09-15-2020 11:30 AM
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:
Ben64
note: plutôt étrange et non conventionnel comme protocole
09-16-2020 04:53 AM - modifié 09-16-2020 04:55 AM
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.