Discussion :

[edam]

comme vous avez un caractére de fin de transmission utlise plutot ce caractére
moi jutilise une version entien de tcomport et que jéstime trés bien
moins de procedure inutilisé pour moi jutilise seulement le caratére de fin de transmission

[davinout]

Si ça marche avec un logiciel de test, c peut-être que les paramètres de ton composant TComPort dans delphi sont mauvais.. Vérifie que ce sont les mêmes que ceux qui sont utilisés avec ton logiciel qui marche.

[chourmo]

je n'ai pas accès aux paramètres du logiciel de test.
j'ai bien vérifié les paramètres de vitesse, parité, bit de stop et nombre de bits pour la liaison.

[MD Software]

Bon, pour être sûr, voilà ce qu'il faudrait faire [de manière générale]

Tu ouvres le port
Tu envois ta Trame
Tu ne fais plus rien
--------
[Tu as codé un évènement dans le onRxChar]
Le onRxChar se déclenche avec le Count qui contient le nombre de caractères. Le onRxChar peut se déclencher plusieurs fois, si d'autres infos arrivent sur le port. Donc, en principe, on n'interprète la trame reçue que lorsqu'elle a la taille qu'on attend. Tant qu'elle n'a pas la bonne taille, le code du onRxChar doit concaténer les caractères dans la trame.

Est-ce que c'est bien comme ça que tu fais ?

[chourmo]

Tu ouvres le port
Tu envois ta Trame
Tu ne fais plus rien
--------
[Tu as codé un évènement dans le onRxChar]
Le onRxChar se déclenche avec le Count qui contient le nombre de caractères. Le onRxChar peut se déclencher plusieurs fois, si d'autres infos arrivent sur le port. Donc, en principe, on n'interprète la trame reçue que lorsqu'elle a la taille qu'on attend. Tant qu'elle n'a pas la bonne taille, le code du onRxChar doit concaténer les caractères dans la trame.

Est-ce que c'est bien comme ça que tu fais ?

si je simules (comme tu me dis de faire) la réponse avec un autre PC (qui me répond une trame de 8 octets), l'évènement onRxChar ne se déclenche pas. par contre si je mets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
   comport1.Timeouts.ReadTotalConstant:=5000;
comport1.ClearBuffer(true,false);
ComPort1.ReadStr(tramereponse,8);
 edit1.Text:=inttohex(ord(tramereponse[1]),2));

à la suite de writestr (dans la procédure clickbouton qui lance writestr), ça marche si j'envoies une trame avant 5 seconces. mais ça ne marche pas avec mon appareil. par contre l'appareil répond si j'envoies des trames "à la main" avec l'autre PC. (donc l'appareil n'est pas en panne )
je me demande s'il y a pas un paramètre dans l'émission de la trame qui gêne.

[chourmo]

je suppose qu'à eventchar, je dois mettre #$F2

[chourmo]

que je mette #$F2 ou pas, ça ne change rien lors des simu avec le PC qui me répond les trames que j'attends.
c'est à dire que je reçois si j'analyse après avoir envoyé (donc les lignes de code ReadStr dans la même procédure que writestr) et non selon l'évènement onrxchar.

[MD Software]

est-ce que tu as un TComDataPacket sur ta fiche ?

[chourmo]

tu m'avais dit de l'enlever mais comme ça ne changeait rien, je l'ai remis.
je note qu'il réagit sur les même évènements que comport (normal). mais je ne vois pas quoi paramétrer de plus, (je n'ai pas mis les "startstrin et stopstring)

[MD Software]

S'il y a un TComDataPacket tu n'auras pas l'évènement onRxChar sur le TComPort

[chourmo]

effectivement, si j'enlève datacompacket, un evenement onrxchar simulé à la main, fait réagir mon appli. merci déjà pour ça.
par contre, mon matériel ne répond pas, alors que celui ci répond à des trames envoyées "à la main". soit il ne veut pas parler avec mon PC de développement (vu qu'il répond bien à mon PC de test), soit la trame que j'envoie est différente sur la forme (et non sur le fond vu que ce sont les mêmes). y a t'il d'autres paramètres pour l'envoi de data ?

"à la main" = avec un logiciel type wincom ou winterminal pour envoyer des datas RS232

[MD Software]

Tu es sûr à 200% que la trame que tu envoies est valide ?

[chourmo]

quelle soit valide ou pas, l'appareil répond à cette trame lorsqu'elle est envoyée "à la main".
je viens de me rendre compte que, quand l'appareil est reseté, il émet une trame et je la reçois ! je vais essayer une autre trame

[MD Software]

Tel que j'imagine la chose, tu envoies un trame que l'appareil ne comprend pas, donc il répond pas. Ou plus simplement, tu n'envoies pas une trame finie, donc l'appareil attend la fin.

En l'envoyant à la main, tu dois envoyer les bons caractères, mais par le code, peut-être que ce ne sont pas les bons.

[chourmo]

le fait de bien configurer comport sans ComDataPacket m'a permis de découvrir quelque chose d'intéressant :
- l'appareil répondait quelque soit la trame si celle ci était envoyée " à la main"
- l'appareil répond aux trames de mon appli si et seulement si celle ci est la première qu'il reçoit depuis son dernier reset.
c à d qu'il répond aux trames de mon appli à condition qu'elles soient bonnes ou alors que ce soit la première depuis le reset
je trouve ça vicieux
merci pour votre aide (je vous répond de chez moi donc je reprend le dev demain)
bonne fête de la musique