Envoyer une réponse ACK vers un automateRésolu

Question

Bonjour,


Je suis en train de développer un programme de communication avec un
automate de biologie le Sysmex XT-2000i qui utilise un protocol de
communication bi-directionnel et qui a besoin de recevoir une confirmation, en l'occurence ACK si c bien reçu ou NAK dans le cas contraire. Voilà comment ca se passe:

1. L'automate envoie un caractère
2. L'automate attend une réponse ACK ou NAK pour ensuite envoyer la chaine de caractères tant convoitée et qui contient les résultats

Donc ma question est:

Comment envoyer ACK via la méthode Output du contrôle de communication de VB6 MSCOMM1 ?

Dans le manuel de l'automate il mettent 06H pour ACK et 15H pour NAK

Quel devrait être la chaine de caractères + eventuellement du code ASCII à envoyer à cet automate

Je vous prie de bien vouloir prendre la peine de m'aider

Merci

cs_casy · Accepted Answer

Pour envoyer un ACK :
Mscomm1.Output = Chr$(&h06) 

Pour envoyer un NAK :
MsComm1.Output = Chr$(&h15)

Pour integer le ACK ou NAK dans une chaine que tu envoie aussi, il suffit de le rajouter à la chaine : ...= chaine & Chr$(...)

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

sigmatc24 · Answer

Merci beaucoup casy d'avoir répondu aussi vite.

Je vais tester toutes ces bonnes choses lundi car l'automate est bien entendu dans le laboratoire pour lequel je travaille et je te tiendrais au courant.

A très bientôt

sigmatc24 · Answer

Oui casy ca marche ce que tu m'as montré. Merci beaucoup.

Mais je te raconte ce qui s'est exactement passé:

Sur l'automate Sysmex XT-2000i ca n'a pas marché, par contre sur le Hitachi Elecsys 2010 qui a besoin lui aussi d'une réponse ACK, ca marche comme un charme. D'ailleurs dans mon premier message, je n'ai pas cité Hitachi mais non plus RAD-Bio, j'ai choisi le Sysmex par hasard (1 des 3 automates requiérant cette réponse ACK)

Bon ca marche sur 2 des 3 automates, que veut le peuple ? c'est déjà super.

Ce que je te demande aimablement:

Y'a t-il d'autres codes Hex pour la réponse ACK ? ou bien c'est standard pour tous les automates. je me suis dit que le Sysmex n'a peut être pas bien interprété ce que je lui envoie comme réponse ACK.
J'utilise le contrôle Mscomm1 comme tu le sais, peut-on compter sur lui pour établir une communication avec des automates pareils ?

Merci d'être patient avec moi

A+

cs_casy · Answer

Le code ACK n'est pas un standard pour les automates.

C'est une convention connue sous le nom de Norme ASCII qui nous vient des tous débuts de l'informatique et qui normalise le codage des caractères. Cette norme était surtout utilisée pour tous les systèmes fonctionnant en mode Texte notamment MSDOS pour Microsoft. Elle permet de coder 127 caractères dans sa version de base et jusqu'a 255 pour le version étendue. Les caractères 0 à 31 sont des caractères dits de controle, et permettaient à l'époque de controler les terminaux informatiques. Parmis eux les caractères ACK et NAK
Mais depuis Windows et autre système moderne sont arrivés avec des besoins autres. Ca à commencer par une modification des caractères étendus (128 à 255) puis maintenant depuis plusieurs années, à l'adoption de la norme Unicode qui code chaque caractère sur 2 octets et permet de couvrir dans une seule norme, l'ensembles des alphabets mondiaux.

Alors oui ACK et NAK sont normalisés, mais rien n'oblige un constructeur d'automate de respecter cette norme.

