Port série ...Résolu

Question

Bonjour à tous,

Je cherche désespérément à envoyer des datas en hexadécimal sur un port COM en utilisant le composant Serialport sous Visual Basic 2005 Express:
Si je lance un truc du style MonPortSerie.Write("Hello"), tout fonctionne comme attendu; par contre, si je veux lui envoyer de l'hexadécimal, et bien chose qui me parait logique, il me l'interprete comme du texte, et envoie la chaine telle qu'elle est ...

Donc, si vous connaissez la commande qui va bien, je suis preneur, car ça fait trois plombes que j'essaye plein de trucs, sans résultats ..

Merci d'avance,
Dni.

cs_casy · Accepted Answer

Oui, j'avais vu ce problème d'où mon coup de gueule sur le format ASCII 8bits non supporté par .Net.

Et c'est pour cette raison que je t'avais dit aussi dans une réponse au dessus que pour ton cas, il vallait mieux laisser tomber la chaine de caractère et passer plutot sur un tableau de byte

Dim cmd As Byte() = {&H80, &HA, &H0, &H30, &H70}
PSerie.Write(cmd, 0, cmd.GetLength(0))

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_casy · Answer

Il te faut construire une chaine de caractères à partir de tes valeurs hexa

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_dni · Answer

Heuuu ... pardonne moi si ma question te semble stupide, mais tu peux être plus précis ?
Concretement, si je veux envoyer les codes hexa suivants 80 0A 00 30 70 (qui ne composent qu'une seule commande), je dois faire quoi ?

Désolé, mais je suis loin d'etre un expert, tu l'auras deviné !!! En attendant, merci pour ton coup de main;
Dni.

cs_casy · Answer

Ex :         MonPortSerie.Write(Chr(&H80) & Chr(&HA) & Chr(&H0) & Chr(&H30) & Chr(&H70))

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_dni · Answer

Arf, c'était pourtant si simple ... et moi qui cherchais déjà à faire des trucs du style:
PSerie.Encoding = System.Text.Encoding.GetEncoding(XXXX) ....

M'enfin, merci infiniement !!!!
Dni.

cs_dni · Answer

Hello evyc64 (et les autres ;-)) c'est encore moi ..
Effectivement, trop pressé de tester ta solution, je n'ai testé qu'une commande simple (sans paramètres)....
Donc, 2 choses : 

1 - mon idée du PSerie.Encoding = System.Text.Encoding.GetEncoding.Unicode 
n'était pas si mauvaise, car sans cette ligne avant la commande, rien ne se passe ... ou alors, c'est un pur hasard ... :-(

2 - si j'envoie une commande simple, style MonPortSerie.Write(Chr(&HA6)), ça fonctionne ... par contre, si j'en reviens à ma commande suivie de 4 paramètres  (80 0A 00 30 70), nada .... ça veut pas ...

Pour info, si je lance ces commande via ce soft (en activant "debug hexa"), en saisissant typiquement la chaine 80 0A 00 30 70, ben ça fonctionne .. 

A titre info, il s'agit d'un projet qui consiste à piloter une console de gestion de train : toutes les infos sur cette pages, si t'as le courage ....

Encore merci pour ton aide...
Dni.

cs_casy · Answer

Dsl, ja'i pas pu te répondre plus tot.

Je suis assez surpris que tu sois obligé de mettre un Encoding Unicode. C'est plutot de l'ascii que tu doit envoyer. Ta console doit attendre de l'ascii, alors si tu envoie de l'unicode, il semble logique qu'elle n'y comprend rien.

Mon Pc ne me permet pas de faire de tests, je n'ai qu'un port série. Je vais voir si je peux monter des ports virtuels pour faire quelques tests mais je ne te promet rien.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_casy · Answer

Bon je viens de découvrir quelque chose dans VB2005 qui met plutot désagréable.

Il semble ne pas connaitre les caractères codés en ASCII 8bits. Les seuls formats connus sont les format ASCII ou les divers formats unicode, Le format ASCII correspond au ASCII 7bits. Les caractères unicodes sont quant à eux codés sur 16 bits.
Quid du 8bits

Donc pour ton probleme, la solution est de passer plutot par un tableau d'octets, comme ceci :

        Dim cmd As Byte() = {&H80, &HA, &H0, &H30, &H70}
        PSerie.Write(cmd, 0, cmd.GetLength(0))

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_dni · Answer

Re, 
Aucun soucis, déjà que tu t'investies pour résoudre mon probleme, c'est déjà plus qu'appréciable : je ne vais pas me permettre d'être exisgeant !!!
Cependant, voici les tests que j'ai effectué depuis ta remarque à propos de l'encoding.

J'ai effectué ces tests en parallele, via mon appli, et via l'utilitaire Wdiags, en envoyant la fameuse commande 80 0A 00 30 70 et en bouclant mon port série (émission sur réception) :

- Via mon appli, envoit de la commande 80 0A 00 30 70 en Unicode ou en ASCII: c'est toujours une chaine contenant le charactère "? "qui est envoyée/reçue ... donc, l'Encoding n'a effectivement, et à ce stade, aucune influance ...
- Via Wdiags, envoit de la même commande en mode normal: la même chaine est envoyée/reçue ... 

Donc, pour l'instant c'est cohérent... sauf que si j'envoie réellement cette commande à mon périphérique, ça ne fonctionne toujours pas ... 

Le seul cas où celà fonctionne:
- Via Wdiags, envoit de la même commande en mode "debug hexa": la ça fonctionne !!!!!!! (aprés avoir cliqué sur "Debug hexa", Menu, puis définition de la trame, saisie de 80 0A 00 30 70, puis Envoie trame...)
 
La question, est donc, que fait ce mode debug hexa ???
En regardant ce coup ci ce qui est envoyé, je vois à l'émission comme à la réception la chaine suivante: 
 .:80  .:0A  .:00  0:30  p:70

Voilà où j'en suis ....: comment obtenir le même résultat avec mon aplli qui commence à me titiller ???
J'ai essayé de trouver des infos sur Wdiags, mais sans succés ...

Si tu as d'autres idées, je suis toujours preneur !!!
Denis.

cs_casy · Answer

Alors apparement il ne faut pas te fier à l'affichage de WDiags, il doit surrement proceder à une interprétation des données avant affichage.

Quoiqu'il en soit je viens de vérifier, quelque soit le mode choisit dans WDiags, c'est bien les données hexa 800a003070 qui sont envoyées.

Par contre, tu dis que l'encoding n'a aucune influence chez toi. Chez moi lorsque j'ai essayer avec une chaine de caratères (première solution que je t'avais donné) l'encoding avait une influence.
En unicode, les données envoyées étaient 8000 0a00 0000 3000 7000 ce qui est logique puisque l'unicode est codé sur 16bits, octet de poid faible en tete ( caractère chr(&h80) est donc codé 0080 et envoyé octet de poid faible en premier soit 8000)

