Discussion :

[Just-Soft]

Bonjour !

Un client me demande s'il est possible de brancher plusieurs appareils médicales (laboratoire d'analyses) et d'être à l'écoute pour récupérer les données quand l'appareil termine ses analyses. Pour être plus clair voici un exemple :

Appareil A : Fait l'analyse de 5 paramètres
Appareil B : Fait l'analyse de 10 paramètres

Quand A termine de faire les analyses il envoi les résultats vers une mémoire tampon, idem pour l'appareil B.
Est-il possible de se connecter sur les deux appareils qui sont dotés de port COM pour récupérer les données ?

A noter qu'il n'existe aucune correspondance entre les deux appareils.


Merci par avance.

[SergioMaster]

Bonjour,

je ne vois pas quel pourrait être le problème. Une condition cependant, avoir la doc concernant les deux appareils afin de bien savoir quels sont leur protocoles et format de données envoyés

[gaby277]

Bonjour,

Deux remarques et un complément :
Les PC depuis longtemps ne disposent plus de port com. Il va donc falloir les rajouter soit sous forme
- d'un convertisseur USB <-> com. Ces convertisseurs sont peu chers , se trouvent facilement et marchent bien. Attention cependant à bien lire les spécifs du convertisseur pour être sur qu'il est compatibles avec l'OS en particulier si c'est Windows 10 ...
- soit sous forme d'une carte additionnelle (donc que le PC ait un (des) connecteur(s) interne libre et compatibles avec la carte choisie). Donc la encore bien lire les spécifs du PC et de la carte pour éviter toute mauvaise surprise.

- bien que la question n'ait pas été posée et que cette précision puisse paraître superflue il faut 1 port com par appareil connecté.

- Sous Delphi il faut un composant additionnel pour gérer les ports série. Le grand classique freeware est Tcomport.
Le développeur ne fait plus de mises a jour depuis bien longtemps, pour les dernières versions de Delphi (2010) il faut prendre le composant modifié de WPOSTMA.
En payant (peu cher) il y un composant TMS (éventuellement avec sources) qui est régulièrement mis a jour.

[Just-Soft]

Bonjour,

je ne vois pas quel pourrait être le problème. Une condition cependant, avoir la doc concernant les deux appareils afin de bien savoir quels sont leur protocoles et format de données envoyés

Tout le problème est là ... mon client ne dispose pas de la doc, la seule chose apparente c'est les ports COM. Y'a t-il un moyen universel pour récupérer des données même encodées même si on ne connait le protocole et le format des données ?

[gaby277]

Bonjour,
Si on a aucune doc il est relativement facile de retrouver certaine informations sur le format de transmission par exemple la vitesse, le nombre de stop , start (1, 1.5, 2) le format 7 bits, 8 bits , la parité (paire/impaire, pas) le handshaking (materiel/logiciel/pas)
(il y a des logiciels qui le font en écoutant pendant un certain temps le port série) ou en observant les signaux V24 avec un oscilloscope ou en essayant successivement les vitesses de transmission normalisées (1200, 2400, 4800, 9600 etc.) puis les différents formats.

Apres la récupération des caractères reçus par le port série qu'ils soient codés ou non ne change rien. Sous réserve par exemple que le matériel d'analyse n'attende pas telle ou telle trame pour envoyer tel ou tel résultat

Par contre pour leur interprétation c'est autre chose. ça pourra être très simple ou très compliqué, ce n'est sans doute pas le programmeur qui n'a sans doute pas de connaissance médicale qui aura le plus de facilité ... Le biologiste qui doit actuellement disposer des résultats par un autre moyen (impression, afficheur ) pourra aider l'informaticien au vu de ce qui est reçu.

[Just-Soft]

Un grand merci à vous gaby pour les informations fournies et le temps accordé à cette discussion mais comme je suis novice dans ce type de tâche j'ai besoin de quelques éclaircissements si possible.

Si on a aucune doc il est relativement facile de retrouver certaine informations sur le format de transmission par exemple la vitesse, le nombre de stop , start (1, 1.5, 2) le format 7 bits, 8 bits , la parité (paire/impaire, pas) le handshaking (materiel/logiciel/pas)
(il y a des logiciels qui le font en écoutant pendant un certain temps le port série) ou en observant les signaux V24 avec un oscilloscope ou en essayant successivement les vitesses de transmission normalisées (1200, 2400, 4800, 9600 etc.) puis les différents formats.

ça m'intéresse de savoir s'il vient à votre esprit quelques logiciels qui font ça

Apres la récupération des caractères reçus par le port série qu'ils soient codés ou non ne change rien. Sous réserve par exemple que le matériel d'analyse n'attende pas telle ou telle trame pour envoyer tel ou tel résultat

il m'est difficile de comprendre sans exemple réel ... une documentation p.e

Merci encore

[gaby277]

Un grand merci à vous gaby pour les informations fournies et le temps accordé à cette discussion mais comme je suis novice dans ce type de tâche j'ai besoin de quelques éclaircissements si possible.


ça m'intéresse de savoir s'il vient à votre esprit quelques logiciels qui font ça

