RS232-détection RX-port série occupé

Bonjour,

Je n'ai jamais programmé en Python et c'est pourquoi je me pose la question suivante.
Est-il possible de détecter un manque de réception RS232 alors que la porte est déjà occupée par un autre programme?

J'utilise un RaspberryPi sur lequel tourne un programme SER2NET.
Ce programme sert à transférer un Flux TCP vers le port USB série (RS232 USB FTDI).

Le problème est que l'appareil connecté à la porte RS232 se bloque et le but est de détecter ce manque de communication.
Il n'y a plus de réception car l'appareil n'envoie plus rien.

C'est donc pour cela, que j'ai utilisé SER2NET, car ce programme permet de faire des LOG en RX et en TX (deux fichiers LOG séparés).
Avec les deux LOG, je pourrai analyser ce qui c'est passé.

J'aimerai détecter le manque de communication.
Mais, je suppose que ce n'est pas possible , car le port série est déjà occupé par SER2NET.

Question : est ce faisable?

Sinon, je pensait détecter le manque de communication en faisant un TAIL du fichier RX LOG.
Est ce possible?

Le programme complet devrait faire les actions suivantes :

• détecter le manque de communication
• si plus de communication, alors, couper SER2NET
• Envoyer un XON vers l'apapreil
• créer un petit fichier LOG avec la date et heure du pbm
• redémarrer SER2NET

Pouvez vous me conseiller?
Merci

Citation:

---

Envoyé par esa66

Bonjour,
C'est donc pour cela, que j'ai utilisé SER2NET, car ce programme permet de faire des LOG en RX et en TX (deux fichiers LOG séparés).
Avec les deux LOG, je pourrai analyser ce qui c'est passé.

---

Bonjour,

Qu'est-ce qui vous empêche d'analyser les fichiers log dès à présent ? :roll:

Votre demande relève plus d'un forum réseaux/hardware voire RasPi que Python. Peut-être vaudrait-il mieux vous assurer que ser2net n'est pas en mutex (mutual exclusion) ou qu'il ne verrouille pas le port qu'il utilise car sinon, quel que soit le langage que vous viserez, vous ne pourrez pas y accéder.

Sinon, avec Python, vous avez les modules socket et pyserial qui peuvent aider :

https://docs.python.org/2/library/socket.html

http://pyserial.sourceforge.net/

Mais le mieux reste quand même de s'assurer que ser2net ne verrouille pas le port qu'il utilise.

En cas de mutex, vous ne pourrez vous servir que de ce que ser2net veut bien produire en output.

Une dernière solution reste de plonger dans le code de ser2net - si la licence le permet - et de coder le cas où une réponse ne parvient pas avant un certain délai (timeout).

A moins que ce cas ait déjà été prévu auquel cas il faudrait éplucher la doc ser2net dans le détail, si celle-ci existe.

Exemple trouvé grâce à :google: http://linux.die.net/man/8/ser2net

Citation:

---

setporttimeout <tcp port> <timeout>
Set the amount of time in seconds before the port connection will be shut down if no activity has been seen on the port.

---

Il serait toutefois intéressant de trouver pourquoi la machine bloque de temps en temps ?

@+.

Bonjour,

Q: Qu'est-ce qui vous empêche d'analyser les fichiers log dès à présent ?
R : Je ne sais pas comment m'y prendre. Soit analyser la date/heure du dernier accès au fichier. Soit faire un Tail, mais cela ne semble pas facile de voir s'il y a encore du trafic dans le LOG.
J'ai bien vu ceci, mais cela me semble compliqué :


Q: Votre demande relève plus d'un forum réseaux/hardware voire RasPi que Python. Peut-être vaudrait-il mieux vous assurer que ser2net n'est pas en mutex (mutual exclusion) ou qu'il ne verrouille pas le port qu'il utilise car sinon, quel que soit le langage que vous viserez, vous ne pourrez pas y accéder.
A : Bonne info que je vais approfondir. Je ne savais pas qu'il fallait chercher sur le terme MUTEX.

Q: setporttimeout <tcp port> <timeout>
Bien vu, mais malheureusement, ce paramètre ne va pas m'aider. Ce paramètre agis sur la partie TCP (pas RS232). J'ai fait un test : si je coupe le LANTRONIX, alors ce paramètre permet de relancer la communication au redémarrage du Lantronix. Sinon, la connection TCP n'est pas restaurée et reste bloquée.

Q : Il serait toutefois intéressant de trouver pourquoi la machine bloque de temps en temps ?
C'est justement là qu'intervient SER2NET. Le but est de SNIFFER le port RS232 vers la machine (qui est un panneau de centrale feu).

