Mon objectif n'est pas de polluer ce forum, mais plutot d'essayer de résodre un pb par topic. A mon avis, ça sera bénéfique pour les autres forumeurs. Si j'me trompe...

Donc voilà, j'ai suivit la procédure d'installation de TComport conseillée par Jlen100 que je remercie.
Dedans, il y a 4 exemples de prog pour communiquer avec le port série RS232.

Le 1er qui ressemble à l'hyperteminal ne veut pas fonctionner chez moi : il me renvoie en permanence l'erreur "winerror code 2".
Qqun voit-il d'où ça peut venir ?

En fouillant un peu, j'ai constaté que je n'était pas le seul à rencontrer ce pb Mais je ne parviens pas à exploiter sa méthode dans mon cas

Si qqun a des idées...
Par avance merci,
Djipe.

salut,
excuses moi de ne pas t'avoir répondu ... d'autres PB à régler.
quelle est ta version de DELPHI?
ce message ressemble à une erreur E/S
regardes la conficuration de ton port (si j'ai bonne mémoire dans l'exemple le control de flux flux est en hardware ce qui n'est peut-être pas ton cas

@+
jlen

Tu n'as pas à t'excuser : c'est super cool de nous aider. Surtout que j'ai constaté que tu le fais bien.

Je tourne sous DELPHI 6.

En fait, l'exemple 1 (hyperterminal) fournit avec le composant est celui qui se rapproche le plus de mon besoin. Pour les experts, je suis en train de préparer un downloader pour PIC. Et j'ai besoin que l'appli DELPHI scrupte en permanence (sans interruption) le buffer de réception du port série. Du moins, le buffer ne doit jamaies être coupé.
Sur les 3 autres exemples, la scruptation est coupée. Et donc, j'ai peur que le buffer soit déconnecté à ce moment et donc que je perde des infos.

bonsoir;
si tu connais le format de tes trames l'utilisation du terminal n'est certainement pas la meilleure façon de procéder.
personnellement j'ai assez l'habitude de travailler avec des micro controleurs ( même si j'ai abandonné le pic depuis quelques années) et je prévilegie la scrutation par un timer 
tcomport possède un buffer et travaille avec des threads la réception est donc indépendante du programme lui même il n'y a  donc aucun risque de perte de données par le composant ( temps que la connexion est phisiquement présente et que l'on n'a pas fermer le port)
la procédure est simple dans le ontimer du scan tu mets la lecture de la totalité des données présente dans le buffer de TComport que tu traites ensuite

si tu veux un exemple vas  voir ma source PILOTAGE  4 AXES
tu trouveras dans la procédure :
procedure TModuleDeCommande.ScannerTimer(Sender: TObject);

un exemple pour la réception en double bufferisation avec traitement des données

@+
jlen

Ton lien sur le pilotage 4 axes ne fonctionne pas :-(

Je travail sur les PICs ;-)
Actuellement, je suis en train de produire un downloader sous DELPHI par ce que j'ai l'habitude de l'utiliser. Par la suite, j'envisage de le refaire en JAVA : actuellement, je migre en nunux ;-)

Demain, je vais faire un teste pour vérifier si lorsque l'on sésactive le timer, le buffer reste opérationnel.

Je te tiens informé dès que j'ai des résultats.


Sinon, as-tu une idée de pourquoi j'ai ce message d'erreur sur l'exemple 1 (terminal) ?
Peut-être que j'pourrai me servir de cette appli par la suite ;-)

Encore merci,
Djipe.

le lien est sur le site!!!
je le remets PILOTAGE 4 AXES

@+
jlen