Bonjour,
Est-il possible qu'une réception sur le port série génère une
interruption dans un script python sous windows 10 ? j'utilise python
2.7.15 et bottle pour l'interface utilisateur et j'aimerais qu'une lecture
du port série ne soit pas bloquante, une sorte de fonction
onSerialEvent()...
Merci pour toute suggestion !
Bonjour,
Est-il possible qu'une réception sur le port série génère une
interruption dans un script python sous windows 10 ? j'utilise python
2.7.15 et bottle pour l'interface utilisateur et j'aimerais qu'une lecture
du port série ne soit pas bloquante, une sorte de fonction
onSerialEvent()...
Merci pour toute suggestion !
Bonjour,
Est-il possible qu'une réception sur le port série génère une
interruption dans un script python sous windows 10 ? j'utilise python
2.7.15 et bottle pour l'interface utilisateur et j'aimerais qu'une lecture
du port série ne soit pas bloquante, une sorte de fonction
onSerialEvent()...
Merci pour toute suggestion !
Une interruption et un serveur WEB ne sont pas vraiment du même monde.
Quel est le cas d'usage ?
En fonction de ce que vous voulez faire, les solutions ne seront pas les
mêmes.
Une interruption et un serveur WEB ne sont pas vraiment du même monde.
Quel est le cas d'usage ?
En fonction de ce que vous voulez faire, les solutions ne seront pas les
mêmes.
Une interruption et un serveur WEB ne sont pas vraiment du même monde.
Quel est le cas d'usage ?
En fonction de ce que vous voulez faire, les solutions ne seront pas les
mêmes.
Le 28/01/2019 à 08:58, Nicolas a écrit :Une interruption et un serveur WEB ne sont pas vraiment du même monde.
Quel est le cas d'usage ?
En fonction de ce que vous voulez faire, les solutions ne seront pas les
mêmes.
C'est pour un banc de contrôle. Les instruments ramènent des infos par
les ports séries. L'utilisateur peut aussi scanner des données avec un
lecteur de code barres. L'interface utilisateur permet de choisir des
options de réglages ou entrer des paramètres de calibration. S'il était
possible que le port série génère une interruption cela aurait
l'avantage de simplifier l'interface utilisateur. Par exemple si
l'utilisateur scanne un document le programme pourrait l'orienter
directement en fonction du document scanné.
Le 28/01/2019 à 08:58, Nicolas a écrit :
Une interruption et un serveur WEB ne sont pas vraiment du même monde.
Quel est le cas d'usage ?
En fonction de ce que vous voulez faire, les solutions ne seront pas les
mêmes.
C'est pour un banc de contrôle. Les instruments ramènent des infos par
les ports séries. L'utilisateur peut aussi scanner des données avec un
lecteur de code barres. L'interface utilisateur permet de choisir des
options de réglages ou entrer des paramètres de calibration. S'il était
possible que le port série génère une interruption cela aurait
l'avantage de simplifier l'interface utilisateur. Par exemple si
l'utilisateur scanne un document le programme pourrait l'orienter
directement en fonction du document scanné.
Le 28/01/2019 à 08:58, Nicolas a écrit :Une interruption et un serveur WEB ne sont pas vraiment du même monde.
Quel est le cas d'usage ?
En fonction de ce que vous voulez faire, les solutions ne seront pas les
mêmes.
C'est pour un banc de contrôle. Les instruments ramènent des infos par
les ports séries. L'utilisateur peut aussi scanner des données avec un
lecteur de code barres. L'interface utilisateur permet de choisir des
options de réglages ou entrer des paramètres de calibration. S'il était
possible que le port série génère une interruption cela aurait
l'avantage de simplifier l'interface utilisateur. Par exemple si
l'utilisateur scanne un document le programme pourrait l'orienter
directement en fonction du document scanné.
<petite digression>
Perso, je fais des bancs de contrôle avec des applications desktop
(basées sur wxPython), pas avec des technos WEB. Les technos WEB sont
très à la mode mais, à mon avis, pas du tout adaptées à ce genre
d'application.
</petite digression>
Je ne connais pas bottle, je ne peux donc pas dire ce qu'il est possible
de faire avec.
Ce que je ferais, c'est un thread séparé qui gère le port série.
Lorsqu'un évènement utile arrive, un message est envoyé au serveur WEB.
Pas d'interruption, mais c'est un peu tout comme. Mais le serveur en
fera quoi de ce message ? Le client fait une demande de mise à jour
régulièrement ?
Pour avoir une mise à jour "instantanée", il faut un serveur WebSocket
en plus.
Nicolas
<petite digression>
Perso, je fais des bancs de contrôle avec des applications desktop
(basées sur wxPython), pas avec des technos WEB. Les technos WEB sont
très à la mode mais, à mon avis, pas du tout adaptées à ce genre
d'application.
</petite digression>
Je ne connais pas bottle, je ne peux donc pas dire ce qu'il est possible
de faire avec.
Ce que je ferais, c'est un thread séparé qui gère le port série.
Lorsqu'un évènement utile arrive, un message est envoyé au serveur WEB.
Pas d'interruption, mais c'est un peu tout comme. Mais le serveur en
fera quoi de ce message ? Le client fait une demande de mise à jour
régulièrement ?
Pour avoir une mise à jour "instantanée", il faut un serveur WebSocket
en plus.
Nicolas
<petite digression>
Perso, je fais des bancs de contrôle avec des applications desktop
(basées sur wxPython), pas avec des technos WEB. Les technos WEB sont
très à la mode mais, à mon avis, pas du tout adaptées à ce genre
d'application.
</petite digression>
Je ne connais pas bottle, je ne peux donc pas dire ce qu'il est possible
de faire avec.
Ce que je ferais, c'est un thread séparé qui gère le port série.
Lorsqu'un évènement utile arrive, un message est envoyé au serveur WEB.
Pas d'interruption, mais c'est un peu tout comme. Mais le serveur en
fera quoi de ce message ? Le client fait une demande de mise à jour
régulièrement ?
Pour avoir une mise à jour "instantanée", il faut un serveur WebSocket
en plus.
Nicolas
Merci pour le conseil de faire un thread, je ne sais pas si c'est comme
cela qu'il faut faire mais ça a l'air de marcher et je peux récupérer
les données du port série sans que cela soit bloquant pour l'application
principale. Maintenant je vais voir si je peux adapter à Bottle pour la
GUI.
***********************************************
# -*- coding: iso-8859-1 -*-
#
# essai écoute port com4
import time, os, serial
from threading import Thread
def listenCOM4(i):
# écoute de COM4 9600N81
global dta, k
ser = serial.Serial("COM4", timeout=None)
while ser.inWaiting()==0 :
time.sleep(0.1)
time.sleep(0.1) # pour une réception de qlq dizaines de char max
k=i
dta=ser.read(ser.inWaiting())
ser.close()
# on relance le thread après la lecture
t = Thread(target=listenCOM4, args=(i+1,))
t.start()
#démarre thread une première fois...
t = Thread(target=listenCOM4, args=(1,))
t.start()
# ... et passe à autre chose
dta=""; k=0
for j in range(10):
print "temps : ", j, " reception ", k, " chaine : ", dta
time.sleep(1)
os._exit(0)
*********************************************
ce qui donne :
C:...>testThreadSerial2.py
temps : 0 reception 0 chaine :
temps : 1 reception 0 chaine :
temps : 2 reception 0 chaine :
temps : 3 reception 1 chaine : 456789
temps : 4 reception 1 chaine : 456789
temps : 5 reception 1 chaine : 456789
temps : 6 reception 1 chaine : 456789
temps : 7 reception 2 chaine : 123
temps : 8 reception 2 chaine : 123
temps : 9 reception 2 chaine : 123
Merci pour le conseil de faire un thread, je ne sais pas si c'est comme
cela qu'il faut faire mais ça a l'air de marcher et je peux récupérer
les données du port série sans que cela soit bloquant pour l'application
principale. Maintenant je vais voir si je peux adapter à Bottle pour la
GUI.
***********************************************
# -*- coding: iso-8859-1 -*-
#
# essai écoute port com4
import time, os, serial
from threading import Thread
def listenCOM4(i):
# écoute de COM4 9600N81
global dta, k
ser = serial.Serial("COM4", timeout=None)
while ser.inWaiting()==0 :
time.sleep(0.1)
time.sleep(0.1) # pour une réception de qlq dizaines de char max
k=i
dta=ser.read(ser.inWaiting())
ser.close()
# on relance le thread après la lecture
t = Thread(target=listenCOM4, args=(i+1,))
t.start()
#démarre thread une première fois...
t = Thread(target=listenCOM4, args=(1,))
t.start()
# ... et passe à autre chose
dta=""; k=0
for j in range(10):
print "temps : ", j, " reception ", k, " chaine : ", dta
time.sleep(1)
os._exit(0)
*********************************************
ce qui donne :
C:...>testThreadSerial2.py
temps : 0 reception 0 chaine :
temps : 1 reception 0 chaine :
temps : 2 reception 0 chaine :
temps : 3 reception 1 chaine : 456789
temps : 4 reception 1 chaine : 456789
temps : 5 reception 1 chaine : 456789
temps : 6 reception 1 chaine : 456789
temps : 7 reception 2 chaine : 123
temps : 8 reception 2 chaine : 123
temps : 9 reception 2 chaine : 123
Merci pour le conseil de faire un thread, je ne sais pas si c'est comme
cela qu'il faut faire mais ça a l'air de marcher et je peux récupérer
les données du port série sans que cela soit bloquant pour l'application
principale. Maintenant je vais voir si je peux adapter à Bottle pour la
GUI.
***********************************************
# -*- coding: iso-8859-1 -*-
#
# essai écoute port com4
import time, os, serial
from threading import Thread
def listenCOM4(i):
# écoute de COM4 9600N81
global dta, k
ser = serial.Serial("COM4", timeout=None)
while ser.inWaiting()==0 :
time.sleep(0.1)
time.sleep(0.1) # pour une réception de qlq dizaines de char max
k=i
dta=ser.read(ser.inWaiting())
ser.close()
# on relance le thread après la lecture
t = Thread(target=listenCOM4, args=(i+1,))
t.start()
#démarre thread une première fois...
t = Thread(target=listenCOM4, args=(1,))
t.start()
# ... et passe à autre chose
dta=""; k=0
for j in range(10):
print "temps : ", j, " reception ", k, " chaine : ", dta
time.sleep(1)
os._exit(0)
*********************************************
ce qui donne :
C:...>testThreadSerial2.py
temps : 0 reception 0 chaine :
temps : 1 reception 0 chaine :
temps : 2 reception 0 chaine :
temps : 3 reception 1 chaine : 456789
temps : 4 reception 1 chaine : 456789
temps : 5 reception 1 chaine : 456789
temps : 6 reception 1 chaine : 456789
temps : 7 reception 2 chaine : 123
temps : 8 reception 2 chaine : 123
temps : 9 reception 2 chaine : 123
Ici, c'est le thread principal qui vient chercher les données reçues par
le thread COM.
Il est également possible de prévenir le thread principal que des
données sont prêtes.
Ici, c'est le thread principal qui vient chercher les données reçues par
le thread COM.
Il est également possible de prévenir le thread principal que des
données sont prêtes.
Ici, c'est le thread principal qui vient chercher les données reçues par
le thread COM.
Il est également possible de prévenir le thread principal que des
données sont prêtes.
Le 30/01/2019 à 09:15, Nicolas a écrit :Ici, c'est le thread principal qui vient chercher les données reçues par
le thread COM.
Je viens de tester et ça marche. Merci beaucoup d'avoir revisité mon
bricolage !Il est également possible de prévenir le thread principal que des
données sont prêtes.
Vous pourriez me dire comment ? Cela m'intéresse car ça permettrait de
déclencher des actions quand certains équipements envoient des données
de tests.
Le 30/01/2019 à 09:15, Nicolas a écrit :
Ici, c'est le thread principal qui vient chercher les données reçues par
le thread COM.
Je viens de tester et ça marche. Merci beaucoup d'avoir revisité mon
bricolage !
Il est également possible de prévenir le thread principal que des
données sont prêtes.
Vous pourriez me dire comment ? Cela m'intéresse car ça permettrait de
déclencher des actions quand certains équipements envoient des données
de tests.
Le 30/01/2019 à 09:15, Nicolas a écrit :Ici, c'est le thread principal qui vient chercher les données reçues par
le thread COM.
Je viens de tester et ça marche. Merci beaucoup d'avoir revisité mon
bricolage !Il est également possible de prévenir le thread principal que des
données sont prêtes.
Vous pourriez me dire comment ? Cela m'intéresse car ça permettrait de
déclencher des actions quand certains équipements envoient des données
de tests.
Le 31/01/2019 à 08:43, Nicolas a écrit :Tout dépend de ce que vous voulez faire, comment vous voulez faire et
avec quoi vous voulez le faire.
Quelles actions sont déclenchées ?
A quel niveau ces actions sont t'elles déclenchées ?
- Dans un thread de management général ?
- Dans l'interface graphique ?
- Autre ?
J'imagine une interface graphique où l'utilisateur aurait des choix et où
les résultats (venant des ports série) pourraient aussi s'afficher.
Par exemple l'utilisateur démarre le programme (ce dernier va d'ores et
déjà écouter le/les ports série).
Etape 1.L'utilisateur scanne un code-barre sur un OF (Ordre de Fabrication,
feuille qui accompagne les produits tout au long de la production) -> le
programme récupère le code-barre et l'analyse, ce qui va lui donner le
type de produit à tester, leur nombre. A partir du type de produit le
programme récupère le type de test à faire dans une base de données,
par exemple, tester chaque produit à tel courant, c'est l'étape 2 (les
produits sont des instruments de mesure du courant). Là aussi on utilise
le lecteur de code-barre pour scanner le numéro de série du produit. Une
fois scanné le numéro de série le programme envoie les données de tests
au 2ème port série pour programmer l'instrument de test et attendre le
résultat que l'on va archiver dans une BDD pour éditer des certificats
plus tard. Puis l'opérateur change de produit à tester et scanne le
nouveau numéro de série, et on boucle au début de l'étape 2 jusqu'à ce
que tous les produits de cet OF soient testés.
Jusque là c'est très linéaire mais j'aimerais que l'utilisateur ait
accès à d'autres opérations, par exemple en fin d'étape 1 il pourrait
demander (étape 3) à changer légèrement les valeurs de tests pour que
le courant de test soit mieux ajusté. Pour cela il doit juste cliquer sur
un bouton de l'interface graphique, laquelle va renvoyer une autre
interface graphique avec des choix d'ajustement de l'instrument de test.
Ensuite on revient à la première interface graphique, à l'étape 2.
Je ne sais pas si c'est bien compréhensible mais voilà, ce que j'aimerais
c'est un processus fluide où l'utilisateur en général n'aurait même pas
besoin d'utiliser le clavier pour un contrôle "normal" étape 1 + n étape
2.
Je pense utiliser "Bottle" car ça a l'air suffisamment simple de
programmer des interfaces graphiques pour quelqu'un comme moi avec des
connaissances sommaires en programmation. Il faut que je regarde la doc de
plus près car j'ai d'un côté des actions déclenchées à partir de
l'interface graphique (étape 3 par ex.), ce qui semble simple à gérer,
mais aussi des actions déclenchées par des réceptions sur les ports
séries, et il va falloir que je comprenne comment articuler cela.
Le 31/01/2019 à 08:43, Nicolas a écrit :
Tout dépend de ce que vous voulez faire, comment vous voulez faire et
avec quoi vous voulez le faire.
Quelles actions sont déclenchées ?
A quel niveau ces actions sont t'elles déclenchées ?
- Dans un thread de management général ?
- Dans l'interface graphique ?
- Autre ?
J'imagine une interface graphique où l'utilisateur aurait des choix et où
les résultats (venant des ports série) pourraient aussi s'afficher.
Par exemple l'utilisateur démarre le programme (ce dernier va d'ores et
déjà écouter le/les ports série).
Etape 1.L'utilisateur scanne un code-barre sur un OF (Ordre de Fabrication,
feuille qui accompagne les produits tout au long de la production) -> le
programme récupère le code-barre et l'analyse, ce qui va lui donner le
type de produit à tester, leur nombre. A partir du type de produit le
programme récupère le type de test à faire dans une base de données,
par exemple, tester chaque produit à tel courant, c'est l'étape 2 (les
produits sont des instruments de mesure du courant). Là aussi on utilise
le lecteur de code-barre pour scanner le numéro de série du produit. Une
fois scanné le numéro de série le programme envoie les données de tests
au 2ème port série pour programmer l'instrument de test et attendre le
résultat que l'on va archiver dans une BDD pour éditer des certificats
plus tard. Puis l'opérateur change de produit à tester et scanne le
nouveau numéro de série, et on boucle au début de l'étape 2 jusqu'à ce
que tous les produits de cet OF soient testés.
Jusque là c'est très linéaire mais j'aimerais que l'utilisateur ait
accès à d'autres opérations, par exemple en fin d'étape 1 il pourrait
demander (étape 3) à changer légèrement les valeurs de tests pour que
le courant de test soit mieux ajusté. Pour cela il doit juste cliquer sur
un bouton de l'interface graphique, laquelle va renvoyer une autre
interface graphique avec des choix d'ajustement de l'instrument de test.
Ensuite on revient à la première interface graphique, à l'étape 2.
Je ne sais pas si c'est bien compréhensible mais voilà, ce que j'aimerais
c'est un processus fluide où l'utilisateur en général n'aurait même pas
besoin d'utiliser le clavier pour un contrôle "normal" étape 1 + n étape
2.
Je pense utiliser "Bottle" car ça a l'air suffisamment simple de
programmer des interfaces graphiques pour quelqu'un comme moi avec des
connaissances sommaires en programmation. Il faut que je regarde la doc de
plus près car j'ai d'un côté des actions déclenchées à partir de
l'interface graphique (étape 3 par ex.), ce qui semble simple à gérer,
mais aussi des actions déclenchées par des réceptions sur les ports
séries, et il va falloir que je comprenne comment articuler cela.
Le 31/01/2019 à 08:43, Nicolas a écrit :Tout dépend de ce que vous voulez faire, comment vous voulez faire et
avec quoi vous voulez le faire.
Quelles actions sont déclenchées ?
A quel niveau ces actions sont t'elles déclenchées ?
- Dans un thread de management général ?
- Dans l'interface graphique ?
- Autre ?
J'imagine une interface graphique où l'utilisateur aurait des choix et où
les résultats (venant des ports série) pourraient aussi s'afficher.
Par exemple l'utilisateur démarre le programme (ce dernier va d'ores et
déjà écouter le/les ports série).
Etape 1.L'utilisateur scanne un code-barre sur un OF (Ordre de Fabrication,
feuille qui accompagne les produits tout au long de la production) -> le
programme récupère le code-barre et l'analyse, ce qui va lui donner le
type de produit à tester, leur nombre. A partir du type de produit le
programme récupère le type de test à faire dans une base de données,
par exemple, tester chaque produit à tel courant, c'est l'étape 2 (les
produits sont des instruments de mesure du courant). Là aussi on utilise
le lecteur de code-barre pour scanner le numéro de série du produit. Une
fois scanné le numéro de série le programme envoie les données de tests
au 2ème port série pour programmer l'instrument de test et attendre le
résultat que l'on va archiver dans une BDD pour éditer des certificats
plus tard. Puis l'opérateur change de produit à tester et scanne le
nouveau numéro de série, et on boucle au début de l'étape 2 jusqu'à ce
que tous les produits de cet OF soient testés.
Jusque là c'est très linéaire mais j'aimerais que l'utilisateur ait
accès à d'autres opérations, par exemple en fin d'étape 1 il pourrait
demander (étape 3) à changer légèrement les valeurs de tests pour que
le courant de test soit mieux ajusté. Pour cela il doit juste cliquer sur
un bouton de l'interface graphique, laquelle va renvoyer une autre
interface graphique avec des choix d'ajustement de l'instrument de test.
Ensuite on revient à la première interface graphique, à l'étape 2.
Je ne sais pas si c'est bien compréhensible mais voilà, ce que j'aimerais
c'est un processus fluide où l'utilisateur en général n'aurait même pas
besoin d'utiliser le clavier pour un contrôle "normal" étape 1 + n étape
2.
Je pense utiliser "Bottle" car ça a l'air suffisamment simple de
programmer des interfaces graphiques pour quelqu'un comme moi avec des
connaissances sommaires en programmation. Il faut que je regarde la doc de
plus près car j'ai d'un côté des actions déclenchées à partir de
l'interface graphique (étape 3 par ex.), ce qui semble simple à gérer,
mais aussi des actions déclenchées par des réceptions sur les ports
séries, et il va falloir que je comprenne comment articuler cela.