Au niveau SER2NET, tout fonctionne y compris les LOG.
C'est donc un bon début et je peux déjà le placer chez le client.

Cependant, j'aimerai détecter le manque de réception sur la porte RS232 et la relancer par un XON en suivant la procédure donnée ci dessous.

Je continue mes investigations

Citation:

---

Envoyé par esa66

Bonjour,

Q: Qu'est-ce qui vous empêche d'analyser les fichiers log dès à présent ?
R : Je ne sais pas comment m'y prendre. Soit analyser la date/heure du dernier accès au fichier. Soit faire un Tail, mais cela ne semble pas facile de voir s'il y a encore du trafic dans le LOG.

---

Bah non, je pensais plutôt à ouvrir le fichier LOG dans un éditeur de texte pour analyser les dernières lignes tout simplement. :roll:

Citation:

---

Q: setporttimeout <tcp port> <timeout>
Bien vu, mais malheureusement, ce paramètre ne va pas m'aider. Ce paramètre agis sur la partie TCP (pas RS232). J'ai fait un test : si je coupe le LANTRONIX, alors ce paramètre permet de relancer la communication au redémarrage du Lantronix. Sinon, la connection TCP n'est pas restaurée et reste bloquée.

---

C'est vrai que sans voir le contexte de mes propres yeux, j'ai un peu de mal, là. :mrgreen:

Citation:

---

Q : Il serait toutefois intéressant de trouver pourquoi la machine bloque de temps en temps ?
C'est justement là qu'intervient SER2NET. Le but est de SNIFFER le port RS232 vers la machine (qui est un panneau de centrale feu).

---

Hum, ser2net est plutôt un daemon de relais de transmission de données TCP <---> RS232, si vous voulez sniffer le port RS232, vous pourriez le faire avec un script rudimentaire Python exploitant pyserial : http://pyserial.sourceforge.net/

En plus, vous pourriez ainsi bidouiller les configs de port RS232 (RX/TX, handshake, CTS, DTS, baudrate, parity, odd/even, XON/XOFF, etc) dans votre code.

Citation:

---

Cependant, j'aimerai détecter le manque de réception sur la porte RS232 et la relancer par un XON en suivant la procédure donnée ci dessous.

---

XON/XOFF c'est un handshake logiciel, il me semble : http://fr.wikipedia.org/wiki/Contr%C3%B4le_de_flux

Bref, tout ça est un peu loin pour moi. :roll:

@+.

J'ai fais un petit document pour expliquer le contexte général :

http://www.0x1.be/esa/dev/2014/07/28...ronix-ser2net/

A l'origine, il y a deux Lantronix.
Le but est de déporter la porte de communication du PC serveur (PC1) vers le panneau de feu (PC2) qui se trouve dans un autre bâtiment.

J'ai vais donc remplacer un des Lantronix par le Rpi.

Remarque : au début, je pensait "sniffer" avec un petit PC raccordé en // sur le port série du PC2, mais cette solution est plus simple car ne nécessite pas de connexion spéciale et de relayage via un relais pour relancer la porte de COM.

Au sujet du LOG en RX, il faut détecter que plus rien n'arrive dans le fichier.
Ce fichier change tout les jours. enfin , je pense : à analyser.
Et comme il y a souvent les même data qui arrivent je ne peux ma baser sur la dernière ligne.

Je vais encore analyser la possibilité via SER2NET (si open source)

Q : Bref, tout ça est un peu loin pour moi.
Mais non!
Tu peux toujours m'aider pour me lancer sur ce "petit" process qui consiste à analyser le LOG , tuer SER2NET et envoyer un XON sur le port série.
Et oui, tu as raison sur le XON. Je pense que le panneau est bloqué (la raison, je le verrai dans les LOG) et doit être débloqué via un XON.
C'est justement cela que je veux tester.
Je l'ai déjà fait en manuel, donc, je suppose que cela va fonctionner.
Et si cela marche, cela laissera du temps au support pour investigué.
En attendant, leur centrale de feu continuera à discuter avec le PC maitre!
Enfin bref, j'espère trouver une solution.

J'ai dû louper quelque chose, mais pourquoi ne pas relier simplement les deux PCs avec des RJ-45 et un switch ?

La communication se ferait dès lors sur des sockets TCP/IP classiques (IP to IP en ad hoc) entre les deux machines.

Je ne comprends pas l'intérêt de passer par RS232 pour une intercommunication PC to PC ?

@+.