Quelques remarques : En fait, destiné uniquement aux informaticiens qui
de la connexion
d'automates d'analyses médicales
Fabrice Burghgraeve à dit
>>Excuse mon ignorance, mais des automates j'en connecte toutes les
semaines,
>>mais je ne sais pas non plus ce qu'est un driver OPC...
c'est le toutes les semaines qui me choque
surtout quand je lis la suite
>> Déjà qu'en ayant les protocoles fournis par les constructeurs, c'est
>> toujours évident parce que quelque fois il y a des omissions ou des
>> erreurs... (du style qui m'est déjà arrive : un champ numérique, mais
c'est
>> pas note dans le protocole qu'il peut recevoir "<100" qui n'est pas
>> numérique... Ou le bon protocole, mais de la génération précédente
>> d'automate...)
c'est pas toujours évident :
à part 2 cas ou les fabriquant ne voulaient pas me fournir le protocole
(Car ils voulaient que j'utilise leur logiciel (des noms : AT+
et le PG96
de Pharmacia ), je n'ai jamais eu de réel problème,
( et même comme cela on peut s'en sortir en traçant le port de com )
En passant : c'est quoi l'automate qui fournissait un mauvais checksum
qu'il peut recevoir "<100"
pour certaines personnes "<100" est numérique, bien que cela soit une
erreur
?? Pour quelqu'un qui connecte des automates toutes les semaines ! ça
du courant dans
les connexions d'automate d'analyse médicales
de plus il dit plus loin
>> Sans prendre parti ni juger la partie technique d'un automate, les
connexions
>> axsym(abbot) sont parmi les plus agréables que j'ai eu à faire
alors que l'AXSYM est spécialiste pour envoyé des < à ...
Il y a d'autres cas tordus, il ne me vienne pas pour l'instant à l'esprit,
mais tout cela est facilement gérable.
même avec ces cas qui passe pour tordu on s'en sort facilement à condition
que le logiciel
qui va récupérer ces résultats soit assez puissant
ce qui ne doit pas être le cas car vu le message ci dessous :
>> Puis pour certains automates, il faut faire des ajustements du résultat
>> (arrondi à 100 de la formule ou encore toutes les transformations du
>> TP/INR/temps du patient quand le TP est > 100 %...
>> Bon et puis les tubes qui viennent de l'extérieur...
>> Et puis les exigences particulières du client, style, pour telle
ne
>> pas prendre les résultats positifs...
Il y même des systèmes qui sont obligé de faire les calculs dans les
drivers automate (Sorry Romain, j'espère
que vous ne faite plus comme cela dans vos systèmes embarqués )
( Au début j'ai aussi fait ça, mais j'était rouge de honte )
D'autres cas :
j'en oublie sûrement
Tout cela est toujours gérable si le logiciel de connexion et le
qui va réceptionner les résultats, sont puissant
>> Alors si en plus il y a un "machin" au milieu sur lequel t'as aucun
>> contrôle... misère le jour ou la connexion est interrompue...
>> Ca fait 3 interlocuteurs qui se renvoient la balle plutôt que 2...
Des machins au milieu ???? ( Le seul cas que je connaisse est le cas du
logiciel des
profils protéiques entre l'automate et le logiciel de connexion )
(...)
Un truc qui est pas mal est de dire au client : je veux bien faire
l'investigation si le
problème n'est pas chez moi vous aurez une facture de ma part et bien
mettre une clause dans
les contrat de maintenance pour ce cas.
>> (on en a des qu'on peut connecter comme ca : on leur mets un serveur
a
>> dispo, sur lequel on pose les fichiers de demandes, et on récupère les
>> fichiers de résultat... Je vais faire un truc du style dans les jours
>> viennent...)
le quotidien des connexions
vous avez oublier KERMIT
>Ben franchement, si t'arrive à piloter un des automates avec le programme
>d'un autre, même si tous les deux sont en ASTM, t'es costaud...
J'en déduit que je suis costaud...
Et PGP encore plus costaud (moi j'ai quand même quelques exe différents
quelques paramètres
dans le fichier ini)
mais PGP n'en à qu'un seul, par contre PGP à tellement de paramètres, que
prends moins
de temps pour modifier une source que PGP à configurer sont ASTM, le seul
avantage est que PGP
envoi sur site des techniciens non-programmeur.
>> Parce que c'est standard, mais c'est jamais pareil...
>> (pas les mêmes champs, les mêmes champs mais qui servent pas a la même
>> chose, etc etc... et quand les différences ne sont pas au niveau
>> présentation du message, elles sont au niveau protocole...)
ASTM est un standard tellement ouvert que l'on peut y faire n'importe
Il prévoie trop de cas, coupure de trame avec ETB, tout dans un seul
enregistrement logique
ou un enregistrement logique par type de message H P O R C Q M L , il
prévoie même de travailler
avec d'autre séparateur, c'est d'ailleurs pour cela que dans
l'enregistrement H on met les
séparateur que l'on va utilise, il prévoit d'avoir une seule ligne O avec
tous les tests ou une ligne O
par test idem pour les R et j'en oublie.
Il prévoit communication série, RS232 , RS485 ( c'est pourquoi il y a dans
le message H l'émetteur et le Récepteur ) réseau ...
Et ne parlons pas des emplacements des champs dans les trames
De plus malgré que cela soit un standard, on se permet (et je me permet )
même de faire des
chose qui ne sont pas dans le standard ( Kryptor ( Brahms anciennement
CisBio ) à qui on peut envoyer des valeurs antérieures dans des sous
séparateur du tests dans le segment O alors qu'il faudrait les envoyer
des segments R avec un flag type de résultats = ValAnt )
en gros la seule chose de standard c'est le message logique (
<STX>[DATA]<ETX>CHECKSUM<CR> )
et encore il y a le cas <ETB>
Romain à dit (un petit Salut au Passage )
>> Bigre ! Ca me rappelle les "réseaux" PGP V4 en cascade...
>> (mais eux avaient une bonne raison : le coût d'une carte réseau...)
Petit Rappel PGP a fêté sont 20 eme anniversaire l'année dernière, et à
l'époque leur réseau RS485 était une avance technologique par rapport à
ce qui se faisait, de plus cela marchait très bien avec le prix des cartes
très faible. Maintenant une carte réseaux ce n'est pas cher, mais à
l'époque cela coûtait une fortune
Ca fait plus de 7 ans que je suis parti de chez PGP et ils fonctionnaient
déjà avec des cartes réseau
depuis un an.
( C'est pas pour leur jeter des fleurs, je pense que leur politique avec
( LMP ) n'est pas bonne )
>>Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
>>implémenter en C soit même).
Pourquoi réécrire le monde, il suffit d'utiliser un KERMIT existant et
lancer à partir de
Windev. ( Bien sur c'est plus ennuyeux à partir de tes systèmes
(pour ne pas les nommés )
>> Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine,
>> santé, où une erreur peut avoir des conséquences dramatiques (un
>> résultat d'analyse faux) et de constater qu'on nous fourni rarement des
>> documentations exhaustives, mises à jour et pertinentes.
D'abord une connexion cela se teste et se valide.
De plus cela servirait à quoi un biologiste (humour)
( si le logiciel qui gère ensuite la validation est bien foutu on peut
minimiser ces problèmes,
valeurs antérieures d'ou Delta Check, limite de cohérences etc etc
... )
Il faut savoir qu'il y à encore dans tous les labos et cela sans
exception des saisies de résultats manuel , comme risque, c'est encore
qu'un protocole foireux
Dans certains cas avec des protocole foireux je suis arrivé en
les structure des trames à mettre des gardes fou , par exemples trame
toujours de même longueur , vérifié la longueur , trames avec structure
reconnaissable dont on vérifie la structure. En général on connecte des
automate récent, ( A part M.Burghgraeve qui connecte des vieux KONE ( ne
m'en veuillez pas c'est de l'humour ) les protocoles deviennent convenable
dans ma bibliothèque de connexion réaliser, il n'y a qu' un appareil de
( SR60) qui travaille sans checksum
Encore une petite remarque savez vous que même avec un checksum on peut
décoder une erreur , les checksum sont basé sur des sommes des caractères
de la chaîne lue , généralement le checksum est un chiffre entre 0 et 255
0x00 et 0xFF , donc 256 possibilités , si on perd des caractères on a une
chance ( plutôt mal chance ) sur 256 de tombé sur la même somme)
>> C'est pas gentil, ca va faire mal a une connaissance commune ;-)
Romain
>> A qui tu fais allusion ?
Il doit parler de PGP ?
Fabrice Burghgraeve
>> Du coup, c'est rigolo quand un certain concurrent justifie le prix de
>> connexions par le fait qu'il doive mettre 5 ingénieurs pendant 1
>> pour écrire le programme :)
Par contre la je ne vois pas (c'est pas PGP ) car ce n'est pas une
argumentation PGP
Autre chose certain fournisseur ( Bayer pour ne pas le nommé ) facture
développement d'une connexion au premier client , ce n'est pas normal
cela la politique de PGP est bonne, la connexion d'un automate jamais
connecter est au même prix qu'une connexion existante, après il aura des
automates plus rentable que d'autre car fortement diffusé et d'autre que
l'on développera que pour un cas unique, si on fait la balance la
est bonne, c'est pourquoi c'est aussi la mienne )
En Résumé
C'est bien que les connexions d'automates soient compliquées, si non je
devrais me recycler
mais tout cela est facilement gérable.
Le jour au les fabricant d'automate se mettrons d'accord sur des
protocoles réellement standard et intégrerons dans leur logiciel automates
les fonctionnalité nécessaire, on ira pointé au chômage, mais ce jour
arrivera qu'en j'aurai pris ma retraite au soleil.
Alex Jaime
ADC Software
Quelques remarques : En fait, destiné uniquement aux informaticiens qui
de la connexion
d'automates d'analyses médicales
Fabrice Burghgraeve à dit
>>Excuse mon ignorance, mais des automates j'en connecte toutes les
semaines,
>>mais je ne sais pas non plus ce qu'est un driver OPC...
c'est le toutes les semaines qui me choque
surtout quand je lis la suite
>> Déjà qu'en ayant les protocoles fournis par les constructeurs, c'est
>> toujours évident parce que quelque fois il y a des omissions ou des
>> erreurs... (du style qui m'est déjà arrive : un champ numérique, mais
c'est
>> pas note dans le protocole qu'il peut recevoir "<100" qui n'est pas
>> numérique... Ou le bon protocole, mais de la génération précédente
>> d'automate...)
c'est pas toujours évident :
à part 2 cas ou les fabriquant ne voulaient pas me fournir le protocole
(Car ils voulaient que j'utilise leur logiciel (des noms : AT+
et le PG96
de Pharmacia ), je n'ai jamais eu de réel problème,
( et même comme cela on peut s'en sortir en traçant le port de com )
En passant : c'est quoi l'automate qui fournissait un mauvais checksum
qu'il peut recevoir "<100"
pour certaines personnes "<100" est numérique, bien que cela soit une
erreur
?? Pour quelqu'un qui connecte des automates toutes les semaines ! ça
du courant dans
les connexions d'automate d'analyse médicales
de plus il dit plus loin
>> Sans prendre parti ni juger la partie technique d'un automate, les
connexions
>> axsym(abbot) sont parmi les plus agréables que j'ai eu à faire
alors que l'AXSYM est spécialiste pour envoyé des < à ...
Il y a d'autres cas tordus, il ne me vienne pas pour l'instant à l'esprit,
mais tout cela est facilement gérable.
même avec ces cas qui passe pour tordu on s'en sort facilement à condition
que le logiciel
qui va récupérer ces résultats soit assez puissant
ce qui ne doit pas être le cas car vu le message ci dessous :
>> Puis pour certains automates, il faut faire des ajustements du résultat
>> (arrondi à 100 de la formule ou encore toutes les transformations du
>> TP/INR/temps du patient quand le TP est > 100 %...
>> Bon et puis les tubes qui viennent de l'extérieur...
>> Et puis les exigences particulières du client, style, pour telle
ne
>> pas prendre les résultats positifs...
Il y même des systèmes qui sont obligé de faire les calculs dans les
drivers automate (Sorry Romain, j'espère
que vous ne faite plus comme cela dans vos systèmes embarqués )
( Au début j'ai aussi fait ça, mais j'était rouge de honte )
D'autres cas :
j'en oublie sûrement
Tout cela est toujours gérable si le logiciel de connexion et le
qui va réceptionner les résultats, sont puissant
>> Alors si en plus il y a un "machin" au milieu sur lequel t'as aucun
>> contrôle... misère le jour ou la connexion est interrompue...
>> Ca fait 3 interlocuteurs qui se renvoient la balle plutôt que 2...
Des machins au milieu ???? ( Le seul cas que je connaisse est le cas du
logiciel des
profils protéiques entre l'automate et le logiciel de connexion )
(...)
Un truc qui est pas mal est de dire au client : je veux bien faire
l'investigation si le
problème n'est pas chez moi vous aurez une facture de ma part et bien
mettre une clause dans
les contrat de maintenance pour ce cas.
>> (on en a des qu'on peut connecter comme ca : on leur mets un serveur
a
>> dispo, sur lequel on pose les fichiers de demandes, et on récupère les
>> fichiers de résultat... Je vais faire un truc du style dans les jours
>> viennent...)
le quotidien des connexions
vous avez oublier KERMIT
>Ben franchement, si t'arrive à piloter un des automates avec le programme
>d'un autre, même si tous les deux sont en ASTM, t'es costaud...
J'en déduit que je suis costaud...
Et PGP encore plus costaud (moi j'ai quand même quelques exe différents
quelques paramètres
dans le fichier ini)
mais PGP n'en à qu'un seul, par contre PGP à tellement de paramètres, que
prends moins
de temps pour modifier une source que PGP à configurer sont ASTM, le seul
avantage est que PGP
envoi sur site des techniciens non-programmeur.
>> Parce que c'est standard, mais c'est jamais pareil...
>> (pas les mêmes champs, les mêmes champs mais qui servent pas a la même
>> chose, etc etc... et quand les différences ne sont pas au niveau
>> présentation du message, elles sont au niveau protocole...)
ASTM est un standard tellement ouvert que l'on peut y faire n'importe
Il prévoie trop de cas, coupure de trame avec ETB, tout dans un seul
enregistrement logique
ou un enregistrement logique par type de message H P O R C Q M L , il
prévoie même de travailler
avec d'autre séparateur, c'est d'ailleurs pour cela que dans
l'enregistrement H on met les
séparateur que l'on va utilise, il prévoit d'avoir une seule ligne O avec
tous les tests ou une ligne O
par test idem pour les R et j'en oublie.
Il prévoit communication série, RS232 , RS485 ( c'est pourquoi il y a dans
le message H l'émetteur et le Récepteur ) réseau ...
Et ne parlons pas des emplacements des champs dans les trames
De plus malgré que cela soit un standard, on se permet (et je me permet )
même de faire des
chose qui ne sont pas dans le standard ( Kryptor ( Brahms anciennement
CisBio ) à qui on peut envoyer des valeurs antérieures dans des sous
séparateur du tests dans le segment O alors qu'il faudrait les envoyer
des segments R avec un flag type de résultats = ValAnt )
en gros la seule chose de standard c'est le message logique (
<STX>[DATA]<ETX>CHECKSUM<CR> )
et encore il y a le cas <ETB>
Romain à dit (un petit Salut au Passage )
>> Bigre ! Ca me rappelle les "réseaux" PGP V4 en cascade...
>> (mais eux avaient une bonne raison : le coût d'une carte réseau...)
Petit Rappel PGP a fêté sont 20 eme anniversaire l'année dernière, et à
l'époque leur réseau RS485 était une avance technologique par rapport à
ce qui se faisait, de plus cela marchait très bien avec le prix des cartes
très faible. Maintenant une carte réseaux ce n'est pas cher, mais à
l'époque cela coûtait une fortune
Ca fait plus de 7 ans que je suis parti de chez PGP et ils fonctionnaient
déjà avec des cartes réseau
depuis un an.
( C'est pas pour leur jeter des fleurs, je pense que leur politique avec
( LMP ) n'est pas bonne )
>>Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
>>implémenter en C soit même).
Pourquoi réécrire le monde, il suffit d'utiliser un KERMIT existant et
lancer à partir de
Windev. ( Bien sur c'est plus ennuyeux à partir de tes systèmes
(pour ne pas les nommés )
>> Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine,
>> santé, où une erreur peut avoir des conséquences dramatiques (un
>> résultat d'analyse faux) et de constater qu'on nous fourni rarement des
>> documentations exhaustives, mises à jour et pertinentes.
D'abord une connexion cela se teste et se valide.
De plus cela servirait à quoi un biologiste (humour)
( si le logiciel qui gère ensuite la validation est bien foutu on peut
minimiser ces problèmes,
valeurs antérieures d'ou Delta Check, limite de cohérences etc etc
... )
Il faut savoir qu'il y à encore dans tous les labos et cela sans
exception des saisies de résultats manuel , comme risque, c'est encore
qu'un protocole foireux
Dans certains cas avec des protocole foireux je suis arrivé en
les structure des trames à mettre des gardes fou , par exemples trame
toujours de même longueur , vérifié la longueur , trames avec structure
reconnaissable dont on vérifie la structure. En général on connecte des
automate récent, ( A part M.Burghgraeve qui connecte des vieux KONE ( ne
m'en veuillez pas c'est de l'humour ) les protocoles deviennent convenable
dans ma bibliothèque de connexion réaliser, il n'y a qu' un appareil de
( SR60) qui travaille sans checksum
Encore une petite remarque savez vous que même avec un checksum on peut
décoder une erreur , les checksum sont basé sur des sommes des caractères
de la chaîne lue , généralement le checksum est un chiffre entre 0 et 255
0x00 et 0xFF , donc 256 possibilités , si on perd des caractères on a une
chance ( plutôt mal chance ) sur 256 de tombé sur la même somme)
>> C'est pas gentil, ca va faire mal a une connaissance commune ;-)
Romain
>> A qui tu fais allusion ?
Il doit parler de PGP ?
Fabrice Burghgraeve
>> Du coup, c'est rigolo quand un certain concurrent justifie le prix de
>> connexions par le fait qu'il doive mettre 5 ingénieurs pendant 1
>> pour écrire le programme :)
Par contre la je ne vois pas (c'est pas PGP ) car ce n'est pas une
argumentation PGP
Autre chose certain fournisseur ( Bayer pour ne pas le nommé ) facture
développement d'une connexion au premier client , ce n'est pas normal
cela la politique de PGP est bonne, la connexion d'un automate jamais
connecter est au même prix qu'une connexion existante, après il aura des
automates plus rentable que d'autre car fortement diffusé et d'autre que
l'on développera que pour un cas unique, si on fait la balance la
est bonne, c'est pourquoi c'est aussi la mienne )
En Résumé
C'est bien que les connexions d'automates soient compliquées, si non je
devrais me recycler
mais tout cela est facilement gérable.
Le jour au les fabricant d'automate se mettrons d'accord sur des
protocoles réellement standard et intégrerons dans leur logiciel automates
les fonctionnalité nécessaire, on ira pointé au chômage, mais ce jour
arrivera qu'en j'aurai pris ma retraite au soleil.
Alex Jaime
ADC Software
Quelques remarques : En fait, destiné uniquement aux informaticiens qui
de la connexion
d'automates d'analyses médicales
Fabrice Burghgraeve à dit
>>Excuse mon ignorance, mais des automates j'en connecte toutes les
semaines,
>>mais je ne sais pas non plus ce qu'est un driver OPC...
c'est le toutes les semaines qui me choque
surtout quand je lis la suite
>> Déjà qu'en ayant les protocoles fournis par les constructeurs, c'est
>> toujours évident parce que quelque fois il y a des omissions ou des
>> erreurs... (du style qui m'est déjà arrive : un champ numérique, mais
c'est
>> pas note dans le protocole qu'il peut recevoir "<100" qui n'est pas
>> numérique... Ou le bon protocole, mais de la génération précédente
>> d'automate...)
c'est pas toujours évident :
à part 2 cas ou les fabriquant ne voulaient pas me fournir le protocole
(Car ils voulaient que j'utilise leur logiciel (des noms : AT+
et le PG96
de Pharmacia ), je n'ai jamais eu de réel problème,
( et même comme cela on peut s'en sortir en traçant le port de com )
En passant : c'est quoi l'automate qui fournissait un mauvais checksum
qu'il peut recevoir "<100"
pour certaines personnes "<100" est numérique, bien que cela soit une
erreur
?? Pour quelqu'un qui connecte des automates toutes les semaines ! ça
du courant dans
les connexions d'automate d'analyse médicales
de plus il dit plus loin
>> Sans prendre parti ni juger la partie technique d'un automate, les
connexions
>> axsym(abbot) sont parmi les plus agréables que j'ai eu à faire
alors que l'AXSYM est spécialiste pour envoyé des < à ...
Il y a d'autres cas tordus, il ne me vienne pas pour l'instant à l'esprit,
mais tout cela est facilement gérable.
même avec ces cas qui passe pour tordu on s'en sort facilement à condition
que le logiciel
qui va récupérer ces résultats soit assez puissant
ce qui ne doit pas être le cas car vu le message ci dessous :
>> Puis pour certains automates, il faut faire des ajustements du résultat
>> (arrondi à 100 de la formule ou encore toutes les transformations du
>> TP/INR/temps du patient quand le TP est > 100 %...
>> Bon et puis les tubes qui viennent de l'extérieur...
>> Et puis les exigences particulières du client, style, pour telle
ne
>> pas prendre les résultats positifs...
Il y même des systèmes qui sont obligé de faire les calculs dans les
drivers automate (Sorry Romain, j'espère
que vous ne faite plus comme cela dans vos systèmes embarqués )
( Au début j'ai aussi fait ça, mais j'était rouge de honte )
D'autres cas :
j'en oublie sûrement
Tout cela est toujours gérable si le logiciel de connexion et le
qui va réceptionner les résultats, sont puissant
>> Alors si en plus il y a un "machin" au milieu sur lequel t'as aucun
>> contrôle... misère le jour ou la connexion est interrompue...
>> Ca fait 3 interlocuteurs qui se renvoient la balle plutôt que 2...
Des machins au milieu ???? ( Le seul cas que je connaisse est le cas du
logiciel des
profils protéiques entre l'automate et le logiciel de connexion )
(...)
Un truc qui est pas mal est de dire au client : je veux bien faire
l'investigation si le
problème n'est pas chez moi vous aurez une facture de ma part et bien
mettre une clause dans
les contrat de maintenance pour ce cas.
>> (on en a des qu'on peut connecter comme ca : on leur mets un serveur
a
>> dispo, sur lequel on pose les fichiers de demandes, et on récupère les
>> fichiers de résultat... Je vais faire un truc du style dans les jours
>> viennent...)
le quotidien des connexions
vous avez oublier KERMIT
>Ben franchement, si t'arrive à piloter un des automates avec le programme
>d'un autre, même si tous les deux sont en ASTM, t'es costaud...
J'en déduit que je suis costaud...
Et PGP encore plus costaud (moi j'ai quand même quelques exe différents
quelques paramètres
dans le fichier ini)
mais PGP n'en à qu'un seul, par contre PGP à tellement de paramètres, que
prends moins
de temps pour modifier une source que PGP à configurer sont ASTM, le seul
avantage est que PGP
envoi sur site des techniciens non-programmeur.
>> Parce que c'est standard, mais c'est jamais pareil...
>> (pas les mêmes champs, les mêmes champs mais qui servent pas a la même
>> chose, etc etc... et quand les différences ne sont pas au niveau
>> présentation du message, elles sont au niveau protocole...)
ASTM est un standard tellement ouvert que l'on peut y faire n'importe
Il prévoie trop de cas, coupure de trame avec ETB, tout dans un seul
enregistrement logique
ou un enregistrement logique par type de message H P O R C Q M L , il
prévoie même de travailler
avec d'autre séparateur, c'est d'ailleurs pour cela que dans
l'enregistrement H on met les
séparateur que l'on va utilise, il prévoit d'avoir une seule ligne O avec
tous les tests ou une ligne O
par test idem pour les R et j'en oublie.
Il prévoit communication série, RS232 , RS485 ( c'est pourquoi il y a dans
le message H l'émetteur et le Récepteur ) réseau ...
Et ne parlons pas des emplacements des champs dans les trames
De plus malgré que cela soit un standard, on se permet (et je me permet )
même de faire des
chose qui ne sont pas dans le standard ( Kryptor ( Brahms anciennement
CisBio ) à qui on peut envoyer des valeurs antérieures dans des sous
séparateur du tests dans le segment O alors qu'il faudrait les envoyer
des segments R avec un flag type de résultats = ValAnt )
en gros la seule chose de standard c'est le message logique (
<STX>[DATA]<ETX>CHECKSUM<CR> )
et encore il y a le cas <ETB>
Romain à dit (un petit Salut au Passage )
>> Bigre ! Ca me rappelle les "réseaux" PGP V4 en cascade...
>> (mais eux avaient une bonne raison : le coût d'une carte réseau...)
Petit Rappel PGP a fêté sont 20 eme anniversaire l'année dernière, et à
l'époque leur réseau RS485 était une avance technologique par rapport à
ce qui se faisait, de plus cela marchait très bien avec le prix des cartes
très faible. Maintenant une carte réseaux ce n'est pas cher, mais à
l'époque cela coûtait une fortune
Ca fait plus de 7 ans que je suis parti de chez PGP et ils fonctionnaient
déjà avec des cartes réseau
depuis un an.
( C'est pas pour leur jeter des fleurs, je pense que leur politique avec
( LMP ) n'est pas bonne )
>>Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
>>implémenter en C soit même).
Pourquoi réécrire le monde, il suffit d'utiliser un KERMIT existant et
lancer à partir de
Windev. ( Bien sur c'est plus ennuyeux à partir de tes systèmes
(pour ne pas les nommés )
>> Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine,
>> santé, où une erreur peut avoir des conséquences dramatiques (un
>> résultat d'analyse faux) et de constater qu'on nous fourni rarement des
>> documentations exhaustives, mises à jour et pertinentes.
D'abord une connexion cela se teste et se valide.
De plus cela servirait à quoi un biologiste (humour)
( si le logiciel qui gère ensuite la validation est bien foutu on peut
minimiser ces problèmes,
valeurs antérieures d'ou Delta Check, limite de cohérences etc etc
... )
Il faut savoir qu'il y à encore dans tous les labos et cela sans
exception des saisies de résultats manuel , comme risque, c'est encore
qu'un protocole foireux
Dans certains cas avec des protocole foireux je suis arrivé en
les structure des trames à mettre des gardes fou , par exemples trame
toujours de même longueur , vérifié la longueur , trames avec structure
reconnaissable dont on vérifie la structure. En général on connecte des
automate récent, ( A part M.Burghgraeve qui connecte des vieux KONE ( ne
m'en veuillez pas c'est de l'humour ) les protocoles deviennent convenable
dans ma bibliothèque de connexion réaliser, il n'y a qu' un appareil de
( SR60) qui travaille sans checksum
Encore une petite remarque savez vous que même avec un checksum on peut
décoder une erreur , les checksum sont basé sur des sommes des caractères
de la chaîne lue , généralement le checksum est un chiffre entre 0 et 255
0x00 et 0xFF , donc 256 possibilités , si on perd des caractères on a une
chance ( plutôt mal chance ) sur 256 de tombé sur la même somme)
>> C'est pas gentil, ca va faire mal a une connaissance commune ;-)
Romain
>> A qui tu fais allusion ?
Il doit parler de PGP ?
Fabrice Burghgraeve
>> Du coup, c'est rigolo quand un certain concurrent justifie le prix de
>> connexions par le fait qu'il doive mettre 5 ingénieurs pendant 1
>> pour écrire le programme :)
Par contre la je ne vois pas (c'est pas PGP ) car ce n'est pas une
argumentation PGP
Autre chose certain fournisseur ( Bayer pour ne pas le nommé ) facture
développement d'une connexion au premier client , ce n'est pas normal
cela la politique de PGP est bonne, la connexion d'un automate jamais
connecter est au même prix qu'une connexion existante, après il aura des
automates plus rentable que d'autre car fortement diffusé et d'autre que
l'on développera que pour un cas unique, si on fait la balance la
est bonne, c'est pourquoi c'est aussi la mienne )
En Résumé
C'est bien que les connexions d'automates soient compliquées, si non je
devrais me recycler
mais tout cela est facilement gérable.
Le jour au les fabricant d'automate se mettrons d'accord sur des
protocoles réellement standard et intégrerons dans leur logiciel automates
les fonctionnalité nécessaire, on ira pointé au chômage, mais ce jour
arrivera qu'en j'aurai pris ma retraite au soleil.
Alex Jaime
ADC Software
Je vous en veux.
Je vous en veux.
Je vous en veux.
Ben on est au moins 3, il faut qu'on ouvre
fr.comp.developpement.connexion.automates.LABM !!
Ben on est au moins 3, il faut qu'on ouvre
fr.comp.developpement.connexion.automates.LABM !!
Ben on est au moins 3, il faut qu'on ouvre
fr.comp.developpement.connexion.automates.LABM !!
