Port COM : plusieurs types de données

[Pierre_F]

bonjour. je souhaiterais lire sur un port serie, 2 types de données differentes, provenant d'une machine:

-un string (code barres)

-un booleen (test fructueux avant envoi du code barres)

ce qui me vient a l'esprit: concatener le booleens avec le code barres puis décortiquer le buffer après envoi. cette maniere me parait impropre.

est on obligé de faire comme cela, ou y a t il moyen de passer un type de données dans les fonctions VISA pour recuperer automatiquement les tyeps souhaites? (un peu comme le fait le DTC (database connectivity toolkit), lorsqu'on passe un cluster avec nos types en entree des fonctions de recuperation du resultat)

merci d'avance 😉

[PhilB58]

bonjour,

la communication série est assez basique et répond à un protocole bien précis!
Tu envoies une commande et tu reçois des données, à toi de les traiter comme elles doivent!
C'est dans la datasheet de ton équipement que tu auras les renseignements, mais en général, les données sont "typées", c'est à dire que chaque donnée (string, booléen, integer et autres) sont des réponses uniques, ne se mélangeant pas (le plus souvent)!
Donc, le booléen viendra seul dans une réponse, la chaine (string) viendra seule aussi!
Si ton équipement renvoie tout en même temps, tu devrais trouver le moyen de faire le tri dans la datasheet!

[ben64]

Tu peux utiliser la fonction Flatten To String pour transmettre le contenu d'un cluster.

Ici le cluster contient une chaine de caractère et un contôle booléen. Coté transmission il faut ajouter le caractère de terminaison LF (\n) (0x0A). Coté réception on récupère le cluster à l'aide de la fonction Unflatten From String à laquelle on connecte une copie de notre cluster à l'entrée "type". (je te conseille d'en faire un TypeDef et d'utiliser une constante de ce typeDef coté réception).

note: j'ai un connecteur qui relie les pin 2 et 3 du port COM sur mon portable afin de pouvoir tester en boucle ce qui est écrit sur le port COM. Je récupère très bien ce qui est transmis avec le code en exemple.

Ben64

[Pierre_F]

merci pour vos reponses!

neanmoins, une info que j'ai oublié de dire (désole), la machine en question est sous delphi.

du coup j'imagine il faut que le cluster Labview ait un type similaire aux structures Delphi. je vais quand meme essayer!

[guillaumeMa]

bonjour, 

2 questions pour ben

1/

comment fonctionne la copie du code en image. Sur certain post je peux faire glisser l'image dans un vi et le code est implémenté ,parfois seulement un lien est collé voir dessous 

2/ pour la lecture du port série si on connais pas la taille max on peux utiliser la propriété "bytes a port" pour lire exactement le nombre de byte présent sur le port 

[ben64]

@Pierre, peut une wrapper dll?

@Guillaume, je te répondrai plus tard.

Ben63

[ben64]

@Guillaume

1- Pour créer un snippet il faut sélectionner le code dans le bloc diagramme et faire edit -> create vi snippet from selection.

Avant on pouvait directement faire un drag and drop d'un snippet à partir du navigateur mais il faut maintenant télécharger sur l'image sur le PC pour ensuite faire faire un drag and drop à partir du PC. Pour télécharger l'image il faut cliquer dessus, elle s'ouvre et en bas à droite de l'image il y a un bouton carré "download image".

2- Pour moi la propriété Bytes at Port ne correspond à aucun protocole et n'a qu'une utilité, les applications de type terminal où l'on ramasse et affiche tout ce qui passe sur le port série. En utilisant Bytes at Port on peut lire ce qui est disponible même si la transmission n'est pas terminée ce qui probablement non désiré. Il n'y a donc aucune synchronisation entre la transmission et la réception. Généralement lorsqu'il y a un protocole établie c'est assez simple d'estimer la taille maximale car on connait le type de réponse attendu (un code barre + un booléen + un peu d'overhead).

Dans mon exemple, comme la communication série à été configurée avec un caractère de terminaison (valeur 0x10 ce qui correspond à un Line Feed). Dans cette configuration la fonction VISA Read.vi attendra jusqu'à ce qu'une des 3 conditions suivante soit réalisée:

1- Le caractère de terminaison a été reçu, dans ce cas le Read retournera tous les bytes reçus depuis la dernière lecture.

2- Le nombre de bytes relié à l'entrée byte count à été lu, dans ce cas le Read retournera ce nombre de bytes (et retournera un Warning qu'il est possible qu'il y ait plus de byte disponible sur le port).

3- Aucune des 2 conditions précédente n'a eu lieu dans un temps inférieure à la valeur du timeout de VISA (10 sec par défaut je crois) et la fonction VISA Read retournera une erreur.

La fonction VISA Read est faites pour attendre qu'une condition soit réalisée, il ne fait donc aucun sens d'avoir à ajouter un temps d'attente avant cette fonction pour attendre que tous les bytes aient été transmis (même si une telle méthode peut fonctionner).

Il existe d'autres protocoles série où la longueur de la chaine transmise est variable, par exemple lorsque l'on transmet le data d'un analyseur de réseau. Dans ce cas particulier le premier byte reçu correspond au nombre de bytes indiquant la taille du data à lire. Par exemple 03 01 00 01 4A 32 5B ..... Le  03 indique que les 3 prochains bytes indiquent le nombre de bytes de data à lire, 01 00 01 est égal à 65537 ce qui nous indique qu'il y a 65537 bytes de data à lire. On utilise 3 VISA Read dont les valeurs de Bytes To Read sont 1, 3 et 65537 dans ce cas.

Ben64