Dialogue LabView-Instrument de mesure

[Romain.Ch]

oui en effet j'ai cherché ce à quoi correspondait cette erreur mais je n'ai pas trouvé, même sur le forum de NI, je n'ai pas trouvé de sujet correspondant à cette erreur.

Ma journée ce finie là je vais donc faire encore deux trois recherche et je te dis à demain.

[.imb]

Bonjour Romain,

Ce genre d'erreur peut arriver si le port est déjà utilisé, par une autre application, ou par LabVIEW lui-même (si il a mal été fermé par exemple). Certaines personnes semblent dire que redémarrer LabVIEW peut aider. Sinon, ce document traite du problème.

http://digital.ni.com/public.nsf/websearch/6807113B057FDE4C86256B41008212ED

Thomas

[kami_kaze]

Salut Romain,

Cela fait un moment que je travail sur un instrument de table de chez AOIP et j'avoue que ce n'était pas la joie niveau communication.

J'ai pas lu en détails toute la discussion mais j'ai rencontré a peu près tout les pb que toi.

Les principaux points a vérifier sont :

- les paramètres de ta liaison série (évidement) coté LabVIEW et coté appareil

- est ce que ton appareil doit recevoir un caractère de fin de chaine ( Retour a la ligne, retour chariot?)

- les mots clés à envoyer à ton appareil: les instructions de la norme GPIB ( IEEE 488) ne sont pas les même pour la liaison série. dans mon cas, l'instrument que j'utilise réponds plus à des instructions du type :"RUN\n?" avec RUN (l'instruction) "\n"(caractère de fin de ligne)

Un moyen simple de tester ces paramètres est d'ouvrir le NI visa-interactive control et de tester différents paramètres en fonction de ce qui est indiquer dans le manuel.

Concernant la taille de tes buffers, il faut les configurer au fur au à mesure, si tu as un time out c'est que ton buffer est trop grand ( par exemple).

[PhilB58]

En effet, après rélexion, je m'étais dis que le port avait été ouvert et mal refermé suite à tous ses essais 🙂
Le mieux est encore de rebooter l'ordi et recommencer sur une base connue plus "safe", et peut-être, avant toutes choses, vérifier si la ressource fonctionne correctement en le vérifiant dans les ressources système de Windows.

@Kami_kaze, oui, on a le datasheet de l'OM-21, et on doit dialoguer avec cet équipement en lui envoyant des commandes "ascii" ayant un format précis et se terminant par un <LF>
je lui ai fait un petit vi qui devrait lui permettre de rentrer en communication avec son OM-21, et lui envoyer une commande simple qui, si elle est reçue, produit une réponse de l'OM-21 et on devrait recevoir cette réponse, conditions minimale pour contrôler que le dialogue se fait.
Ce Vi est une adaptation d'un Vi perso qui fonctionne paraitement avec tous mes équipements sur RS-232, pas de raison que ça ne marche pas chez lui, c'est juste les commandes qui doivent être adaptées à l'OM-21, le reste, c'est de la gestion de liaison RS-232.

[Romain.Ch]

Bonjour,

Merci à tous pour tout vos conseils, en effet le faite d'avoir redémarré le PC et LabView a supprimé les erreurs liées au Buffer.

Je ne sais pas si c'est normal mais j'ai une erreur au niveau du statut qui fait que le programme ne sort jamais de la boucle mais m'affiche quand même la réponse. Aucune erreur ne s'affiche, je vais donc placer une sonde et faire quelques test, je vous tiens au courant de l'avancement.

Après essais, semblerait il que le problème soit un problème de TimeOut (1073807339) .

Au passage si je désir envoyer un ordre à l'instrument afin de définir moi même les configurations depuis labview, il me suffit d'envoyer par exemple "MODE" au lieu de "MODE?"  ?

Romain

[.imb]

Bonjour Romain,

Je pense que le problème de timeout vient du fait que la sortie de la boucle est mal gérée sur le caractère CR (voir l'image).

Il est comparé à l'ensemble de la réponse de l'appareil, et du coup, le VI continue à essayer de lire après l'arrivée du dernier caractère. Il faudrait isoler le dernier caractère de la chaîne avant de faire la comparaison.

Pour envoyer un ordre, oui cela passe par des instructions sans '?', mais il faut rajouter des paramètres après.

Thomas

[Romain.Ch]

Merci thomas, qu'entends tu par "isoler le dernier caractère de la chaine" ?

[.imb]

Quelque chose comme ça :

En entrée, tu as quelque chose de cette sorte "MEAS:8013<CR>", et en sortie, tu devrais avoir quelque chose comme '<CR>'. Tu trouveras le bout de VI que j'ai inséré dans le VI en pièce jointe.

Et après réflexion, si ma solution ne marche pas, tu peux aussi essayer l'approche que j'ai fait dans le VI planB.

MODIF, une erreur s'est glissée dans le premier VI, je modifie ça

[Romain.Ch]

Merci thomas pour les Vi, enfaite ils refont la même chose que celui de base, c'est à dire que pour corriger le timeOut il faut mettre devant le visa read un "Property Node" qui va permettre de déterminer le nombre de bytes à lire et éviter de chercher plus qu'il ne faut, mais la où je trouve ca bizarre c'est que à aucun moment je ne sort de la boucle.  

Romain

[PhilB58]

Salut,

en fait, dans le Vi que je t'ai donné, j'ai voulu trop bien faire et traiter les messages de réponses jusqu'au bout et contrôlant la présence de <CR> puis <LF> qui snt renvoyés à la fin de chaque réponse de l'OM-21.

On pourrait très bien se contenter de tester le <LF>  (ou le <CR>) à chaque boucle pour en sortir, le buffer étant vidé en sortie de boucle, le message de réponse est de toute façon "épuré" et on peut donc passer à une autre commande sans risquer d'avoir des caractères indésirables dans la réponse suivante.
Mais le noeud de propriété qui te retourne le nombre de caractères à lire (que je ne connaissais pas) peut fort bien être utilisé, avec une boucle For dans ce cas! 😉
On va y arriver, d'ailleurs on avance puisque tu as une réponse de ton OM-21 🙂