Discussion :

[patrice@]

Bonjour à tous,

J'ai un composant TComport (source forge) me permettant de gérer un port série. Tout va bien sauf, quand je déconnecte mon périphérique de mon port série : Une erreur est générée, j'ai fait l'acquisition de l’exception, pas de soucis, mais quand je rebranche mon périphérique, rien à faire, j'ai droit à l'erreur "PurgeComm function failed" et il faut que je reboute mon programme.
Puisqu'en reboutant mon programme le port com se remet d'aplomb, c'est que Comport doit garder quelque chose en mémoire ... mais quoi ?
Comment réinitialiser un composant ?

[SergioMaster]

Bonjour,

un port Com ça s'ouvre mais il faut aussi ne pas oublier de le refermer avant de fermer le programme.
Y a t'il une instruction de fermeture du port dans cette gestion de l'exception ?

[patrice@]

Bonjour SergioMaster,
Oui, la fonction ferme le port mais ça ne fonctionne pas
Le programme appelle toutes les secondes la fonction VisuCommunicationPortCom : une chaine est envoyée sur le port com. Si celui ci renvoie une erreur, le flag VisuCommunicationPortComErreur se mets à true, au prochain traitement, le programme demande la déconnection, la fermeture, et la reconnection. Mais ça génère l'erreur "PurgeComm function failed", donc le port ne se ferme pas. Au reboot du programme, tout va bien.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Function TForm1.VisuCommunicationPortCom:Boolean;
begin
           Try
              if VisuCommunicationPortComErreur=true
              then begin
                   ComPort1.Connected:=false;
                   Comport1.Close;
                   ComPort1.Port:=Label9.Caption; // N° du Port COM
                   Comport1.Open;
              end;
              comport1.WriteStr('0Z0Z0Z');
              Result:=true;
              VisuCommunicationPortComErreur:=false;
           Except
                 on E: CPort.EComport    
                 do begin
                    Result:=false;
                    VisuCommunicationPortComErreur:=true;
                    ComPortError(E.Code,E.Message,FlagTempoErreur);
                 end;
           End;
end;

[patrice@]

Je poursuis mes tests avec le composant COMPORT :
J'ai créé dynamiquement le composant en me disant que s'il génère une erreur persistante, je n'ai qu'à le détruire et le reconstruire.
Et ben non, il ne veut pas se détruire (ComPort1.free), il génère une exception et est pris en charge par la gestion des exception ...
Je vois bien que le sujet ne passionne pas mais si quelqu'un à une idée ...

[gaby277]

Bonjour,
Une idée au Hasard :
Pour voire ce qui se passe je te propose :
De mettre deux boutons provisoires
un pour la fermeture du port (avec une gestion d'erreur) , un pour l'ouverture(avec une gestion d'erreur) et en cas de détection d'une erreur par le programme de visualiser un message sans rien faire. Tu pourras alors manuellement fermer le port puis quelques secondes après le recouvrir.
Je me demande si l'enchainement de commandes "close" immédiatement suivi de "open" n'est pas ce qui pose probleme ..
En décomposant tu verras mieux ce qui se passe en particulier si le défaut se produit "en manuel" tu sauras avec certitude si c'est l'ouverture ou la fermeture du port qui pose problème.

J'ai recherché vite fait le message d'erreur dans le source : a priori c'est une fonction de l'Api Windows qui efface le contenu du buffer (émission (réception ?)
Peut être que Windows refuse parce qu'il y a un message a émettre (ce que tu envoies pour tester la déconnexion)
Donc avant le "close" j'essaierai de vider le buffer avec comport.clearbuffer(parametres )

[tourlourou]

Si le périphérique est déconnecté (ou reconnecté), lors de l'envoi suivant, n'essaye-t-il pas d'envoyer à un Handle qui n'est plus valide ?
Je ne sais pas si TComPort.Handle représente le Handle associé au périphérique et qui est transmis à la fonction PurgeComm de l'API Windows.
Je te suggère de tester la chose en stockant le Handle pour comparer et ne faire le test d'émission dans VisuCommunicationPortCom que 1) s'il n'a pas changé 2) si le statut est Connected.
Si cela n'évite pas l'exception non gérable, ni la solution de gaby277, ni la création dynamique/libération à chaque test, je ne vois plus quoi faire...