Conseils organisation de mon VI

[Michael.C]

Bonjour,

N'oublies pas de mettre une temporisation de 50ms environ entre ton write, et on "byte at port". Il faut laisser le temps à ton équipement de traiter ta requête et y répondre.

Cdt,

Michael

[Desruelle_luc]

Il me semble que la réponse est dans le livre…

Ton problème vient de ton driver.

Avant de chercher à faire un code, il faut poser la question : je dois faire quoi ?

En VISA série, Faire une fonction d’initialisation.

Lors de la communication avec mon appareil, y-at ’il un caractère de fin ?

si oui le configurer à oui dans la fonction d’initialisation + définir le code ASCII du caractère

Si non le configurer à non dans la fonction d’initialisation.

Si non pour chaque commande, y-at ’il un nombre connu d’octets à lire en réponse ?

si oui le configurer dans la fonction de la commande

Si non faire une fonction qui envoie une commande, attend x ms (200ms mini) avant de récupérer le nombre d’octets dans le buffer et faire la lecture de l’ensemble des données du buffer.

A partir de cela, faire une lvlib, faire un driver (1 commande = 1 Vi) faire un VI Tree, documenter le code, faire un vi d'exemple… il y a un driver wizard.

Tu ne sais pas s’il existe un caractère de fin de réception ?

Alors cherche-le.

Tu envoies une commande, tu attends 5s, tu fais la lecture du nombre d’octets dans le buffer, et tu lies toutes les données. Alors tu affiches les « \ » code display (clic droit sur la chaîne de caractère) et tu regardes le code du dernier caractère.

Toujours le même, c'est gagné.

[Desruelle_luc]

Dans ton cas, si tu as des sauts de ligne, je ne pense pas que carriage return soit le caractère de fin, et cela explique tes problèmes.

Au hazard, que penses-tu de End of line ? soit CR/LF. (comme caractère de fin de récéption, pour la fonction init)

[Marcelito]

Merci pour vos réponses.

@Michael c'est fait j'ai rajouté une tempo même si cela ne change rien apparament.

J'ai fait le test pour rechercher le caractère de fin de réception en envoyant une commande, par exemple "C"

Réponse attendue:

$REM:Set high sensitivity!

$REM:Set Frequency to 868MHz!

$REM:Set Com parameters !

$EOT!

Au premier lancement, j'obtiens:

\r$REM:Set\shigh\ssensitivity!\r\r\n

Au 2eme 

$REM:Set\sFrequency\sto\s868MHz!\r\r\n

Au 3ème

$REM:Set\sCom\sparameters\s!\r\r\n

et au 4ème

$EOT!\r\n

Désolé Luc, je comprends bien l'histoire de caractère de fin de transmission du bouquin mais mon cas m'a l'air plus compliqué... A chaque ligne il renvoit ce caractère \r\n

Je ne peux donc pas l'utiliser pour dire que la transmission est terminée.

Je ne vois pas comment je pourrais faire autrement que de boucler jusqu'à avoir $EOT! o $KO! 

Edit: Du coup j'ai supprimé ce caractère de fin de transmission dans la fonction init et j'obtiens maintenant la réponse en entier!

[Desruelle_luc]

avec l'exemple que tu donnes cela me semble évident. la trame est composée de \r\n (End of line - et pas CR qui est \R) donc il ne peux pas être utilisé comme caractère de fin

---

Marcelito a écrit : 

\r$REM:Set\shigh\ssensitivity!\r\r\n

$REM:Set\sFrequency\sto\s868MHz!\r\r\n

$REM:Set\sCom\sparameters\s!\r\r\n

$EOT!\r\n

---

[Desruelle_luc]

tu as 3 pistes.

1) Pas de caractère de fin, donc bien mettre à False dans le VI VISA init le "Enable Termination Char" qui par défaut est à True

et

Faire une fonction qui envoie une commande, attend x ms (200ms mini) avant de récupérer le nombre d’octets dans le buffer et faire la lecture de l’ensemble des données du buffer.

tu tentes avec un wait de 1000 ms, tu regardes si tu as toutes les données, si oui, passe le wait à 500ms...

2) tu as 3 End of line pour une commande... tu peux activer le caractère de Fin, donc le End of line (et pas CR comme dans ton premier VI), et tu fais 3 Read VISA...

3) Sinon tu fais une boucle de read VISA, jusqu'à la détection de ton $EOT!\r\n.

Attention, il faut gérer les erreurs de time out, et le buffer non vide. Donc penser à faire un VISA Flush avant de faire un VISa Write.

Perso je ferai choix 2, puis 1, puis 3

[Marcelito]

Merci pour toutes ces pistes!

La solution 2 ne me plait pas dans le sens ou chaque commande donne un nombre de lignes différent. 

La solution 1 est bien, j'ai mis 500 ms ca à l'air de fonctionner. Plus bas j'ai des erreurs de dépassements...

Voici mon projet avec les dernières corrections. Il manque encore pas mal d'étapes par rapport à ce que je veux faire mais je voudrais bien débuter mon programme.

Pour la partie "mesure à vide" c'est un peu compliqué. Je lance l'acquisition avec la commande "U 0" dans une boucle for pendant 150 itérations J'obtiens des lignes comme ceci 

$RTD:000;9b;75d2;5132;0000;022b!

$RTD:000;9b;75d2;5132;0000;022b!

...

Ma valeur de mesure est à extraire de cette chaine. Et pour arreter la mesure, j'envoi la commande "R"

Merci pour votre relecture

[Marcelito]

Edit résolu problème de cablage. Désolé

J'ai essayé de reproduire le cadencement d'execution comme donné en exemple dans le livre Figure 3.62 et 3.63.

Or cela ne fonctionne pas du tout.

Au lieu d'attendre les 15 secondes demandées, le programme repart à la phase d'initialisation...

Le bouton d'arret ne fonctionne pas du tout aussi...

J'ai raté quoi?

[Desruelle_luc]

Salut, je n'ai pas eu le temps de regarder ton code, désolé. Je suis "un peu" occupé 🙂

je viens aux nouvelles, tu as finalisé tes problémes de driver?

Si oui, pour les autres problèmes, je te conseille de faire un nouveau post, et ajoute un lien dans ce dernier

A+

[Marcelito]

Bonjour Luc,

Merci de suivre ce post.

Pour les drivers, j'ai donc supprimé le caractère de fin de reception. J'obtiens maintenant le buffer en entier sans avoir besoin de passer par un registre à décalage pour concaténer les différentes chaines du buffer.

Il reste juste le driver de mesure qui n'est pas très conventionnel...

cf post du 5/03

J'aurais sinon une question pratique. Lorsqu'on veut faire passer une variable entre les différents états, j'utilise des SR.

Dans toutes les étapes, je suis obligé de cabler les SR si je veux conserver la valeur de ma variable.

J'ai un grand nombre de variables et cela commence à être compliqué tous ses fils.

 Est ce normal? Comment faites vous?

Concretement si je recupère une variable à l'état 1 et que je dois m'en servir à l'état 4 avec l'aide des SR, suis-je obligé de cabler les SR des étapes 2 et 3?

Merci