Discussion :

[-Willis-]

Bonjour,

je suis en train de développer un projet pour communiquer avec un instrument de mesure. La communication se fait par un port série et étant un newbie total dans ce domaine, je coince sur le "formatage" des commandes à envoyer. Dans la doc, il est indiqué que les commandes doivent être du type:
<STX><ADR><CMD><CHKS1><CHKS2>
- STX étant le texte de départ de la commande
- ADR est l'adresse de mon appareil, par défaut 16
- CMD est la commande à envoyer, par example @ pour connaître le modèle de l'instrument
- Ensuite, c'est la que je coince, CHKS1 est le caractère ascii qui correspond à la somme des 4 bytes les plus haut du "check sum modulo 256" plus l'hexadecimal 30.
- CHKS2 est le caractère ascii qui correspond à la somme des 4 bytes les plus bas du "check sum modulo 256" plus l'hexadecimal 30.

Supposons que je veuille envoyer la commande @. J'ai quelque chose du type STX16@CHKS1CHKS2.
Le checksum de 16@ est BE=1011 1110.
Je calcule CHKS1=1011+110000(hex30)=111011 qui correspond au caractère ascii ;
Puis CHKS2=1110+110000=111110 qui correspond au caractère ascii >

Donc je devrais envoyer la commande STX16@;> sauf que ça ne marche pas...

Est-ce qu'il y une erreur dans mon raisonnement ?

Merci pour votre aide.

[Delias]

Bonjour Willis

