Discussions au sujet de NI LabVIEW

annuler
Affichage des résultats de 
Rechercher plutôt 
Vouliez-vous dire : 

disparition de valeur

Bonjour,

 

J'ai rencontré un problème bizar :smileysad:

 

j'ai une donnée qui perd sa valeur lors de l'éxécution,

en fait c'est le résultat d'une opération sur chaîne de caractère que je utilise après dans le reste de mon programme. Quant j'exécute, je ne trouve aucune valeur pour cette variable, alors que si je place une sonde ou je démare l'animation de l'exécution(lampe) je vois bien la valeur souhaitée, mais elle ne passe pas par les fils pour être utilisée dans le reste du code.

 

Y-a-t-il une solution SVP?

 

Merci

0 Compliments
Message 1 sur 7
3 178 Visites

Si je comprends bien votre description, faites une recherche de toutes les instances de cette variable pour localiser les endroits du code où elle est écrite.

 

Prière de poster votre code si cela ne résoud pas votre problème.

Message 2 sur 7
3 172 Visites

voici une capture de la partie du code où j'ai rencontré mon problème, merci

Tout télécharger
0 Compliments
Message 3 sur 7
3 161 Visites

Le problème est donc être d'un autre type que celui que j'avais supposé sans connaître le code.

 

"Avec la lampe", le code va s'exécuter lentement, laissant au four le temps de répondre à l'interrogation. En mode d'exécution normal, la lecture de la réponse du four se fera avant que celui-ci ait eu le temps de répondre.

 

Il faut donc modifier le code de manière à garantir l'arrivée de la réponse du four avant de vouloir la lire. Ceci peut se faire de différentes manières selon le comportement du four.

 

Les réponses à ces questions permettront de choisir la méthode la plus propre et efficace :

- le nombre d'octets de la réponse est-il toujours le même ?

- la réponse se termine-t-elle par un caractère de terminaison ?

 

 

PS : Les séquences empilées devraient être évitées et vous auriez avantage à la remplacer par une machine d'états (boucle while contenant une case structure).

Message 4 sur 7
3 154 Visites

je vous remercie pour votre réponse,

pour répondre à vos question je peux vous dire que:

-oui le nombre d'octet est toujours le même

-la réponse du four se t

0 Compliments
Message 5 sur 7
3 142 Visites

-la réponse du four se termine avec "\r"

 

Je vous remercie pour votre aide 🙂

0 Compliments
Message 6 sur 7
3 141 Visites

Questions :

  1. Votre VI affiche-t-il une erreur dans son état actuel ? Je vous suggère d'analyser la sortie erreur du VI VISA Read, actuellement non connectée.
  2. Quel est le rôle de la boucle while dans laquelle se trouve la lecture ? Le principe n'est-il pas - initialisation du port - envoi d'une requête au four - attente puis décodage de la réponse - libération du port ?

 

Ceci dit, puisque le four termine son envoi par un caractère de terminaison, l'option la plus efficace (parmi d'autres envisageables) est d'utiliser cette fonctionnalité :

 

  • Initialisation du port série : activer l'utilisation du caractère de terminaison (d'ailleurs activée par défaut) et définir celui-ci à "\r". Voir l'aide du VI d'initialisation : 0xD (hexa) --> 13 (décimal).
  • Lecture de la réponse du four : définir le nombre d'octets attendu à une valeur supérieure au nombre envoyé par le four. La lecture se terminera à l'arrivée du caractère de terminaison... et inclut donc une attente de la réponse du four.

 

Tout est clair ?

 

PS : Au risque de me répéter : remplacez la séquence empilée par une boucle while contenant une structure case ! A de très rares exceptions, la séquence empilée doit être bannie car, comme dans votre cas, elle ne génère pas du code évolutif et complique sa lecture. La règle générale est que cette structure doit être bannie s'il y a des liens entre les données des différentes séquences.

0 Compliments
Message 7 sur 7
3 138 Visites