Pour ma manip, j'ai chargé les logiciels Virtual Serial Port Driver et RS232 Com Hex Tool.

Le premier permet de monter des ports virtuels sur le PC en les rebouclant 2 à 2 come si tu mettais un cable derriere ton PC pour relier les 2 ports séries. (moi n'en ayant qu'un, je suis obliger de passer par des ports virtuels.)

Le second est un terminal à l'image de Hyperterminal, à la différence qu'il permet d'afficher les octets sous leur forme hexadécimale.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_dni · Answer

Bah ... c'est une idée ou le serveur a planté ?!? Toujours est il qu'il a mis ma réponse à la trappe ...
Donc, je disais:

En fait, et après de nouveaux essai, effectivement, tu as bel et bien raison: quelque soit le mode choisit dans WDiags, le périphérique réagit correctement ... 
A force de passer mon temps la dessus, j'en deviens abrutis ....

Sinon, comment fais tu pour lire ce qui "passe" sur le port série ? Pour ma part, une fois celui-ci connecter avec une appli, plus moyen de connecter une autre appli dessus ... ?!?

cs_casy · Answer

oui, tu as raison, une seule appli peut acceder à la fois au port. Mais avec les 2 logiciels cités, je remplace simplement ta console de gestion par le terminal. Mais c'est l'un ou l'autre, tu ne peux pas utiliser le terminal et la console en même temps.

Le terminal te permet de vérifier que ce que tu es censé envoyer à la console est correct.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

cs_dni · Answer

Ok ... bon, j'avance, doucement, mais sûrrement !!! Voilà où j'en suis: En utilisant tes deux logiciels, il s'avère que les octets envoyés par mon appli ne reflettent en rien ce que je souhaite ... Effectivement, il apparait qu'à partir du moment où j'envoie un code hexa > à 7F, celui-ci est remplacé par le code 3F .... forcément, moi qui essaye d'envoyer des "80", "A6", etc ... bref, là est le soucis!!! Du coup, en regardant le descriptif de la méthode SerialPort.Write, je me suis apperçu que, je cite: "Notes .../...Par défaut, SerialPort utilise ASCIIEncoding pour coder les caractères. ASCIIEncoding code tous les caractères supérieurs à 127 tels que (char)63 ou '?' [soit 7F en hexa ...] . Pour prendre en charge d'autres caractères dans cette plage, affectez à [ms-help://MS.VSExpressCC.v80/MS.NETFramework.v20.fr/cpref8/html/P_System_IO_Ports_SerialPort_Encoding.htm Encoding] la valeur UTF8Encoding, UTF32Encoding ou UnicodeEncoding. " Du coup, j'ai bien essayé d'autres valeurs pour encoding comme suggéré, mais ... sans meilleur résultat car la chaine émise ne correspond pas à celle que j'envoie .... En envoyant h80, j'ai les résultat suivant en fonction de l'encoding utilisé: UTF8Encoding -> E282AC UTF32Encoding -> AC200000 UnicodeEncoding -> AC20 M'enfin, là, je voie plus trop comment faire ...

cs_dni · Answer

Ben tu me crois si tu veux, mais je n'avais pas vu ta réponse concernant le tableau de Bytes.... qui effectivement résoud mon problème !!!!

Merci infiniement !!!!

Port série ...

14 réponses

Votre réponse

Discussions similaires