Discussions au sujet de NI LabVIEW

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

Recetion de données via liaison série

c'est un risque en effet, mais voilà, je n'ai pas de leçon à donner 🙂 juste aider dans la mesure de mes moyens 🙂
Puis un petit Vi comme le sien, il n'y a pas trop de risque de s'y perdre s'il y a un peu de désordre 🙂 je me demande si je ne te filerais pas bien un projet que je dois faire évoluer pour que tu imagines un peu à quoi je dois faire face tous les jours 🙂
Mais bon, c'est un peu hors sujet ici, faudrait pas trop polluer !!!!

0 Compliments
Message 21 sur 31
641 Visites
0 Compliments
Message 22 sur 31
622 Visites

Au vu de la "tête" que tu fais 🙂 ça ne fonctionne pas!!!!

J'ai modifié ton Vi, regrade ce que j'ai fait, ça te donnera une idée de comment traiter un port série pour (en gros) éviter les soucis.

Je n'ai pas testé ta structure condition avec le noeud de rétroaction, j'imagine qu'elle fonctionnera une fois que ton port série répondra correctement, de toute façon, ce n'est pas le traitement des données qui pose problème en général (tu fais ce que tu veux avec les caractères reçu, il faut surtout les recevoir avant tout 🙂 ).
J'ai remplacé le "sérial frame" car je ne l'ai pas reçu avec ton Vi, c'est un .ctl, mais bon, j'ai fait pareil en moins joli (question de temps) 😉

0 Compliments
Message 23 sur 31
615 Visites

Merci Phil.

C'est bien propre ce vous avez fait , ça m'encourage ;).

n fait si vous avez remarqué mon boucle FOR , dans celle-ci je fais le traitement de données.

mon problème c'est à l'entrée de la boucle FOR le N (nombre d'itération de la boucle ) correspond à la taille du tableau (cercle rouge) hors cette taille ne cesse pas d'augmenter du coup à la fin du traitement (le traitement  en fait c'est le palayage du tableau pour trouver une trame) la fin du traitement est atteint quand i = N, on sort de la boucle et on recommence avec une nouvelle taille du tableau (ancien taille + les données qui arrivé entre temps pendant le traitement).

celà entraîne un retard d'affichage dans la Zone Data.

je veux faire de manière dynamique , comment je peux se débarrasser de cette boucle FOR. 

 

Merci  

 

 

 

 

0 Compliments
Message 24 sur 31
606 Visites

Image 😉

 

0 Compliments
Message 25 sur 31
605 Visites

Ce n'est pas la boucle for qui dérange mais la quantité de données à traiter.
Une fois traitée, une trame ne devrait plus repasser par cette boucle for, et ça devrait être gérable.
Petite modif de Vi, j'ai ajouté un indicateur chaine "trame en cours", c'est elle qui doit subir le traitement, les autres sont stockées dans "Data", elles deviennent juste indicateur de l'historique d'acquisition.
Enfin, si j'ai bien compris ce que tu demandes Smiley indifférent

0 Compliments
Message 26 sur 31
594 Visites

Ta boucle for semble bien compliquée pour ce que tu veux faire (encore une fois, si j'ai bien compris 😉 )
Tes trames sont du style

FF 55 14 04 FF FE FF FF D6 49 

FF 55 15 02 00 6E 92 36 

au format chaine de caractère.
Tu pourrais à chaque trame, oublier les FF et 55 qui semblent permanents, récupérer le troisième et faire un traitement en fonction de la valeur obtenue sans extraire plein de choses de ton tableau.

0 Compliments
Message 27 sur 31
574 Visites

Ce que vous venez de dire et totalement juste.

La boucle FOR me bloque le code car elle occupe le processus de déroulement des tâches, Du coup je dois attendre qu'elle finisse ses itérations pour revenir au corps du reste du code.

Pour les trames j'aurais besoin de toutes les infos car derrière il y a un calcul de CheckSum , pour vérifier si la trame est bonne ou non, me je laisse ça à côté. Pour le moment 😉

0 Compliments
Message 28 sur 31
568 Visites

j'ai fait une modif, ajouté un traitement de trame différent en parallèle de ta boucle for, ça devrait faire le taf 😉

Si ça marche tu bennes la boucle for qui ne sert plus à rien et complexifie inutilement le traitement.

0 Compliments
Message 29 sur 31
564 Visites

J'arrive un peu tard dans la discussion mais l'utilisation de Bytes at Port n'est habituellement pas la méthode recommandée (ça peut bien sur fonctionner mais le fait d'avoir à utiliser une temporisation entre l'écriture et la lecture démontre que ce n'est pas optimal).

 

Je n'ai pas LV2017 alors je ne peut ouvrir ton vi. Une chose que je n'ai pas vu dans les messages précédents c'est l'information si ton protocole utilise un caractère de terminaison (généralement \n ou \n\r). S'il y en a un alors on utilise la fonction VISA Read avec un nombre de bytes à lire plus grand que ce qu'on ne recevra jamais (la fonction VISA Read s'arrête lorsque le caractère de terminaison est détecté ou lorsque le nombre de bytes à lire est obtenu) pour lire la trame complète.

 

S'il n'y a pas de caractères de terminaison alors selon le protocole on fait des lectures successives: première lecture 3 bytes (header+ID -frame), deuxième lecture un byte (Data-Lenght), troisième lecture "Data-Lenght" bytes et finalement une quatrième lecture du nombre de bytes du CRC.

 

Ça résume plus ou moins cet excellent message de RavensFan sur le forum anglais.

 

Ben64

0 Compliments
Message 30 sur 31
544 Visites