Discussion :

[rvzip64]

Salut tout le monde ,
je sais que le sujet a déjà été abordé , mais aprés avoir parcouru tous les topics, je n ai pas trouvé ce que je cherchais.

J'utilise le composant Tcomport, pour piloter 6 ports séries et je voudrais faire des threads différents pour attendre des trames sur les 6 ports et traité les informations.

Le problème c est que je n y arrive pas.
Voila le seul code que j ai trouvé.

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
 
var
  ComPort: TComPort;
  Events: TComEvents;
 
begin
  ComPort := TComPort.Create(nil);
  try
    ComPort.Events := [];  // do not create monitoring thread
    ComPort.Open;  // open port
    Events := [evCTS, evDSR, evRLSD];  // define events to wait for
    ComPort.WaitForEvents(Events, nil, WaitInfinite);  // wait until at least one event happens
    if evCTS in Events then
 
      WriteLn('CTS Changed');  // CTS signal changed state
    ComPort.Close;  // close port
  finally
    ComPort.Free;
  end;
end;

[lafaryan]

Tcomport si on parle bien de celui de Dejan Crnila est déjà threadé ! il te suffit donc en théorie d’instancier un Tcomport par port serie mais pb en fait ca marche pas, soit c’est du a l’api soit c’est du au systeme qui ne peut gérer plusieurs ports pour un même process…

[edam]

6 port série sur même PC,,,,, jamais vu je pense qu'il ya au max 4+2 vértuelle
pour ma part j'ai déja travailler avec deux en même temps
si votre PC contient 6 surment tu peut les utiliser tous avec Tcomport[/code]

[Sub0]

Si c'est de l'accès direct, j'utilise ZLPortIO et dans ce cas je pourrais te conseiller (tiens moi au courant).
Si c'est de la trame RS232, TComPort me semble plus approprié.
L'accès est plus difficile à gérer puisqu'il sagit d'un protocol déjà synchronisé par l'UART...

Vu ton code, il me semble qu'il sagit d'accès direct aux lignes CTS, DSR, RTS, etc...

http://www.developpez.net/forums/viewtopic.php?t=133052

[rvzip64]

En fait sur les 6 ports séries, c'est uniquement des trames RS232. Le code que j ai mis c est un code que j ai trouvé pour faire une évènement. Moi je voudrais faires de vrai thread bien séparer qui attendent une trame sur le port et qui effectuent le traitement.. Et je ne sais pas comment mis prendre.

[Mac LAK]

6 port série sur même PC,,,,, jamais vu je pense qu'il ya au max 4+2 vértuelle

Non, ça c'est une limite du DOS. Sous Win32, tu peux théoriquement aller jusqu'à 255 ports série, tout dépend du nombre de cartes série que tu rajoutes.

J'utilise le composant Tcomport, pour piloter 6 ports séries et je voudrais faire des threads différents pour attendre des trames sur les 6 ports et traité les informations.

Ca me semble normal, puisque tu torpilles directement le composant : c'est pas l'idéal. Virer les threads de contrôle non plus, d'ailleurs.

Essaie plutôt d'utiliser l'évènement TComPort.OnCTSChange, qui enverra un signal ou toute méthode adaptée à ton application pour déclencher la lecture.

[rvzip64]

Donc si je comprend bien cela veut dire que le composant Tcomport est déja threader, donc quand je reçois une trame il me déclenche un évènement, et les procédures que je met dans cet évènement vont etre exécuter dans un autre thread.

Ca me semble normal, puisque tu torpilles directement le composant : c'est pas l'idéal. Virer les threads de contrôle non plus, d'ailleurs.

Je comprends pas ce que tu veux dire.

Essaie plutôt d'utiliser l'évènement TComPort.OnCTSChange, qui enverra un signal ou toute méthode adaptée à ton application pour déclencher la lecture.

Le problème c est que je ne peux pas faire cela , étant donné que les registres de controle ne sont pas cablé sur le port série.

[WolffN]

Salut

Perso j'utilise les composants asyncpro TApdComport j'ai eu un probleme similaire, j'ai d'abord essayé d'utiliser les evt du composant mais cela pose des problèmes de synchronisation, perte d'evenement de reception de caractères si plusieurs reception simultanées

(si le composant est lui même multithreadé cela ne te garantie pas le fait que ces evt se déclenchent dans des threads à part,d'après mes tests il se déclenchent dans le thread principal de l'application d'ou la perte possible d'evt)

une solution

Code :

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

1
2
3
4
 
Application
  Gére une liste de threads
    Chaque thread gère un objet apdComPort

[rvzip64]

tu n aurais pas un bout de code pourque je comprenne un petit mieux stp

[rvzip64]

Personne n a jamais été confornté a ce problème ??

[Sub0]

Par curiosité, j'aurais bien aimé savoir l'utilité d'utiliser 6 ports séries en simultanné. Quels sont les appareils branchés, et n'y avait-il pas de solution plus ingénieuse que d'installer 6 ports série, surtout qu'il est possible de communiquer avec plusieurs appareils via le même port... Bref, pour en revenir à ton problème, sache que tu ne dois pas oublier d'initialiser les ports, en particulier spécifier l'adresse de base, le débit, la parité, données sur 7 ou 8 bits, le nombre de bits de stop, etc... Je pense qu'il faut que tous les ports fonctionnent sur la même fréquence (9,6 ou 115kbds), peut-être que ça résoudra ton problème, sait-on jamais.