Pour moi ce type de syntaxe: <STX><ADR><CMD><CHKS1><CHKS2> me dit que je dois envoyer 5 bytes ou caractères ascii, (byte ou char, c'est au final uniquement pour le traitement dans l'ordi et les cast, sur le port série c'est kif-kif). Chaque byte étant indiqué par une paire <>, mais cela cloche avec ton explication car tu indiques devoir envoyer "STX" pour <STX>.

Il peut y avoir beaucoup de variante, cela dépend tellement des docs. Mais tu pourrais déjà essayer avec l'adresse codée autrement càd le caractère ascii N°16.

Delias

[Delias]

Bonsoir Willis

Trois autres idées qui me sont venues entre temps:
- Le CheckSum prends en général l'ensemble de la trame, inclus le STX, ce qui donnerait un checksum de A6h dans le cas de ta trame initiale(STX16@:6).
- Il existe un encodage qui consiste à envoyer le nombre en format texte par sa représentation hexadécimale. C'est dans ce cas que l'on fait x=x+30h, mais cela n'est valable que pour les chiffres de 0 à 9, pour A à F il faut faire x=x-Ah+'A'. Est-ce que ce serait cela qui soit prévu pour l'encodage du checksum? (STX16@A6)
- Si on applique le même encodage pour l'adresse, il faudrait envoyer "10" (hexa) pour l'adresse 16 (décimale). (STX10@A0)

La vérité est probablement quelque part entre ces différentes variantes.

Et en préparant la réponse j'ai un autre checksum pour "16@": A7h (31h + 36h + 40h).

Delias

[-Willis-]

Bonjour Delias,

merci pour ton aide. Effectivement je n'ai pas pensé à remplacer l'adresse par le caractère ascii correspondant, je vais tenter.
Pour le checksum, la doc précisé que STX n'est pas pris en compte.

[Vincent PETIT]

Salut,
Je trouve un résultat différent pour le calcul du checksum.

Trame STX16@CHKS1CHKS2

16 = Adresse en décimal
@ = Commande en ASCII

-Willis-,
En lisant ce que tu as écrit, je comprends qu'on est dans le cadre d'un checksum de type : somme des bits à 1 + 0x30 (le modulo 256 c'est juste pour s'assurer de prendre que les 8 bits soit la valeur 255). La somme des bits à 1 peut aller de 0 à 8 et en ajoutant 0x30 alors tu te retrouves avec un caractère ASCII allant de '0' à '8'.

16 = 0001 0000 = 1 seul bit à 1 dans l'octet de poids fort
@ = 0100 0000 = 1 seul bit à 1 dans l'octet de poids faible

On a donc 1 + 0x30 pour le MSB = '1'
On a donc 1 + 0x30 pour le LSB = '1'

Trame STX16@11

[-Willis-]

Bonjour Vincent Petit,

effectivement le checksum pourrait bien être cela, il faudra que je vérifie lundi.
En relisant la doc, je crois comprendre que stx doit être un caractère mais ce n'est pas clair...
Si vous avez le courage d'y jeter un oeil, voilà le lien : http://products.inficon.com/GetAttac...0-7f6e17f1975c
C'est la section 5.2.1

[Delias]

Bonjour Willis

Avec une traduction aussi aléatoire, pas étonnant d'avoir des réponses dans toutes les directions:

Mon premier commentaire était correct, chaque <> représente bien un byte ou un char.

STX: est un caractère ASCII le n°2, d'être passé à côté
La trame doit se terminer par le CR, alors que beaucoup d'OS enverront autre chose (CR+LF ou LF), il est bien bien plus sûr d'utiliser la fonction d'envoi sans retour de ligne et d'ajouter manuellement le CR.
L'adresse doit être envoyée sur 1 byte, donc c'est bien \x10 qu'il faut envoyer.
Le chksum se calcule comme étant la somme des bytes d'adresse, de commande, et de datas optionnels, en modulo 256 pour rester sur 8 bits. Puis avec la manip que tu avais compris, mais mal expliqué. Ce sont les 4 bits forts de la somme auquel on ajoute 0x30, puis les 4 bits faibles de la somme ajouté également de 0x30.
La somme vaut 0x10 + 0x40 soit 0x50 -> CHKS1 = 0x35 ('5') et CHKS2 = 0x30 ('0')

Donc la trame à envoyer serait: "\x02\x10@50\r".

Delias

[-Willis-]

Oui j'aurais du commencer par mettre la doc tout de suite !
Merci encore de t'être penché dessus.
Je comprends ton calcul de checksum par contre à quoi sert le caractère \h ?

[Delias]

Bonsoir

\x00, défini le caractère ascii dont le code en hexa est 00 (chaque 0 doit être un chiffre hexa dans la plage 0..9,a..f).
\000, défini le caractère ascii dont le code en octal est 000 (chaque 0 doit être un chiffre octal dans la plage 0..7).

Je préfère la première variante, faute d'être à l'aise avec l'octal.

C'est obligatoire pour les caractères inférieurs à 0x30 qui sont des codes et non des caractères visibles (même si sur plusieurs systèmes, il existe des représentations graphiques).

Edit: J'ai été trop vite, c'est \x et pas \h, corrigé ici et dans le message précédent

Delias

[-Willis-]

Merci pour l'explication !
Je n'ai plus qu'à tester cela.
Bon dimanche

[-Willis-]

Bonjour Delias,

j'ai enfin pu tester ce que tu suggérais (désolé pour le silence radio, j'ai été pris sur un autre projet en urgence), malheureusement sans succès...
Je viens de récupérer un vi labview pour communiquer avec mon instrument, je vais regarder à l'intérieur de la filasse pour voir si je trouve comment il formate leur commande.

[Delias]

Bonjour Willis

J'ai repris la spec, et j'ai remarqué un point que j'avais zappé.

Les commandes du tableau 5.2 sont à envoyer en tant que data de la <CMD_RSP> 0x80 " Product_Specific". Ce qui fait que la commande devrait être "\x02\x10\x80@" suivit du checksum et du \r.
Sauf que dans les 8 commandes indiquées en page 5-5 sous "5.2.1.2 Command Packet Format" la commande 0x40 comme tu envoyais avant c'est déjà "Request slave to return software version string.", tu aurais déjà dû avoir quelque chose en retour de la forme "\x02\x10\41SoftwareVersionString" suivit du checksum et du \r.

Pas le temps de faire plus d'ici demain.

Delias

[-Willis-]

Bonjour Delias,

j'ai finalement réussi à communiquer avec mon appareil !
Effectivement il manquait le CMD_RSP, ensuite la commande doit être envoyée en version hexa donc @ -> \x40, ce qui donne \x02\x10\x80\x40 puis calcul du checksum -> 10+80+40 = D0.
Le chks1 vaut donc D+30 = 3D et le chks2 0+30 = 30.
Au final, il faut envoyer la commande \x02\x10\x80\x40\x3D\x30\x0D.

Merci encore pour ton aide.