Problèmes plusieurs trames RS232

[llllSSSS]

Bonjour à tous ! 
Tout d'abord merci à ceux qui prennent le temps de me lire et aux benevoles qui vont m'aider à resoudre (je l'espère ahah) mon problème. 

Historique du code: 
Je cherche à communiquer avec un banc d'amortisseur. Ce banc communique avec une centrale qui elle communique avec mon ordinateur. 
Cette liaison entre mon ordinateur et cette centrale se fait par RS232. 
Donc j'envoie toutes mes ptites trames (d'ailleurs la communication est faite maison donc si vous avez des astuces pour simplifier le code je suis preneuse), mais...

Au lieu d'envoyer mes 12 trames, il en envoie 48! 
Oui il quadruple l'envoie!! 😞 du coup forcement le banc ne comprend pas et il bug. 😕
Pourtant je ne voie pas comment cela est possible. J'ai créé une machine d'états et une temporisation pour cadenser mon envoie de trames..
J'ai espionné la liaison via un socilloscope et voici le compte rendu des trames pour que vous visualisiez mieux. 
Je mets aussi en PJ mon code avec son control.

Si quelqun a des idées ! 🙂

Merci

Cordialement, 

Léa 

[Michael.C]

Bonjour,

Pourrais tu fournir ton sous vi d'écriture des trames.

En ce qui concerne le main, le travail est propre, tu peux sortir la fonction de tempo de 30ms de ta structure case, histoire de pas la répéter dans chaque cas.

Ta gestion de rejouer le cas en cas d'erreur ne sert à rien, puisque tu interromps ta boucle while dès la première erreur.

Pour moi, je ne vois rien qui cloche dans ce programme, il me faudrait vérifier le sous-vi pour potentiellement identifier ton bug.

[llllSSSS]

Bonjour, 
oui Oups j'avais oublier mon sous-VI.. ^^

Merci pour le code j'essaye de m'appliquer 😛 
Ok je ne savais pas pour la tempo ! je le ferai automatiquement desormais 😉

En tout cas merci pour ton retour et pour ton aide ! 🙂

cordialement, 

Léa 

[Michael.C]

Bon, c'st un peu plus brouillon là ^^

J'ai fait des modifications sur ton cas param 2.

Regarde, et fait la même chose pour le cas par défaut, ca permettra de clarifier ton diagramme, pour identifier le problème.

[llllSSSS]

Ahah Oui ! je viens de voir ton Vi ! Effectivement je ne connaissais pas les constantes Hexa du coup j'ai du user de stratagèmes pour avoir ce que je voulais. ^^

Et merci encore ! effectivement c'est encore plus propre 🙂

Je viens de tout modifier celon tes indications. 

Je mets tout en pièce jointe. 

Vois tu une erreur ressortir en particulier ?

Cordialement, 

Léa

[Michael.C]

Alors oui je pense savoir ton problème.

Tu n'es pas assez rigoureuse sur le type de tes variables. Tu mets en forme ta trame avec des variables U32 (c'est à dire codé sur 4 octets), et derrière tu envois celle-ci au format ASCII, tu vas donc avoir une troncature de tes valeurs sur un octet (mis en avant par le point rouge / noeud de coercition) lors de ton passage tableau / ascii.

Il te faut corriger cela, et bien comprendre le type de donnée attendu par ton système soit des valeurs sur 1 octet soit sur 4, mais il ne faut absolument pas mélanger les deux.

Pour changer le type de variable, clic droit, representation -> U8, et en sorti de fonction si nécessaire palette numérique transformation U8.

Enfin quand tu as regardé mon VI, tu es passé à côté de deux modifications mineures, mais qui sur un gros programme peuve apporter un gain à l'exécution :

- Ta structure Case peut gérer directement la valeur de ton paramètre, pas besoin de passer par une comparaison et un booléen.

- Lors de l'utilisation de structure "while/for", il faut sortir toutes les commandes/indicateurs, n'étant pas amené à varier lors des itérations de ta boucle. En effet, il y a un temps de traitement différent dans labview, entre lire une valeur en mémoire (tunnel d'entrée de ta boucle), et récupérer la valeur d'une commande, mettre à jour un indicateur.

Fait le point sur la cohérence au niveau de la mise en format de ta trame U8/U32, et fais le test pour voir si cela corrige ton souci.

[llllSSSS]

D'accord pour les modifs je vais regarder cela.

Par contre avec les modifications que tu m'as donné au niveau des trames, je retrouve pas du tout les bonne trames a envoyer ... 

une idée car ce n'est pas sensé changer..

[Michael.C]

Dans le cas de la trame 16 bits, je retrouve exactement la même chose.

Mais comm dit précédemment, j'ai des doutes sur la mise en forme de ta trame, pourrais tu me donner des détails sur l'objectif de ton code, car j'arrive pas à justifier les choix que tu as fait à partir de mes hypothèses.

[llllSSSS]

Non je viens de refaire ton code je retrouve pas les trames recherchées...

Ma suite de trames doit etre:

0900-02DC-B4A1-0400-0040

0900-02FC-AB00-0000-00B2

0900-02E5-B4C4-FF00-0067

0900-02E6-B466-0200-000D

0900-02E7-B4C4-FF00-0069

0900-02DE-B400-0000-009D

0900-02DD-B4C8-0000-0064

0900-0224-AC04-0000-00E5

0900-0242-9C00-0000-00E9

0700-021C-AE00-00D3

0900-0242-9C01-0000-00EA

0700-02F2-B401-00B0

Tout cela en testan avec avec 10 de strocke/ 20 d'offset/ 2 en frequence/10 nbre de cycle

Je sais que cette trame est bonne car c'est la seule que j'ai pu espionner (n'ayant aucune info sur les valeurs a envoyer au banc j'ai du faire du retro engeniering)..

[Michael.C]

Bonjour,

Je n'arrive toujours pas à comprendre le découpage que  tu cherche à appliquer pour ton champs "value".

Pourrais tu m'expliciter ton objectif ??? (découper les datas sur 2 octets, ou autre...).

En imaginant , que tu as fait cette usine juste pour découper tes U32 sur 4 octets, j'ai modifié ton VI, regarde en pièce jointe.

Je ne pense pas avancer dans le bon sens, mais tant que je n'aurai pas compris exactement la mise en forme de ta trame, je ne saurais pas t'aider.