Je crois que j'utiliserais la méthode proposée par WolffN, c'est-à-dire créer moi-même les threads et utiliser le thread principal du composant TComPort pour chaque port. Cela dit, il se peut que cela ne fonctionne pas super bien si le composant n'est pas prévu pour une utilisation simultannée... Comme c'était le cas avec ZLPortIO dans un sujet récent (http://www.developpez.net/forums/viewtopic.php?t=264660), nous avons été obligé d'adapter le composant pour pouvoir créer plusieurs "sessions" d'accès direct au port parrallèle.

En résumé, je pense qu'il faudrait dans un 1er temps revoir l'initialisation des ports séries, en particulier définir l'adresse de base du port et les autres spécifications (débit, parité, données, stop). D'après moi, tu n'as pas à te soucier des états des lignes de synchronisation, l'uart les gère lui-même, d'ailleurs, certains protocols n'utilisent pas toutes les lignes d'Handshaking; Le protocol "xon-xoff" par exemple ne les utilise pas. Je suppose que TComPort possède déjà les évènements appropriés (interruption matérielle fournie par l'UART) permettant de savoir lorsqu'une lecture/écriture est démarrée/finalisée.

J'espère t'avoir donné des informations constructives!

[rvzip64]

Alors je vais t en dire un peu plus , les intialisations sont tres bien faites je te rassure pour etre plus précis je vais te dire ce qu il y a sur les 6 ports COM.

COM 1: automate de vision
COM 2: automate de vision
COM 3: Automate
COM 4: Acquisition de pression
COM 5: Gestion de moteurs Pas à Pas
COM 6: lecteur de code barre

Alors si tu veux sur ma fiche j ai deja 6 Tcomports, mais le truc dont j ai peur, c est que les Tcomport ne craient pas un thread par composant, alors ma question est concrétement (avec quel bout de code), j e peux dire au 6 Tcomports de faire chacun un thread a par !

[Sub0]

Très bien!

Je suppose donc que tu as déjà testé les communications avec chaque port et vérifié que les appareils fonctionnaient correctement séparément. A présent, je te conseil d'utiliser 6 threads distincts et de créer dynamiquement l'objet TComPort pour chacun (en utilisant un nom différent). En tous les cas, c'est ce que je ferais je crois, à+

[rvzip64]

ok merci, mais vu que je suis un débutant dans les threads pourrais tu me donner un exemple si cela ne te dérange pas.

[Sub0]

http://lberne.developpez.com/delphi/Proc-Thread/

[rvzip64]

Super je vous remercie tous, et je vous tiens au courant de mon avancement.

[Sub0]

Sujet déjà résolu?

Excelent!

[Mac LAK]

Je comprends pas ce que tu veux dire.

Je parle de ces lignes de code :

Code :

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

1
2
3
4
5
6
 
    ComPort.Events := [];  // do not create monitoring thread
...
    Events := [evCTS, evDSR, evRLSD];  // define events to wait for
    ComPort.WaitForEvents(Events, nil, WaitInfinite);  // wait until at least one event happens
    if evCTS in Events then

J'utilise aussi TComPort, dans une DLL câblée à l'application principale par un thread pour chaque port COM, et j'ai jamais eu de problèmes.

Le problème c est que je ne peux pas faire cela , étant donné que les registres de controle ne sont pas cablé sur le port série.

Hein ??? Comment ça, les registres de contrôle ne sont pas câblés ?? Ce sont des UARTs 16550, ou pas ?
Si tes ports série ne gèrent pas les signaux modem, comment veux-tu arriver à monitorer ces évènements ?!?!
Je te rappelle, quand même, que la ligne CTS correspond à une broche bien distincte du connecteur SubD9, et pas à une "trame" reçue sur RX ! Tu confonds avec le signal BREAK, qui est lui uniquement sur RX.
Donc, peux-tu clarifier ce point, stp ?

[rvzip64]

Non Mac LAK, je sais bien ce que je raconte, et je sais bien que le CTS est une broche cablé !!!

L'exemple que j avais mis :

ComPort.Events := []; // do not create monitoring thread
...
Events := [evCTS, evDSR, evRLSD]; // define events to wait for
ComPort.WaitForEvents(Events, nil, WaitInfinite); // wait until at least one event happens
if evCTS in Events then

c'était uniquement pour montrer ce que j avais trouvé, et je savais que cela n' était pas le bon code, donc je vais faire comme ma dis Sub0 un thread par port COM et je mettrais le code dans ce topic.

Je met résolu, meme si cela n est pas vraiment le cas, on va dire que vous m avez bien aidé et que a mon avis je suis sur la bonne voix.

[Mac LAK]

Non Mac LAK, je sais bien ce que je raconte, et je sais bien que le CTS est une broche cablé !!!

Alors, qu'appelles-tu le registre de contrôle ? L'état des signaux modem est détecté, à la source, par un appel à WaitCommEvent. Cet appel est fait, dans TComPort, au sein des fonctions TComThread.Execute et TCustomComPort.WaitForEvent (ce dernier devant être plus ou moins en mode polling et/ou avoir son propre thread => pas bon).
Mais ça ne change pas le fait que si ton port COM n'est pas capable de gérer ces signaux de manière hard, tu peux retourner le problème dans tous les sens, tu ne détectera jamais le changement d'état de ces lignes.

Habituellement, il faut et il suffit de créer un TComPort au sein de chaque thread appelant (pas au sein de l'application principale), et ça passe tout seul...
Cependant, j'avoue avoir modifié les sources de TComPort pour ne plus avoir besoin de poser un composant sur la fiche (dans une DLL, ça le fait pas trop).
En gros, ça revient à virer TCustomComPort.ShowSetupDialog.

L'exemple que j avais mis

peut marcher s'il a un thread pour lui tout seul : simplement, après la détection de l'évènement, il faut lire/émettre sur le port.
Utiliser l'évènement OnCTSChange sert, en général, à débloquer un thread de communication dédié, pas à lire/écrire.