Je developpe une appli avec dialogue sur port COM.
Jamais fait ce genre de choses et il y a deux trois petites choses qui
me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branch=E9 sur le port
COM. ?!?
- Soit, dans une fonction =E0 part, j'ecris donc un ordre et attends la
r=E9ception pour v=E9rifier qu'il y a l=92=E9quipement =E0 l'autre bout.
Apres c'est message en cas de pepin ou continuation si OK.
Dans les 2 cas, fermeture du port COM. (Le tout etant dans une
proc=E9dure d'auto-test appel=E9e au debut du programme).
En cas de succ=E8s, lorsque je r=E9-ouvre mon port COM un peu plus loin,
le souvre() ne fonctionne plus (acces refus=E9).
Par contre, si je deroule le code en mode debug aucun probl=E8me.
Y'a t-il une latence pour que le syst=E8me ferme r=E9ellement le port COM
apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ?
(les outils habituels de Microsoft (entre autre) ne fonctionnent pas
sur Seven)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Romain PETIT
a écrit :
Bonjour
Bonjour,
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
Normal.
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l'équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme). En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème. Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
Non, c'est très probablement ton appli qui ne ferme pas le port. Tu es sûr de bien fermer ? (sFerme et non fFerme, N° du port com au lieu du N° donné par sOuvre etc....)
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
tjfromparis@gmail.com a écrit :
Bonjour
Bonjour,
- souvre() me retourne OK meme si je n'ai rien de branché sur le port
COM. ?!?
Normal.
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la
réception pour vérifier qu'il y a l'équipement à l'autre bout.
Apres c'est message en cas de pepin ou continuation si OK.
Dans les 2 cas, fermeture du port COM. (Le tout etant dans une
procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin,
le souvre() ne fonctionne plus (acces refusé).
Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM
apres que je lui envoi l'ordre de le faire ?
Non, c'est très probablement ton appli qui ne ferme pas le port.
Tu es sûr de bien fermer ? (sFerme et non fFerme, N° du port com au
lieu du N° donné par sOuvre etc....)
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
Normal.
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l'équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme). En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème. Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
Non, c'est très probablement ton appli qui ne ferme pas le port. Tu es sûr de bien fermer ? (sFerme et non fFerme, N° du port com au lieu du N° donné par sOuvre etc....)
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Romain PETIT
Non, c'est très probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le réouvrir ? Garde le ouvert.
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Non, c'est très probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le réouvrir ?
Garde le ouvert.
A+
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
Non, c'est très probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le réouvrir ? Garde le ouvert.
A+
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Fredo
Le 03/09/2011 08:04, Romain PETIT a écrit :
Non, c'est très probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le réouvrir ? Garde le ouvert.
A+
Salut,
Si tu n'es pas sous seven, il existe un freeware génial (aspycom) qui permet d'espionner les communications rs232.
Tu sélectionne ton port com, tu passe en mode transparent et tu peux voir tous les échanges entre ton pc et ta bascule.
Bon dev.
Fred
Le 03/09/2011 08:04, Romain PETIT a écrit :
Non, c'est très probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le réouvrir ?
Garde le ouvert.
A+
Salut,
Si tu n'es pas sous seven, il existe un freeware génial (aspycom) qui
permet d'espionner les communications rs232.
Tu sélectionne ton port com, tu passe en mode transparent et tu peux
voir tous les échanges entre ton pc et ta bascule.
Non, c'est très probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le réouvrir ? Garde le ouvert.
A+
Salut,
Si tu n'es pas sous seven, il existe un freeware génial (aspycom) qui permet d'espionner les communications rs232.
Tu sélectionne ton port com, tu passe en mode transparent et tu peux voir tous les échanges entre ton pc et ta bascule.
Bon dev.
Fred
tjfromparis
Je suis sous Seven, donc pour aspycom c'est mort. En fait, c'est mort pour tous les softs que je connais. phenomene curieux : les petits de MS fonctionnent tous sur seven sauf celui pour le port COM.
Pour l'ouverture du port com qui peut se faire sans rien dessus, me doutais que c'etait normal. Du coup, je cherche à je contacter l'automate au bout pour verifier s'il est là.
J'ouvre donc mon port com , si ok j'envoi un message à l'automate, en fonction de la reponse je sais s'il est au bout ou pas. Je ferme le COM. Tout ca dans le debut du projet (inutile d'aller plus loin si l'automate ne repond pas)
En mode debug ca fonctionne impeccable, mais en mode test (sans pas à pas) lorsque j'ouvre le port COM (apres le test d'existence) j'ai une erreur : "Ouverture impossible". c''est comme si j'essayais d'ouvrir le port com alors que le systeme n'avait pas encore eu le temps de le fermer. Evidemment, multitache temporise etc ne reglent pas mon probleme.
On 5 sep, 08:46, Fredo wrote:
Le 03/09/2011 08:04, Romain PETIT a crit :
>> Non, c'est tr s probablement ton appli qui ne ferme pas le port.
> Mais au fait, pourquoi fermes tu ce port pour le r ouvrir ? > Garde le ouvert.
> A+
Salut,
Si tu n'es pas sous seven, il existe un freeware g nial (aspycom) qui permet d'espionner les communications rs232.
Tu s lectionne ton port com, tu passe en mode transparent et tu peux voir tous les changes entre ton pc et ta bascule.
Bon dev.
Fred
Je suis sous Seven, donc pour aspycom c'est mort. En fait, c'est mort
pour tous les softs que je connais. phenomene curieux : les petits de
MS fonctionnent tous sur seven sauf celui pour le port COM.
Pour l'ouverture du port com qui peut se faire sans rien dessus, me
doutais que c'etait normal. Du coup, je cherche à je contacter
l'automate au bout pour verifier s'il est là.
J'ouvre donc mon port com , si ok j'envoi un message à l'automate, en
fonction de la reponse je sais s'il est au bout ou pas. Je ferme le
COM.
Tout ca dans le debut du projet (inutile d'aller plus loin si
l'automate ne repond pas)
En mode debug ca fonctionne impeccable, mais en mode test (sans pas à
pas) lorsque j'ouvre le port COM (apres le test d'existence) j'ai une
erreur : "Ouverture impossible".
c''est comme si j'essayais d'ouvrir le port com alors que le systeme
n'avait pas encore eu le temps de le fermer.
Evidemment, multitache temporise etc ne reglent pas mon probleme.
On 5 sep, 08:46, Fredo <Fr...@gb-informatique.com> wrote:
Le 03/09/2011 08:04, Romain PETIT a crit :
>> Non, c'est tr s probablement ton appli qui ne ferme pas le port.
> Mais au fait, pourquoi fermes tu ce port pour le r ouvrir ?
> Garde le ouvert.
> A+
Salut,
Si tu n'es pas sous seven, il existe un freeware g nial (aspycom) qui
permet d'espionner les communications rs232.
Tu s lectionne ton port com, tu passe en mode transparent et tu peux
voir tous les changes entre ton pc et ta bascule.
Je suis sous Seven, donc pour aspycom c'est mort. En fait, c'est mort pour tous les softs que je connais. phenomene curieux : les petits de MS fonctionnent tous sur seven sauf celui pour le port COM.
Pour l'ouverture du port com qui peut se faire sans rien dessus, me doutais que c'etait normal. Du coup, je cherche à je contacter l'automate au bout pour verifier s'il est là.
J'ouvre donc mon port com , si ok j'envoi un message à l'automate, en fonction de la reponse je sais s'il est au bout ou pas. Je ferme le COM. Tout ca dans le debut du projet (inutile d'aller plus loin si l'automate ne repond pas)
En mode debug ca fonctionne impeccable, mais en mode test (sans pas à pas) lorsque j'ouvre le port COM (apres le test d'existence) j'ai une erreur : "Ouverture impossible". c''est comme si j'essayais d'ouvrir le port com alors que le systeme n'avait pas encore eu le temps de le fermer. Evidemment, multitache temporise etc ne reglent pas mon probleme.
On 5 sep, 08:46, Fredo wrote:
Le 03/09/2011 08:04, Romain PETIT a crit :
>> Non, c'est tr s probablement ton appli qui ne ferme pas le port.
> Mais au fait, pourquoi fermes tu ce port pour le r ouvrir ? > Garde le ouvert.
> A+
Salut,
Si tu n'es pas sous seven, il existe un freeware g nial (aspycom) qui permet d'espionner les communications rs232.
Tu s lectionne ton port com, tu passe en mode transparent et tu peux voir tous les changes entre ton pc et ta bascule.
Bon dev.
Fred
Cyrille
Bonjour,
Pour toute communication sur un port quelconque (COM ou autre) il faut définir un protocole pour communiquer entre les 2 appareils. Il existe des protocoles standards de communication sur port COM.
Pour savoir si ton appareil est branché de l'autre coté, il faut définir le message d'acceuil (shakehand) pour être sur que tu causes bien au bon appareil à l'autre bout. Si rien n'est branché tu aura une erreur de timeout de toute façon. Si c'est bien ton appareil qui a répondu tu peux alors commencer la communication.
Le 02/09/2011 22:27, a écrit :
Bonjour
Je developpe une appli avec dialogue sur port COM. Jamais fait ce genre de choses et il y a deux trois petites choses qui me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l’équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ? (les outils habituels de Microsoft (entre autre) ne fonctionnent pas sur Seven)
Merci
Bonjour,
Pour toute communication sur un port quelconque (COM ou autre) il faut
définir un protocole pour communiquer entre les 2 appareils.
Il existe des protocoles standards de communication sur port COM.
Pour savoir si ton appareil est branché de l'autre coté, il faut définir
le message d'acceuil (shakehand) pour être sur que tu causes bien au bon
appareil à l'autre bout.
Si rien n'est branché tu aura une erreur de timeout de toute façon.
Si c'est bien ton appareil qui a répondu tu peux alors commencer la
communication.
Le 02/09/2011 22:27, tjfromparis@gmail.com a écrit :
Bonjour
Je developpe une appli avec dialogue sur port COM.
Jamais fait ce genre de choses et il y a deux trois petites choses qui
me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port
COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la
réception pour vérifier qu'il y a l’équipement à l'autre bout.
Apres c'est message en cas de pepin ou continuation si OK.
Dans les 2 cas, fermeture du port COM. (Le tout etant dans une
procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin,
le souvre() ne fonctionne plus (acces refusé).
Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM
apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ?
(les outils habituels de Microsoft (entre autre) ne fonctionnent pas
sur Seven)
Pour toute communication sur un port quelconque (COM ou autre) il faut définir un protocole pour communiquer entre les 2 appareils. Il existe des protocoles standards de communication sur port COM.
Pour savoir si ton appareil est branché de l'autre coté, il faut définir le message d'acceuil (shakehand) pour être sur que tu causes bien au bon appareil à l'autre bout. Si rien n'est branché tu aura une erreur de timeout de toute façon. Si c'est bien ton appareil qui a répondu tu peux alors commencer la communication.
Le 02/09/2011 22:27, a écrit :
Bonjour
Je developpe une appli avec dialogue sur port COM. Jamais fait ce genre de choses et il y a deux trois petites choses qui me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l’équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ? (les outils habituels de Microsoft (entre autre) ne fonctionnent pas sur Seven)
Merci
Fredo
Le 05/09/2011 09:04, a écrit :
Je suis sous Seven, donc pour aspycom c'est mort. En fait, c'est mort pour tous les softs que je connais. phenomene curieux : les petits de MS fonctionnent tous sur seven sauf celui pour le port COM.
Pour l'ouverture du port com qui peut se faire sans rien dessus, me doutais que c'etait normal. Du coup, je cherche à je contacter l'automate au bout pour verifier s'il est là.
J'ouvre donc mon port com , si ok j'envoi un message à l'automate, en fonction de la reponse je sais s'il est au bout ou pas. Je ferme le COM. Tout ca dans le debut du projet (inutile d'aller plus loin si l'automate ne repond pas)
En mode debug ca fonctionne impeccable, mais en mode test (sans pas à pas) lorsque j'ouvre le port COM (apres le test d'existence) j'ai une erreur : "Ouverture impossible". c''est comme si j'essayais d'ouvrir le port com alors que le systeme n'avait pas encore eu le temps de le fermer. Evidemment, multitache temporise etc ne reglent pas mon probleme.
On 5 sep, 08:46, Fredo wrote:
Le 03/09/2011 08:04, Romain PETIT a crit :
Non, c'est tr s probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le r ouvrir ? Garde le ouvert.
A+
Salut,
Si tu n'es pas sous seven, il existe un freeware g nial (aspycom) qui permet d'espionner les communications rs232.
Tu s lectionne ton port com, tu passe en mode transparent et tu peux voir tous les changes entre ton pc et ta bascule.
Bon dev.
Fred
Salut,
Pense à une chose, ... la lecture / écriture série, c'est lent et donc si ça marche en mode débug c'est que tu laisse à la communication le temps de se faire.
Rajoute des tempos entre les lectures & ecritures.
Idem pour la lecture, généralement on place le slit dans une boucle car ce n'est pas évident que tu reçoive ton message entier au moment ou tu fait ta lecture.
du style
Chrono(1) TimeOut est une duree = 300 Tantque ChronoValeur(1) < timeoOut MaChaine += sLit(nocom,sDansFileEntree(nocom)) si position(machaine,caractFin) > 0 alors sortir multitache(5) fin
CaractFin = trame de fin de message de ta basculle
fin
Bon dev,
Fred.
Le 05/09/2011 09:04, tjfromparis@gmail.com a écrit :
Je suis sous Seven, donc pour aspycom c'est mort. En fait, c'est mort
pour tous les softs que je connais. phenomene curieux : les petits de
MS fonctionnent tous sur seven sauf celui pour le port COM.
Pour l'ouverture du port com qui peut se faire sans rien dessus, me
doutais que c'etait normal. Du coup, je cherche à je contacter
l'automate au bout pour verifier s'il est là.
J'ouvre donc mon port com , si ok j'envoi un message à l'automate, en
fonction de la reponse je sais s'il est au bout ou pas. Je ferme le
COM.
Tout ca dans le debut du projet (inutile d'aller plus loin si
l'automate ne repond pas)
En mode debug ca fonctionne impeccable, mais en mode test (sans pas à
pas) lorsque j'ouvre le port COM (apres le test d'existence) j'ai une
erreur : "Ouverture impossible".
c''est comme si j'essayais d'ouvrir le port com alors que le systeme
n'avait pas encore eu le temps de le fermer.
Evidemment, multitache temporise etc ne reglent pas mon probleme.
On 5 sep, 08:46, Fredo<Fr...@gb-informatique.com> wrote:
Le 03/09/2011 08:04, Romain PETIT a crit :
Non, c'est tr s probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le r ouvrir ?
Garde le ouvert.
A+
Salut,
Si tu n'es pas sous seven, il existe un freeware g nial (aspycom) qui
permet d'espionner les communications rs232.
Tu s lectionne ton port com, tu passe en mode transparent et tu peux
voir tous les changes entre ton pc et ta bascule.
Bon dev.
Fred
Salut,
Pense à une chose, ... la lecture / écriture série, c'est lent et donc
si ça marche en mode débug c'est que tu laisse à la communication le
temps de se faire.
Rajoute des tempos entre les lectures & ecritures.
Idem pour la lecture, généralement on place le slit dans une boucle car
ce n'est pas évident que tu reçoive ton message entier au moment ou tu
fait ta lecture.
du style
Chrono(1)
TimeOut est une duree = 300
Tantque ChronoValeur(1) < timeoOut
MaChaine += sLit(nocom,sDansFileEntree(nocom))
si position(machaine,caractFin) > 0 alors sortir
multitache(5)
fin
CaractFin = trame de fin de message de ta basculle
Je suis sous Seven, donc pour aspycom c'est mort. En fait, c'est mort pour tous les softs que je connais. phenomene curieux : les petits de MS fonctionnent tous sur seven sauf celui pour le port COM.
Pour l'ouverture du port com qui peut se faire sans rien dessus, me doutais que c'etait normal. Du coup, je cherche à je contacter l'automate au bout pour verifier s'il est là.
J'ouvre donc mon port com , si ok j'envoi un message à l'automate, en fonction de la reponse je sais s'il est au bout ou pas. Je ferme le COM. Tout ca dans le debut du projet (inutile d'aller plus loin si l'automate ne repond pas)
En mode debug ca fonctionne impeccable, mais en mode test (sans pas à pas) lorsque j'ouvre le port COM (apres le test d'existence) j'ai une erreur : "Ouverture impossible". c''est comme si j'essayais d'ouvrir le port com alors que le systeme n'avait pas encore eu le temps de le fermer. Evidemment, multitache temporise etc ne reglent pas mon probleme.
On 5 sep, 08:46, Fredo wrote:
Le 03/09/2011 08:04, Romain PETIT a crit :
Non, c'est tr s probablement ton appli qui ne ferme pas le port.
Mais au fait, pourquoi fermes tu ce port pour le r ouvrir ? Garde le ouvert.
A+
Salut,
Si tu n'es pas sous seven, il existe un freeware g nial (aspycom) qui permet d'espionner les communications rs232.
Tu s lectionne ton port com, tu passe en mode transparent et tu peux voir tous les changes entre ton pc et ta bascule.
Bon dev.
Fred
Salut,
Pense à une chose, ... la lecture / écriture série, c'est lent et donc si ça marche en mode débug c'est que tu laisse à la communication le temps de se faire.
Rajoute des tempos entre les lectures & ecritures.
Idem pour la lecture, généralement on place le slit dans une boucle car ce n'est pas évident que tu reçoive ton message entier au moment ou tu fait ta lecture.
du style
Chrono(1) TimeOut est une duree = 300 Tantque ChronoValeur(1) < timeoOut MaChaine += sLit(nocom,sDansFileEntree(nocom)) si position(machaine,caractFin) > 0 alors sortir multitache(5) fin
CaractFin = trame de fin de message de ta basculle
fin
Bon dev,
Fred.
Fredo
Le 05/09/2011 09:16, Cyrille a écrit :
Bonjour,
Pour toute communication sur un port quelconque (COM ou autre) il faut définir un protocole pour communiquer entre les 2 appareils. Il existe des protocoles standards de communication sur port COM.
Pour savoir si ton appareil est branché de l'autre coté, il faut définir le message d'acceuil (shakehand) pour être sur que tu causes bien au bon appareil à l'autre bout. Si rien n'est branché tu aura une erreur de timeout de toute façon. Si c'est bien ton appareil qui a répondu tu peux alors commencer la communication.
Le 02/09/2011 22:27, a écrit :
Bonjour
Je developpe une appli avec dialogue sur port COM. Jamais fait ce genre de choses et il y a deux trois petites choses qui me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l’équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ? (les outils habituels de Microsoft (entre autre) ne fonctionnent pas sur Seven)
Merci
Salut,
Attention, toutes les communications séries ne sont pas forcément à double sens. Dans le cas d'une imprimante ticket, si tu ne gère pas les erreurs, la communication est à sens unique, ... sOuvre, sEcrit, sFerme et sur certains capteurs c'est l'inverse, Slecture uniquement si il y'a des données dans le buffer.
Fred
Le 05/09/2011 09:16, Cyrille a écrit :
Bonjour,
Pour toute communication sur un port quelconque (COM ou autre) il faut
définir un protocole pour communiquer entre les 2 appareils.
Il existe des protocoles standards de communication sur port COM.
Pour savoir si ton appareil est branché de l'autre coté, il faut définir
le message d'acceuil (shakehand) pour être sur que tu causes bien au bon
appareil à l'autre bout.
Si rien n'est branché tu aura une erreur de timeout de toute façon.
Si c'est bien ton appareil qui a répondu tu peux alors commencer la
communication.
Le 02/09/2011 22:27, tjfromparis@gmail.com a écrit :
Bonjour
Je developpe une appli avec dialogue sur port COM.
Jamais fait ce genre de choses et il y a deux trois petites choses qui
me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port
COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la
réception pour vérifier qu'il y a l’équipement à l'autre bout.
Apres c'est message en cas de pepin ou continuation si OK.
Dans les 2 cas, fermeture du port COM. (Le tout etant dans une
procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin,
le souvre() ne fonctionne plus (acces refusé).
Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM
apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ?
(les outils habituels de Microsoft (entre autre) ne fonctionnent pas
sur Seven)
Merci
Salut,
Attention, toutes les communications séries ne sont pas forcément à
double sens. Dans le cas d'une imprimante ticket, si tu ne gère pas les
erreurs, la communication est à sens unique, ... sOuvre, sEcrit, sFerme
et sur certains capteurs c'est l'inverse, Slecture uniquement si il y'a
des données dans le buffer.
Pour toute communication sur un port quelconque (COM ou autre) il faut définir un protocole pour communiquer entre les 2 appareils. Il existe des protocoles standards de communication sur port COM.
Pour savoir si ton appareil est branché de l'autre coté, il faut définir le message d'acceuil (shakehand) pour être sur que tu causes bien au bon appareil à l'autre bout. Si rien n'est branché tu aura une erreur de timeout de toute façon. Si c'est bien ton appareil qui a répondu tu peux alors commencer la communication.
Le 02/09/2011 22:27, a écrit :
Bonjour
Je developpe une appli avec dialogue sur port COM. Jamais fait ce genre de choses et il y a deux trois petites choses qui me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l’équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ? (les outils habituels de Microsoft (entre autre) ne fonctionnent pas sur Seven)
Merci
Salut,
Attention, toutes les communications séries ne sont pas forcément à double sens. Dans le cas d'une imprimante ticket, si tu ne gère pas les erreurs, la communication est à sens unique, ... sOuvre, sEcrit, sFerme et sur certains capteurs c'est l'inverse, Slecture uniquement si il y'a des données dans le buffer.
Fred
JeAn-PhI
a formulé ce vendredi :
Bonjour
Je developpe une appli avec dialogue sur port COM. Jamais fait ce genre de choses et il y a deux trois petites choses qui me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l’équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ? (les outils habituels de Microsoft (entre autre) ne fonctionnent pas sur Seven)
Merci
http://www.serial-port-monitor.com/ en version free
-- Cordialement JeAn-PhI
tjfromparis@gmail.com a formulé ce vendredi :
Bonjour
Je developpe une appli avec dialogue sur port COM.
Jamais fait ce genre de choses et il y a deux trois petites choses qui
me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port
COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la
réception pour vérifier qu'il y a l’équipement à l'autre bout.
Apres c'est message en cas de pepin ou continuation si OK.
Dans les 2 cas, fermeture du port COM. (Le tout etant dans une
procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin,
le souvre() ne fonctionne plus (acces refusé).
Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM
apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ?
(les outils habituels de Microsoft (entre autre) ne fonctionnent pas
sur Seven)
Merci
http://www.serial-port-monitor.com/ en version free
Je developpe une appli avec dialogue sur port COM. Jamais fait ce genre de choses et il y a deux trois petites choses qui me chiffonnent :
- souvre() me retourne OK meme si je n'ai rien de branché sur le port COM. ?!?
- Soit, dans une fonction à part, j'ecris donc un ordre et attends la réception pour vérifier qu'il y a l’équipement à l'autre bout. Apres c'est message en cas de pepin ou continuation si OK. Dans les 2 cas, fermeture du port COM. (Le tout etant dans une procédure d'auto-test appelée au debut du programme).
En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin, le souvre() ne fonctionne plus (acces refusé). Par contre, si je deroule le code en mode debug aucun problème.
Y'a t-il une latence pour que le système ferme réellement le port COM apres que je lui envoi l'ordre de le faire ?
connaissez vous un soft qui permet de savoir qui occupe un port COM ? (les outils habituels de Microsoft (entre autre) ne fonctionnent pas sur Seven)
Merci
http://www.serial-port-monitor.com/ en version free
-- Cordialement JeAn-PhI
tjfromparis
Bonjour,
@Jean-Phil : merci. C'est celui là que j'ai trouvé.
Pour la difference de comportement entre mode debug et mode compilé, je me doutais que c'etait une histoire de tempo. J'ai modifié en conséquence.
Merci à vous.
On 5 sep, 11:00, JeAn-PhI wrote:
a formulé ce vendredi :
> Bonjour
> Je developpe une appli avec dialogue sur port COM. > Jamais fait ce genre de choses et il y a deux trois petites choses qui > me chiffonnent :
> - souvre() me retourne OK meme si je n'ai rien de branché sur le port > COM. ?!?
> - Soit, dans une fonction à part, j'ecris donc un ordre et attends la > réception pour vérifier qu'il y a léquipement à l'autre bout . > Apres c'est message en cas de pepin ou continuation si OK. > Dans les 2 cas, fermeture du port COM. (Le tout etant dans une > procédure d'auto-test appelée au debut du programme).
> En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin , > le souvre() ne fonctionne plus (acces refusé). > Par contre, si je deroule le code en mode debug aucun problème.
> Y'a t-il une latence pour que le système ferme réellement le port C OM > apres que je lui envoi l'ordre de le faire ?
> connaissez vous un soft qui permet de savoir qui occupe un port COM ? > (les outils habituels de Microsoft (entre autre) ne fonctionnent pas > sur Seven)
> Merci
http://www.serial-port-monitor.com/en version free
-- Cordialement JeAn-PhI
Bonjour,
@Jean-Phil : merci. C'est celui là que j'ai trouvé.
Pour la difference de comportement entre mode debug et mode compilé,
je me doutais que c'etait une histoire de tempo. J'ai modifié en
conséquence.
Merci à vous.
On 5 sep, 11:00, JeAn-PhI <nos...@nospam.fr> wrote:
tjfrompa...@gmail.com a formulé ce vendredi :
> Bonjour
> Je developpe une appli avec dialogue sur port COM.
> Jamais fait ce genre de choses et il y a deux trois petites choses qui
> me chiffonnent :
> - souvre() me retourne OK meme si je n'ai rien de branché sur le port
> COM. ?!?
> - Soit, dans une fonction à part, j'ecris donc un ordre et attends la
> réception pour vérifier qu'il y a léquipement à l'autre bout .
> Apres c'est message en cas de pepin ou continuation si OK.
> Dans les 2 cas, fermeture du port COM. (Le tout etant dans une
> procédure d'auto-test appelée au debut du programme).
> En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin ,
> le souvre() ne fonctionne plus (acces refusé).
> Par contre, si je deroule le code en mode debug aucun problème.
> Y'a t-il une latence pour que le système ferme réellement le port C OM
> apres que je lui envoi l'ordre de le faire ?
> connaissez vous un soft qui permet de savoir qui occupe un port COM ?
> (les outils habituels de Microsoft (entre autre) ne fonctionnent pas
> sur Seven)
> Merci
http://www.serial-port-monitor.com/en version free
@Jean-Phil : merci. C'est celui là que j'ai trouvé.
Pour la difference de comportement entre mode debug et mode compilé, je me doutais que c'etait une histoire de tempo. J'ai modifié en conséquence.
Merci à vous.
On 5 sep, 11:00, JeAn-PhI wrote:
a formulé ce vendredi :
> Bonjour
> Je developpe une appli avec dialogue sur port COM. > Jamais fait ce genre de choses et il y a deux trois petites choses qui > me chiffonnent :
> - souvre() me retourne OK meme si je n'ai rien de branché sur le port > COM. ?!?
> - Soit, dans une fonction à part, j'ecris donc un ordre et attends la > réception pour vérifier qu'il y a léquipement à l'autre bout . > Apres c'est message en cas de pepin ou continuation si OK. > Dans les 2 cas, fermeture du port COM. (Le tout etant dans une > procédure d'auto-test appelée au debut du programme).
> En cas de succès, lorsque je ré-ouvre mon port COM un peu plus loin , > le souvre() ne fonctionne plus (acces refusé). > Par contre, si je deroule le code en mode debug aucun problème.
> Y'a t-il une latence pour que le système ferme réellement le port C OM > apres que je lui envoi l'ordre de le faire ?
> connaissez vous un soft qui permet de savoir qui occupe un port COM ? > (les outils habituels de Microsoft (entre autre) ne fonctionnent pas > sur Seven)
> Merci
http://www.serial-port-monitor.com/en version free