Write puis read sur port com

bonjour
voici mon code :

Code:

---

1 2 3 4 5 6 7 8 9

comport1.Connected:= true ; ComPort1.WriteStr(#$0D+#$F2+#$00+#$00+#$07...) ; Comport1.Timeouts.ReadTotalConstant := 5000; comport1.ClearBuffer(true,false); ComPort1.ReadStr( tramereponse,8); showmessage('taille : '+inttostr(length(tramereponse))); Edit1.Text:=inttohex(ord(tramereponse[1]),2); Edit2.Text:=inttohex(ord(tramereponse[2]),2); comport1.Connected:= false ;

---

l'appli se comporte comme si elle ne recevait pas de trame de réponse, sauf que je suis sûr que l'appareil répond une trame (vérif avec multicom)

ça fait deux heures que je cherche, si quelqu'un a une idée..
merci
Seb, débutant delphi
Balises code ajoutées par Laurent Dardenne

Citation:

---

Envoyé par chourmo

si quelqu'un a une idée..

---

Oui dans un premier temps utiliser les balises code !
Merci de respecter les régles des forums.

Pourquoi tu ne fais pas le Read dans le onRxChar ?

si je double clique sur OnRxChar dans l'inspecteur d'objet, il s'affiche :

Code:

---

ComPort1.ReadStr(Chaine,Count);

---

.
à la suite de cette ligne,est-ce que je rajoute ? :

Code:

---

1 2 3

Comport1.Timeouts.ReadTotalConstant := 5000; comport1.ClearBuffer(true,false); ComPort1.ReadStr( tramereponse,11);

---

mon appli amène l'utilisateur à cliquer sur un bouton pour lancer une trame, recevoir une réponse instantanée puis afficher une info selon le contenu de la réponse. pour cela, j'ai donc fait writestr puis readstr dans la procedure click du bouton. est-ce possible de tout faire comme tu me le conseilles? (du moins la réception)

Si quand tu doubles clique sur OnRxChar, il t'affiche

Code:

---

ComPort1.ReadStr(Chaine,Count);

---

, c'est normal que ton premier code de marche pas, car ce Read te prend les caractères. Cependant, même si tu enlèves cette ligne, ton premier code ne sera pas correct.

OnRxChar se déclenche lorsqu'un [ou plusieurs] caractères arrivent sur le port.

Donc, ce qu'il faut que tu fasses. Lors du clic sur le bouton, tu envoies les infos. Puis tu ne fais plus rien. Lorsque ta machine répond, elle va déclencher le onRxChar, avec, dans le paramètre Count, le nombre de caractères reçus. Donc, dans l'évènement, il faut que tu fasses un ReadStr avec le paramètres count.

voici mon code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

procedure Tfm03_DialogueRS232.btnEnvoiPersoClick(Sender: TObject); var //........ begin comport1.Connected:= true ; ComPort1.WriteStr(#$0D+#$F2+....); comport1.Connected:= false ; end;   procedure Tfm03_DialogueRS232.ComPort1RxChar(Sender: TObject; Count: Integer); Var Chaine:String; begin ComPort1.ReadStr(Chaine,count); edit1.text:=inttohex(ord(chaine[1]),2); end;

---

ça ne marche pas plus. quelle est l'influence de la ligne

Code:

---

comport1.Connected:= false ;

---

sur l'évènement onrxchar ?

Si tu déconnectes le port, il ne va rien recevoir, donc pas d'évènement onRxChar

ok j'ai enlevé cette ligne.
si j'utilise un autre PC pour envoyer la trame de réponse, je vois la led de propriété ledsignal "isrx" qui s'allume succinctement. j'ai donc reçu quelque chose. mais rien ne remplit edit1
le problème ne pourrait il pas venir du fait que j'ai à la fois le composant comdatapacket1 et comport1 ? je pense que les deux sont nécessaires mais au point où j'en suis...

Enlève le comdatapacket1, en effet, ici, c'est lui qui doit te bloquer

fait un point d'arrêt sur ComPort1RxChar et voir le contenus de count et chaine ,fait pas à pas et voir se qui ce passe.

j'ai bien mis un showmessage dans ComPort1RxChar mais je pense que le problème est du côté du timing. car si je simule la réponse avec un autre PC, le showmessage s'affiche, si je connecte mon matériel, rien ne s'affihce, peut il répondre trop vite ?

tout porte à croire que c'est le matériel qui ne marche pas mais si j'envoies la même trame avec un logiciel d'envoi de data sur port com, le matériel répond comme il faut !
et j'ai bien vérifié d'envoyer la même trame "à la main" (avec l'autre PC) ou avec mon appli

par contre y a un truc qui m'intrigue c'est que le showmessage qu'il y a dans ComPort1RxChar s'affiche deux fois quand je simule avec un autre PC. si ma réponse fait 4 octets et que le showmessage montre la taille de la répopnse, alors le showmessage affiche d'abord 1 je clique sur OK puis il affiche 3.
ça vous parle ?

merci pour le coup de pouce, à demain peut être
bonne soirée

c'est normal et je pense que MD Software peut vous expliqué mieux que moi
par contre tu peut pas nous dire le type de réponse que vs attendé ,largeur cartére de début et de fin??

je dois effectuer plusieurs dialogues successifs dont les trames sont de longueur variable.
je dois :
- rentrer en relation avec l'appareil connecté, qui me répond sa version et son n° de série, puis
- j'envoies la trame qui lui indique que je veux programmer sa 2EPROM, puis il me répond OK puis
- j'envoies la prog et il acquitte cette prog.
le format de la trame PC vers matériel est :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

(STX // de valeur #$F2 +#$.. // longueur de trame depuis le code fction jusqu'à la dernière data +#$.. // code fonction +#$00 // valeur fixe +#$00 // n° de bloc +#$00+#$00 // adresse premier octet mémoire +#$.. //nombre d'octet de la chaine data +#$.. //data +ETX // de valeur #$03 +CHK //checksum +EOT); // de valeur #$04

---

LA réponse est du même style.

l'impression que j'ai c'est que l'appareil répond trop vite pour le PC. si je simule avec un autre PC (et un logiciel d'envoi de data RS232), je vois la réponse de mon matériel instantanément. est-ce possible que le port com ne s'ouvre pas assez vite ?

après divers espionnage, je me rends compte que le problème se situe lors de l'envoi. avec mon appli, j'envoies la bonne trame (vu que je la vois sur un PC espion) mais l'appareil ne répond pas.
si j'envoies la même trame "à la main" (c'est à dire avec un logiciel d'envoi de data RS232), le matériel répond une certaine trame.
quel paramètre sur delphi en configuration d'émission de data pourrait causer ce problème ?
merci pour tout aide

que font les évènements "onRxBuf", "onRxFlag",... du comport ?

As-tu bien vérifié les paramètres de vitesse, parité et tout ce qui va avec ?

Pour les évènements, onRxFlag, survient lorsque l'état d'un indicateur du port à changé [style CTS ou RTS]. onRXBuf, c'est la même idée que onRxChar, mais au lieu de parler en caractères, il parle en buffer.

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 :wink:
moins de procedure inutilisé pour moi jutilise seulement le caratére de fin de transmission

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.

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.

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 ?

Citation:

---

Envoyé par MD Software

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:

---

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.

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

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.

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

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)

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

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

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

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

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.

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