Rien n'empeche un constructeur de dire "- moi, ma 'séquence ack', sera l'envoie des 2 caractères RetourChariot et Saut de ligne (CR et LF, ou vbCR et vbLF pour VB, ou vbCRLF lorsqu'ils sont associés)"
Un autre pourra dire "- ben moi, j'envoie les 2 lettres O et K pour acquiter, sinon K et O en place du nak"
Dans ce cas là la seule "norme" valable est la doc de l'automate ou tout ça doit etre expliquer, car ça peut aussi etre plus complexe que ces 2 exemples.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

sigmatc24 · Answer

Merci casy pour ces informations.

J'utilise le contrôle Mscomm de microsoft pour les communications série. Peut-on lui faire confiance sachant que parfois il ne restitue pas correctement les données supposées arrivées (Des petits carrés et autres caractères ASCII aléatoires). Et parfois il ne restitue rien du tout.

Peut -tu me suggérer un autre contrôle ActiveX avec lequel tu travailles peut être ou un moyen plus efficace pour la communication série entre PC et automates.

A+

cs_casy · Answer

Je n'ai jamais eu de problème avec MSComm.

Pour les petits carrés, c'est une interprétation d'affichage. En effet les caractères "Retour Charriot", "Saut de ligne", "ACK", .... et plus largement les caractères dont le code ascii est inférieur à 32 en décimal ne sont pas des caractères affichables. Donc si tu reçois ces caractères là et que tu regarde la chaine reçue dans le débuggeur ou avec un msgbox ou autre, directement, sans aucune autre forme de traitement, Windows ne sachant pas afficher ces caractères, il met un petit carré noir à la place. Cela ne veut pas dire pour autant que le caractère n'est pas ou est mal reçu. Par contre si tu affiche leur valeur ascii, tu verra qu'ils correspondent probablement à ceux que tu dois recevoir.

Pour ce qui est des autres problèmes, cela peut venir aussi d'une mauvaise configuration de la ligne RS232. Il faut vérifier que les paramètres de Vitesse, Nombres de bits de données, Nombre de bits de Stop, Parité, soit strictement identique des 2 cotés de la ligne. En gros il faut que tu configure MsComm avec strictement les mêmes paramèters que ceux utiliser par ton automate.

Cela peut aussi venir d'une ligne de moins bonne qualité ou parasitée, ou alors d'une vitesse de traitement pas assez élevé de ton coté. Reduire la vitesse peut améliorer les choses. 
Perso, j'ai souvent eu de meilleures performances à 38400 qu'à 115200 srtout en milieu perturbé, vitesse moindre certe, mais moins de pertes ou d'erreur, donc moins de demande de retranmission et donc au final, une transmission plus rapide.
Attention à avoir une liaison avec minimum 3 fils et surtout une très très bonne masse.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

sigmatc24 · Answer

Me voici de retour casy car je ne me lasse pas de discuter avec toi. tu m'as apporté beaucoup d'informations vitales. Merci

Pour parler un peu de câblage qui est très très important comme tu l'a souligné. Et bien je t'expose ce que j' ai découvert. Normalement le schèma d'un câble série devrait être:

                            Fiche A        Fiche B
Connecteurs                    2     -->       3
                                            3     -->      2
                                            4     -->        6
                                            5     -->       5
                                            6     -->        4
                                            7     -->      8
                                            8     -->        7

Et un dernier fil (la masse qui se soude sur la fiche)

Figures toi que cette configuration ne marche pas sur les automates requiérat ACK pour envoyer le reste de la chaine. Le 1 er caractère d'initialisation que l'automate envoie n'est pas reçu dans forcément je ne peux pas renvoyer ACK, donc plus de communication.

Par hasard, il y avait un câble série quelque part, en le branchant, tout marche, je l'ai ouvert et voilà ce que je découvre comme schèma:

                            Fiche A        Fiche B

Connecteurs                   1     -->       7 | Les connecteurs 7+8 sont soudés mais le fil est soudé 
                                                                  8 | dans la position 8

Les connecteurs 7+8  | 7    <--      1                                                
sont soudés mais le     | 8
fil est soudé dans la
position 8
                                            2     -->       3

                                            3     -->      2

                                            4     -->        6

                                            5     -->       5

                                            6     -->        4

Et un dernier fil (la masse qui se soude sur la fiche)

Et ce n'est pas un harard, car cette la seule configuration qui me permet de communiquer avec des automates à voie bi-directionnelle.

Que penses tu de tout cela, et si jamais tu as un schèma de connection à me proposer, ca sera le bienvenu.

A +

cs_casy · Answer

Les fils interessants sont : 
- broche 2 : RX : Reception (Entrée)
- broche 3 : TX : Emission (Sortie)
- broche 5 : GND : Masse

Les fils sont des signaux de controles utilisés lorsque un protocole matériel est mis en place. Il existe plusieurs possibilités de branchement suivant les matériels et protcoles utilisés.
- broche 1 : CD : Détection de porteuse (Entrée)
- broche 4 : DTR : Terminal de données pret, comprendre Pret à recevoir (Sortie)
- broche 6 : DSR : Poste de données pret (Entrée)
- broche 7 : RTS : Demande d'emission (Entrée)
- broche 8 : CTS : Pret à émettre
- broche 9 : RI : Sonnerie (Entrée)

Le 1er cas que tu donne est une configuration appelée Cable NULL MODEM, utiliser notamment pour relier 2 PC entre eux.

Le 2nd cas est une autre version de cable NULL MODEM

Pour ta culture, tu peux visiter notamment ces 2 sites par exemple :
Le site de Christian Tavernier
Le site de 1100F

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #

sigmatc24 · Answer

Ok, je vais consulter ces liens, merçi

sigmatc24 · Answer

Bonjour casey,

Après plus de 2 mois d'bsence passé à programmer des communications série, en partie avec tes précieux conseils. j'aimerais savoir si tu peux m'éclairer sur un sujet:

j'ai lu dans un manuel de l'interfacage PC - Automate et pour une bonne confection d'un câble série, il faut savoir si les réglages du port de communication côté PC sont en DTE ou DCE ??

Y'a t-il un moyen de savoir si la configuration du port série côté PC est en DTE ou DCE ?

Merçi d'avance

cs_casy · Answer

Les termes DTE et DCE deviennent petit à petit inconnus car de moins en moins utilisés. De part sa configuration et de part la norme RS232 (IEEE432) un ordinateur est toujours DTE (Data Terminal Equipment)

Ensuite les équipements en face peuvent DTE ou DCE (Data Communication Equipment). Un modem par exemple doit normalement etre DCE. Mais de plus en plus de périphérique sont DTE.

La différence se fait essentiellement dans l'affectation des broches du connecteur série.

de DTE vers DCE, normalement un cable droit suffit.
de DTE vers DTE, il faut un cable croisé, dit aussi cable "null-modem", mais il existe plusieurs configuration de de cable croisés. C'est pour cela que la source d'information la plus sure est la doc du périphérique que tu connecte au PC.

---- Sevyc64  (alias Casy) ----<hr size="2" width="100%" /># LE PARTAGE EST NOTRE FORCE #    http://aide-office-vba.monforum.com/index.php

sigmatc24 · Answer

C'est exactement ce que je me disais mais j'avais besoin de la confirmation d'un connaisseur.

Donc effectivement il faut se fier au manuel du périphérique à connecter au PC.

Merci pour toutes ces précisions

cs_abdelloui · Answer

bonjour casy,

suite a votre discussion avec sigmatic je voit que vous ètes entrain de parler concernant la communication biderictionelle entre les pc et les automates de laboratoire et moi cette anneé j'ai un sujet ds ce sens je veut faire un projet d'interface graphique avec du Vb qui va echanger les donnes avec un automate de laboratoire via la communication RS232 alors s'il vout plaît si vous pouvez me donnez les démarches à suivre pour ce sujet.

Envoyer une réponse ACK vers un automate

13 réponses

Votre réponse

Discussions similaires