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
hg
MCI, Shadok Gouroudoudou wrote:
Bonsoir !
personne au bout de la ligne ... bloqué une solution ?
La seule que j'ai trouvée : utiliser un thread. Seul le thread restera bloqué, et la partie principale du programme continuant à tourner.
-- @-salutations
Michel Claveau
Merci,
Mais que fais-tu si l'utilisateur ne re-connectes pas le matériel? ... le thread est bloqué et donc le soft ne peut, à ma connaissance, se terminer correctement.
hg
MCI, Shadok Gouroudoudou wrote:
Bonsoir !
personne au bout de la ligne ... bloqué
une solution ?
La seule que j'ai trouvée : utiliser un thread. Seul le thread restera
bloqué, et la partie principale du programme continuant à tourner.
--
@-salutations
Michel Claveau
Merci,
Mais que fais-tu si l'utilisateur ne re-connectes pas le matériel? ... le
thread est bloqué et donc le soft ne peut, à ma connaissance, se terminer
correctement.
personne au bout de la ligne ... bloqué une solution ?
La seule que j'ai trouvée : utiliser un thread. Seul le thread restera bloqué, et la partie principale du programme continuant à tourner.
-- @-salutations
Michel Claveau
Merci,
Mais que fais-tu si l'utilisateur ne re-connectes pas le matériel? ... le thread est bloqué et donc le soft ne peut, à ma connaissance, se terminer correctement.
hg
MCI, Shadok Gouroudoudou
Bonsoir !
personne au bout de la ligne ... bloqué une solution ?
La seule que j'ai trouvée : utiliser un thread. Seul le thread restera bloqué, et la partie principale du programme continuant à tourner.
-- @-salutations
Michel Claveau
Bonsoir !
personne au bout de la ligne ... bloqué
une solution ?
La seule que j'ai trouvée : utiliser un thread. Seul le thread restera
bloqué, et la partie principale du programme continuant à tourner.
Un thread, tournant ou bloqué, n'empêchera pas le programme (principal) de se terminer. Cela arrêtera le thread.
@+
MCI
Je pense que les problèmes que j'ai rencontré étaient liés à des threads bloqués sur des sockets.
La solution me rend tout de même nerveux: pleins d'effets de bords.
hg
hg
MCI, Shadok Gouroudoudou wrote:
Re !
Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous windows. Je ne l'utilise plus.
Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai dû opter pour d'autres solutions. J'en ai utilisé deux : - utiliser le composant MsComm, via PyWin32 - utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise les sockets TCP/IP pour dialoguer avec les périphériques.
Actuellement, je mise sur la dernière solution, car ça me permet une grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe quel poste du réseau, voire plus loin, via Internet ; etc.)
-- @-salutations
Michel Claveau
Merci,
Hélas pas possible pour moi ... mini-pc (TPE) qui discute avec une imprimante ticket de base (le client me tuerais si je lui demandais d'investir)
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et pourrai toujours ajouter de la tempo. si j'en rencontre.
hg
MCI, Shadok Gouroudoudou wrote:
Re !
Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous
windows. Je ne l'utilise plus.
Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai
dû opter pour d'autres solutions. J'en ai utilisé deux :
- utiliser le composant MsComm, via PyWin32
- utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise
les sockets TCP/IP pour dialoguer avec les périphériques.
Actuellement, je mise sur la dernière solution, car ça me permet une
grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe
quel poste du réseau, voire plus loin, via Internet ; etc.)
--
@-salutations
Michel Claveau
Merci,
Hélas pas possible pour moi ... mini-pc (TPE) qui discute avec une
imprimante ticket de base (le client me tuerais si je lui demandais
d'investir)
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est
déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et
pourrai toujours ajouter de la tempo. si j'en rencontre.
Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous windows. Je ne l'utilise plus.
Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai dû opter pour d'autres solutions. J'en ai utilisé deux : - utiliser le composant MsComm, via PyWin32 - utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise les sockets TCP/IP pour dialoguer avec les périphériques.
Actuellement, je mise sur la dernière solution, car ça me permet une grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe quel poste du réseau, voire plus loin, via Internet ; etc.)
-- @-salutations
Michel Claveau
Merci,
Hélas pas possible pour moi ... mini-pc (TPE) qui discute avec une imprimante ticket de base (le client me tuerais si je lui demandais d'investir)
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et pourrai toujours ajouter de la tempo. si j'en rencontre.
hg
MCI, Shadok Gouroudoudou
Re !
Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous windows. Je ne l'utilise plus.
Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai dû opter pour d'autres solutions. J'en ai utilisé deux : - utiliser le composant MsComm, via PyWin32 - utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise les sockets TCP/IP pour dialoguer avec les périphériques.
Actuellement, je mise sur la dernière solution, car ça me permet une grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe quel poste du réseau, voire plus loin, via Internet ; etc.)
-- @-salutations
Michel Claveau
Re !
Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous
windows. Je ne l'utilise plus.
Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai
dû opter pour d'autres solutions. J'en ai utilisé deux :
- utiliser le composant MsComm, via PyWin32
- utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise
les sockets TCP/IP pour dialoguer avec les périphériques.
Actuellement, je mise sur la dernière solution, car ça me permet une
grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe
quel poste du réseau, voire plus loin, via Internet ; etc.)
Pour être franc, j'ai eu pas mal de problèmes, avec PySerial sous windows. Je ne l'utilise plus.
Dans certains cas, c'était sans importance. Mais, pour d'autres, j'ai dû opter pour d'autres solutions. J'en ai utilisé deux : - utiliser le composant MsComm, via PyWin32 - utiliser des convertisseurs RS-232c <--> Ethernet, et on utilise les sockets TCP/IP pour dialoguer avec les périphériques.
Actuellement, je mise sur la dernière solution, car ça me permet une grande souplesse (ça passe par WiFi, c'est utilisable depuis n'importe quel poste du réseau, voire plus loin, via Internet ; etc.)
-- @-salutations
Michel Claveau
hg
NicolasP wrote:
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et pourrai toujours ajouter de la tempo. si j'en rencontre.
T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.
;-) oui c'est effectivement plus simple ... et puis avec mon clavier, je me brûle jamais.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?
Nicolas
hg
NicolasP wrote:
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est
déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et
pourrai toujours ajouter de la tempo. si j'en rencontre.
T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu
peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.
;-) oui c'est effectivement plus simple ... et puis avec mon clavier, je me
brûle jamais.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise
dans une appli qui ne transmet que quelques Ko de temps en temps et sans
contrôle de flux.
Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et pourrai toujours ajouter de la tempo. si j'en rencontre.
T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.
;-) oui c'est effectivement plus simple ... et puis avec mon clavier, je me brûle jamais.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?
Nicolas
hg
hg
hg wrote:
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
en fait surement pas effectivement ... l'UART devrait accepter l'XON de pydev sans crier ... et puisque aucun XOFF ne reviendra ...
je vais tester merci
hg
hg wrote:
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
en fait surement pas effectivement ... l'UART devrait accepter l'XON de
pydev sans crier ... et puisque aucun XOFF ne reviendra ...
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
en fait surement pas effectivement ... l'UART devrait accepter l'XON de pydev sans crier ... et puisque aucun XOFF ne reviendra ...
je vais tester merci
hg
NicolasP
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et pourrai toujours ajouter de la tempo. si j'en rencontre.
T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
Nicolas
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est
déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et
pourrai toujours ajouter de la tempo. si j'en rencontre.
T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
J'ai shunté le RTS/CTS, et pydev no bloque plus si l'imprimante est déconnecté. Je n'ai vu aucun problème de hand-shake (octets perdus) et pourrai toujours ajouter de la tempo. si j'en rencontre.
T'as shunté en hard, avec ton fer à souder ? Parce que si c'est le cas, tu peux désactiver la gestion de RTS/CTS dans pyserial. C'est plus simple.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
Nicolas
NicolasP
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
A priori non.
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?
Ben c'est un cas très particulier où c'est l'utilisateur qui gère. C'est une appli qui n'est pas grand public évidemment.
Nicolas
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
A priori non.
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise
dans une appli qui ne transmet que quelques Ko de temps en temps et sans
contrôle de flux.
Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?
Ben c'est un cas très particulier où c'est l'utilisateur qui gère. C'est une appli qui n'est pas grand public évidemment.
Tu ne peux pas utiliser un protocole XonXoff à la place de RTS/CTS ?
Oui (pas testé) mais n'aurais-je pas le même problème ?
A priori non.
Pour ma part, je n'ai pas eu de problèmes avec pyserial. Mais je l'utilise dans une appli qui ne transmet que quelques Ko de temps en temps et sans contrôle de flux.
Avec RTS/CTS ? si oui comment gères-tu un périphérique déconnecté ?
Ben c'est un cas très particulier où c'est l'utilisateur qui gère. C'est une appli qui n'est pas grand public évidemment.