Je n'ai pas (plus) de nom de logiciel en tête (trop ancien), simplement j'ai utilisé il y a une vingtaine d'année des moniteurs de ligne que l'on branchait en y sur une liaison V24 et qui permettaient de voir les échanges sur la liaison (en ASCII, EBCDIC, Hexa) sur certains il fallait d'abord rentrer les caractéristiques de la liaison : vitesse , nombre de bits, parité etc. ( et autres paramètres cités) sur les plus récents il y avait une option paramétrage automatique et l'analyseur reconnaissait au bout de 30 secondes environ (sous réserve qu'il y ait du trafic sur la liaison- ça peut-être le problème) les paramètres et les affichait.
Je suppose que l'analyseur scrutait les changement d'états des lignes émission et réception et en déduisait la durée du bit donc la vitesse de transmission, ensuite il devait calculer la parité de chaque caractère et si elle était fausse dans 50% des cas c'est qu'il n'y avait pas de parité et ainsi de suite

J'avais vu un freeware qui le faisait également .
A mon avis la détermination des caractéristiques de la transmission ne posera pas de problème bloquant il suffira de programmer le port du PC successivement avec les différentes vitesses disons de 1200 à 56000 avec 1 start et un stop (s'il y en 1.5 ou 2 sans ne gênera pas la réception puis de tester à 1.5 et 2). ça ne fera jamais que 8 vitesses de transmission à tester, donc peut-être 2 heures pour l'informaticien. On peut en complément utiliser un connecteur intermédiaire(~15 euros ) avec des leds sur les principaux fils de la liaison pour voire si "ça discute" et si les signaux CTS/TRS et DTR/DRS sont utilisés et donc qu'il faut les gérer.

Apres pour le protocole de la liaison le cryptage était rare.

Ce qui serait très gênant c'est si l'appareil d'analyse attendait la réception de 1 ou plusieurs caractères ou message genre "send, transmit .. choisis arbitrairement par le programmeur ) pour envoyer les résultats.
Si vraiment aucune doc ne peut être trouvée j'essaierai avec un connecteur a leds sur les fils de la liaison en forçant les signaux logiques qui peuvent être nécessaires pour que l'appareil émette (très souvent le protocole était matériel : le dispositif positionne la ligne RTS (Request To Send)pour dire qu'il a quelque chose à dire et quand l'ordinateur répond en positionnant CTS (Clear To Send) le dispositif émet . Bon tout ça c'est loin mais le principe est la (de mémoire c'est de la logique négative) .
A lire éventuellement :
http://www.astuces-pratiques.fr/elec...connecteur-db9

Donc je pense qu'il faut d'abord déterminer les parametres de la transmission de l'analyseur (souvent d'ailleurs il y avait des switchs qui permettaient de parametre la liaison donc peut etre qu'en ouvrant le capot .. les informations seront gravées sur le circuit imprimé)
et puis apres regarder ce qui est reçu avec l'aide du biologiste pour recréer la doc .
Bon courage

[Just-Soft]

Vous voulez dire un programme comme celui-ci : http://www.wimb.net/index.php?s=delphi&page=11

[gaby277]

Bonjour,

Vous voulez dire un programme comme celui-ci : http://www.wimb.net/index.php?s=delphi&page=11

Non ! Mais tout simplement parce-que je ne connaissais pas ce programme.
Par contre je connais et j'ai utilisé le composant Tcomport grand classique Delphi de la communication série.

Pour essayer de déterminer la faisabilité du projet sans investir trop de temps il y a des quantités de programmmes de terminaux série disponibles sur le marché qui permettent de visualiser ce qui est reçu et d'émettre des caractères et messages notamment
- les exemples livré avec le composant Tcomport
- Termite
- Termie
- Putty
Ces 3 trois derniers sont des grands classiques freeware et open source (en c)
Mais aussi le terminal de Windows (plus livré à partir de Windows 8 ? je ne sais plus) mais livré avec XP

Je n'ai peut-être pas été clair aussi je vais essayer de reformuler.
Pour communiquer avec l'appareil de laboratoire il va falloir deux choses :
la première (et la plus simple) les paramètres de la transmission vitesse , nombre de bits de starts de stops le "handshaking":
matériel (CTS/RTS éventuellement DSR/DTR) ou logiciel Xon /Xoff ou aucun.
Ces paramètres doivent obligatoirement être connus pour pouvoir communiquer "physiquement" ils
seront assez faciles a déterminer en essayant différentes valeurs (leur nombre est limité) quand le composant n'indiquera plus d'erreur et que les caractères reçus ne seront plus des gribouillis ce sera OK

La deuxième est le(les) protocole(s) et la tout est possible :
Protocole pour les résultats :
l'appareil envoie par exemple les 10 mesures séparées par une virgule ou tabulation par exemple
1.5, 32 ... qui indiquera le taux de cholesterol, de sucre etc
Soit c'est un peu plus sophistiqué et plus facile a lire genre "cholesterol=1.5" "sucre=2.5" etc

ou c'est le PC qui mène la dance et envoie "CH?" pour demander le taux de cholesterol puis "sucre? pour la glycémie etc ..

et le protocole pour la transmission :
1- le codage
ACII sans doute , mais éventuellement EBCDIC (pour certains appareils américains) , Binaire et la ça serait plus coton pour faire du reverse engeenering
2- Gestion des echanges : Par exemple si un message est reçu correctement le PC envoie "Ack" si erreur "Nack" et l'appareil répète (1fois , 2 fois ...)
Je pense vous avoir à peu pres dit toutes les généralités sur le sujet.
Mais bon si je puis me permettre il faudrait peut-être essayer de chercher coté constructeur sinon ça peut être très simple ou très compliqué.
Je ne pense pas qu'il existe un logiciel miracle qui après quelques minutes donnera les spécifs des échanges. La liaison série c'est pas pas comme internet ou il y a des normes pour les trames, même s'il y avait des principes et des bonnes pratiques chaque programmeur faisait ce qu'il voulait et l'imagination humaine est sans limites ..