Problème : LASER ULTRA de Quantel - Lecture:OK/ Commande:OK -> ensemble non !

[GDB21]

Bonjour,

Il y a pas longtemps j'avais ouvert un post sur mon soucis de lecture des valeurs retournées par le laser ULTRA de Quantel.

Ben64 avait trouvé la solution. Bref, ça fonctionne pour la lecture. J'ai ajouté via une machine d'état toute la partie commande via des boutons du laser pour le paramétrer, l'allumer, choix de la puissance, ect. Chaque partie (Command /Querie) fonctionne indépendamment bien mais ensemble non ... cela prend trop de temps de faire le coup d'horloge et le laser s'il est allumé s'arrête car il a une interruption quelques part puis la lecture refonctionne. Je fais 30 WRITE/READ d'affilé ... que certains je traite et d'autre non... Pour arrêter par le STOP normal cela prend près de 5 sec d'arrêt ! C'est beaucoup trop pourtant j'ai aucune tempo sauf 150ms (condition constructeur)

Avez-vous une idée de la non compatibilité des 2 parties ? J'ai pensé à le mettre dans une autre boucle While mais je suis sur la même port COM donc non ...

J'ai mis le projet complet en pj.

EDIT :

Si je n'appel pas de commande, le flow continu sur les Queries mais dès que j’exécute une commande il y a une erreur (-1073807346)

et ça coupe la COM de lecture et elle reprend ensuite quleques instants après ... Donc, vu que je voudrais scanner les valeurs de T°C et donne une alerte si au-dessus de consigne ou en-dessous ... j'en aurais à chaque appel de commande car la valeur tombe à 0 quelques sec ...

[ben64]

Pour l'erreur -1073807346, c'est parce que tu ne passe pas le fil "VISA resource name" à travers tous les cas de la structure événement!

Pour le délais c'est un problème d'architecture, le wait de 150ms de la boucle while est en parallèle avec tout ce qui se passe dans la boucle, faire 30 Read/Write prend beaucoup plus que 150ms donc ici le wait est inutile.

Le bouton stop est également en parallèle avec le contenu de la boucle, donc on ne peut prévoir à quel moment il sera lu. S'il est lu au début et que son état est faux et que son état change durant cet itération de la boucle while alors la boucle exécutera une autre itération incluant 30 VISA Read/Write. C'est fort probablement de là que vient le délais de 5 secondes avant l'arrêt.

Je te suggérerais plutôt d'utiliser une architecture Producteur/Consommateur (événement) où toutes les commandes et télémétries sont effectuées dans la boucle Consommateur. La structure événement pourrait avoir un timeout de 1 seconde, dans cet état timeout tu vérifies si la file est vide si oui alors tu enfiles les 30 demandes de télémétries (crée un sous-vi pour ça) et si non tu ne fais rien. Quand tu envoies une commande tu utilises Enqueue at opposite end pour t'assurer que la commande est effectuée en priorité (ainsi la commande n'attend pas que toutes les télémétries aient été lues). Quand tu appuis sur stop dans la structure événement tu fais un Flush Queue pour vider la file.

Ben64

[GDB21]

Pour l'erreur -1073807346, c'est réglé ... j'ai oublié de câblé une paire de fil ... C'est réglé !

Par contre, je ne suis pas familier avec la structure Prod/Conso. Aurais-tu un lien documenté ? 

J'ai celui-ci :https://labviewbancdetest.wordpress.com/2011/04/27/design-pattern-producteurconsommateur/ 

Je viens de commander le Labview : Programmation et Applications ed 4, je l'attend je suppose que le sujet est abordé.

GDB

[ben64 · Accepted solution]

Il y a également ce document.

En fichier joint voici un exemple vite fait de ce que je disais.

Ben64

[GDB21]

Bonjour Ben,

Je te réponds avec un long mois de retard. J'étais sur d'autre projets...

Bref, j'ai repris le VI que tu avais mis en pièce-jointe. J'ai implémenté que la partie télémétrie (rajout des queries) sinon j'ai pas modifié les commandes afin de voir si pendant un tour, les commandes se rajoutaient bien en priorité 1 de lecture. Il semblerait qu'il fasse appuyer 2-3fois sur le bouton pour qu'elle soit lue ... As-tu une idée de la provenance de ce problème ?

En pièce-jointe le VI modifié.

Merci !

[ben64]

Je n'ai jeté qu'un coup d’œil rapide mais a priori il faudrait enlever le temps d'attente de 250 ms dans la boucle consommateur. Je l'avais mis uniquement pour que l'on voit passer la commande dans la simulation.

Note que la commande ne s'exécutera pas immédiatement, elle sera exécuter après l'opération de lecture/écriture en cours.

Ben64

[GDB21]

Salut Ben,

Alors j'ai enlevé le temps d'attente de 250ms de chaque queries dans la boucle consommateur et mis le timeout à 1 pour la boucle producteur. Les commandes ne sont jamais lues, j'ai mis des indicateurs et rien n'apparait.

Également, j'ai laissé le 2e objet du cluster 'data' même si je ne l'utilise plus au cas ou.

GDB,

[GDB21]

Autant pour moi j'avais mal linké l'action commande avec la case structure. C'est ok ça fonctionne mais dès que je fais une commande, tout les lectures READ se décalent ... Comment faire pour éviter cela ?

Merci,

[ben64]

Probablement relié à ça.

Ben64

[GDB21]

Oui mais le Trim Whitespace est déjà présent à chaque lecture comme tu me l'avais conseillé à ce post. (17 caractères dont 2 blancs)