erreur -1073807254 - erreur de "parité" communication série

[Canister31]

Ok, je vois qu'effectifement c'est pas recommandé d'en permanence ouvrir/ferme le handle de la com.

Cependant le pb ne doit pas provenir de cela, puisque je viens de tester d'apeller dans un vi seulement la fonction de save&graphe (sans mon sous-vi de tare!) et j'obtiens direct les memes erreurs de parité!

Ce que je comprend toujours pas, c'est qu'avec les modifs effectuées, j'ai effectivement deux erreurs d'un coup à chaque fois (pour chaque port) mais elles se répètent bien plus rapidement qu'auaravant (par exemple, quand j'avais posté ce post hier, cette erreur n'arrivait pas direct une fois l'éxécution enclenchée, et quand je la fermais elle mettait bien qqes secondes avant de réapparaitre, alors que maintenant, c'est quasi instantannée...)

[Canister31]

Ah et autre question, j'ai cru quelque part qu'il était possible que Labview ne prenne pas en compte certaines erreurs  (dans le sens où on lui dit d'ignorer un type d'erreur en particulier, en l'occurence ce pb de partié puisque j'ai l'impression que LabVIEW continue à enregistrer/tracer les données provenant des balances même quand ces erreurs apparaissent)

[Canister31]

plus d'idées de debugage?

[Michael.C]

Bonjour,

Oui tu peux réaliser des filtres afin d'ignorer certains types d'erreurs, mais personnellement, j'essaye d'éviter au maximum cette solution.

Pourrais tu fournir ton VI de tare, afin de comprendre la nuance entre tes deux VIs, car il n'y a pas de raison que l'un provoque des erreurs de parité et pas l'autre.

Cdt,
Michael

[Canister31]

Bonjour,

oui je susi complètement d'accord avec toi, je te joins en PJ mon vi de tare et je te remet celui pour l'enregistrement.

[Michael.C]

Bon, déjà au vue de ton programme, l'hypothèse la plus probable est que ton erreur de parité intervient au moment de la réception de données en provenance des balances.

Comme tu ne fais pas de lecture dans ton VI de tare mais seuleument un envoi de commande, cela expliquerait que tu n'es pas d'erreur dans ce sous-VI.

Si je me souviens bien, tu as réussi à faire un QUERY simple sous Max ? As tu pu reproduire de manière unitaire cette commande sous labview?

[Canister31]

Hmmm, oui tu as raison : l'erreur doit provenir des noeuds de propriété en sortie de la séquence (qui attend 500 ms). En fait, et pour répondre à ta question, je ne me souvenais plus comment réaliser un read pour qu'il prenne en compte le bon nombre de bits que l'on souhaite lire etc. Du coup, j'avais copier cette structure (avec le write/wait/noeud prop/read qu'il y a dans mon vi) depuis un des exemples LabVIEW et cela fonctionnait parfaitement quand j'avais réalisé le meme programme mais avec seulement une balance à piloter. Et quand, j'ai réalisé le code pour le pilotage de la seconde balance, j'ai directement copié/collé ce noeud de propriété pour le réaliser! 

Je pense qu'effectivement, le pb vient de ces deux noeuds de prop, et qu'il faudrait changer le code pour, soit ne pas les utiliser, soit modifier quelque chose qui ne va pas dessus (je t'avoue que même en cherchant je n'ai pas découvert on construisait ce genre de noeud de propriété fonctionnel; du moins je sais qu'il faut prendre un noeud de prop "vierge", relier le nom de ressource VISA à sa référence d'entrée puis passé la propriété en 'Number of bytes at a serial port')

Bref, je pense qu'on touche au but!:)

[Michael.C]

Ce qui me gène, c'est que de ma vue, tu as réalisé correctement ton programme :s

En effet, dans le cadre d'une communication série, il faut procéder de la manière suivante :

- Initialisation du port de communication

- Attente d'une centaine de milliseconde en cas de système lent.

- Envoi d'une commande

- Attente de minimum 50ms pour traitement de la commande (plus dépendant du système d'exécution)

- Réception d'une réponse

- Cloture du port de communication.

En ce qui concerne la réception de la réponse, c'est ici que tu vas trouver plusieurs "méthodes" de travail :

 1 - La méthode figée : Pour ta commande tu connais le nombre de Byte attendue en retour, et tu cables donc une constante à ta fonction "lecture". Ce qui bloquera ton programme sur cette fonction, tant qu'elle n'a pas reçu le bon nombre de byte ou qu'elle a dépassé son timeout.

2 - La méthode Variable : qui peut se décomposer en deux branches

    2a - Un mix avec la première méthode : Tu attends un certain temps après ta commande pour que le buffer de réception se remplisse, ensuite via le noeud de propriété "byte at port" tu viens lire la totalité de tes données. A ta charge par la suite de décomposer ta trame correctement, cette méthode provoquant des fois des réceptions de trames partielles, ou de plusieurs trames en même temps.

     2b - Dépendant directement de l'appareil visé, à voir dans la documentation, si ton appareil finit sa réponse toujours par le même caractère de terminaison, tu peux configurer ton VISA pour arrêter la lecture sur ce caractère, ainsi tu vas mettre une valeur excessivement grande sur ta constante de lecture, et ta fontion s'arrêtera dès qu'elle atteindra le nombre de byte concernée.

https://zone.ni.com/reference/en-XX/help/371361J-01/lvinstio/visa_read/

Bon courage, sans pouvoir faire de test physique, je ne te serais plus d'une grande aide.

Michael

[Canister31]

Ok, très bien je vais aller tester tout cela maintenant, je te dis ce qu'il en a été cette après-midi!

[Canister31]

Je vais essayer ta solution 2b; l'exemple que tu m'as donné sert à donner un caractère de terminaison pour l'envoi des données, le principe est exactement le meme pour la réception?? 

edit: erreur de ma part, c'est aussi effectif pour la lecture!

edit : bon j'ai tout changé mais ça n'a malheureusement rien changé, je te montre ce que j'ai fait en PJ :

y-a-t-il une erreur?

Par ailleurs je vais tenter de refaire un programme de save & graphe sans utiliser tous les noeuds de prop que j'ai mis pour mon rappel dans le main, pour voir si ça marche comme cela