Bonjour,
Je suis à la recherche d'un "Active X" ou de tout autre moyen de
avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque chose
de prévu pour cela ou s'il faut acheter un composant externe ? J'aimerais
également savoir si quelqu'un a déjà essayé de communiquer avec un
et si oui, de quelle façon ?
Merci !!!
Bonjour,
Je suis à la recherche d'un "Active X" ou de tout autre moyen de
avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque chose
de prévu pour cela ou s'il faut acheter un composant externe ? J'aimerais
également savoir si quelqu'un a déjà essayé de communiquer avec un
et si oui, de quelle façon ?
Merci !!!
Bonjour,
Je suis à la recherche d'un "Active X" ou de tout autre moyen de
avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque chose
de prévu pour cela ou s'il faut acheter un composant externe ? J'aimerais
également savoir si quelqu'un a déjà essayé de communiquer avec un
et si oui, de quelle façon ?
Merci !!!
Ben voyons, tu sais pas ca !!!
communiquer
> avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
Ben voyons, tu sais pas ca !!!
communiquer
> avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
Ben voyons, tu sais pas ca !!!
communiquer
> avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
> > avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
chose
(...)
Excuse mon ignorance, mais des automates j'en connecte toutes les
mais je ne sais pas non plus ce qu'est un driver OPC...
> > avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
chose
(...)
Excuse mon ignorance, mais des automates j'en connecte toutes les
mais je ne sais pas non plus ce qu'est un driver OPC...
> > avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
chose
(...)
Excuse mon ignorance, mais des automates j'en connecte toutes les
mais je ne sais pas non plus ce qu'est un driver OPC...
Salut Fabrice..
> > > avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
> chose
> (...)
>
> Excuse mon ignorance, mais des automates j'en connecte toutes les
semaines,
C'est bien .... quellle marque?
> mais je ne sais pas non plus ce qu'est un driver OPC...
Ben là ...
OPC = OLE for Process Control
cela permet des échanges standardisés entre des applis, devices,
automates, supervisions etc...
l'interet de la chose est :
son universalité dans le monde industriel (j'entends par monde
industriel : industrie de fabrication, cimenterie, usine chimique,
acierie, enfin l'industrie lourde et celle que je connais le mieux)
sa standardisation et facilité d'échange
son support par MS et un groupe de travail "indépendant" (opc foundation)
regroupant les plus grand constructeurs de matos type API
ou systèmes d'acqui.
ici tu trouveras ton bonheur avec des infos plus "valides" que les miennes
http://www.opceurope.org/
par exemple :
je souhaite connecté un API contenant 1000 variables à surveiller.
via OPC et un support réseau, je crée une table coté API et une table de
variable coté PC (via en général un outils de conf) je déploie un ActiveX
ou j'utilise une DLL et chaque fois qu'une variable change coté API,
la variable est mise à jour coté PC.
résultat :
tu as gagné de nombreuses heures de mise au point de récup de variable
(parsing) par rapport à une merde de modbus par exemple.
Maintenant la réalité sur le terrain est un peu différente:
bon nombre d'API support mal ou pas à 100% la "norme"
mais le résultat final est "globalement très positif".
Maintenant pour répondre au Monsieur qui pose la question,
s'il connaisait mieux WDXXXXX il saurait que bien sur, comme
bon nombre de produit "non-spécialisé automatisme" WDXXXX
n'intégre pas ce genre d'outils. Il faut acquérir un composant tiers
(il faut bien que nous aussi on vive...)
et dans ce cas google est ton ami ....
je conseille au monsieur aussi de faire de nombreux essais avant de
se lancer...
il faut qualifier :
le soft,
le composant
l'API
sans essais poussés point de salut...
car ce qui semble marcher au labo, risque de te peter
à la gueule en prod.
<buissness>
si le monsieur le désire, il peut me contacter et nous nous
ferons un plaisir de lui faire une étude chiffrée et une qualification.
</buissness>
Dominique "QNX" Lecocq
www.binact.com
Salut Fabrice..
> > > avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
> chose
> (...)
>
> Excuse mon ignorance, mais des automates j'en connecte toutes les
semaines,
C'est bien .... quellle marque?
> mais je ne sais pas non plus ce qu'est un driver OPC...
Ben là ...
OPC = OLE for Process Control
cela permet des échanges standardisés entre des applis, devices,
automates, supervisions etc...
l'interet de la chose est :
son universalité dans le monde industriel (j'entends par monde
industriel : industrie de fabrication, cimenterie, usine chimique,
acierie, enfin l'industrie lourde et celle que je connais le mieux)
sa standardisation et facilité d'échange
son support par MS et un groupe de travail "indépendant" (opc foundation)
regroupant les plus grand constructeurs de matos type API
ou systèmes d'acqui.
ici tu trouveras ton bonheur avec des infos plus "valides" que les miennes
http://www.opceurope.org/
par exemple :
je souhaite connecté un API contenant 1000 variables à surveiller.
via OPC et un support réseau, je crée une table coté API et une table de
variable coté PC (via en général un outils de conf) je déploie un ActiveX
ou j'utilise une DLL et chaque fois qu'une variable change coté API,
la variable est mise à jour coté PC.
résultat :
tu as gagné de nombreuses heures de mise au point de récup de variable
(parsing) par rapport à une merde de modbus par exemple.
Maintenant la réalité sur le terrain est un peu différente:
bon nombre d'API support mal ou pas à 100% la "norme"
mais le résultat final est "globalement très positif".
Maintenant pour répondre au Monsieur qui pose la question,
s'il connaisait mieux WDXXXXX il saurait que bien sur, comme
bon nombre de produit "non-spécialisé automatisme" WDXXXX
n'intégre pas ce genre d'outils. Il faut acquérir un composant tiers
(il faut bien que nous aussi on vive...)
et dans ce cas google est ton ami ....
je conseille au monsieur aussi de faire de nombreux essais avant de
se lancer...
il faut qualifier :
le soft,
le composant
l'API
sans essais poussés point de salut...
car ce qui semble marcher au labo, risque de te peter
à la gueule en prod.
<buissness>
si le monsieur le désire, il peut me contacter et nous nous
ferons un plaisir de lui faire une étude chiffrée et une qualification.
</buissness>
Dominique "QNX" Lecocq
www.binact.com
Salut Fabrice..
> > > avec un automate par un driver OPC. Est-ce que Windev 7.5 a quelque
> chose
> (...)
>
> Excuse mon ignorance, mais des automates j'en connecte toutes les
semaines,
C'est bien .... quellle marque?
> mais je ne sais pas non plus ce qu'est un driver OPC...
Ben là ...
OPC = OLE for Process Control
cela permet des échanges standardisés entre des applis, devices,
automates, supervisions etc...
l'interet de la chose est :
son universalité dans le monde industriel (j'entends par monde
industriel : industrie de fabrication, cimenterie, usine chimique,
acierie, enfin l'industrie lourde et celle que je connais le mieux)
sa standardisation et facilité d'échange
son support par MS et un groupe de travail "indépendant" (opc foundation)
regroupant les plus grand constructeurs de matos type API
ou systèmes d'acqui.
ici tu trouveras ton bonheur avec des infos plus "valides" que les miennes
http://www.opceurope.org/
par exemple :
je souhaite connecté un API contenant 1000 variables à surveiller.
via OPC et un support réseau, je crée une table coté API et une table de
variable coté PC (via en général un outils de conf) je déploie un ActiveX
ou j'utilise une DLL et chaque fois qu'une variable change coté API,
la variable est mise à jour coté PC.
résultat :
tu as gagné de nombreuses heures de mise au point de récup de variable
(parsing) par rapport à une merde de modbus par exemple.
Maintenant la réalité sur le terrain est un peu différente:
bon nombre d'API support mal ou pas à 100% la "norme"
mais le résultat final est "globalement très positif".
Maintenant pour répondre au Monsieur qui pose la question,
s'il connaisait mieux WDXXXXX il saurait que bien sur, comme
bon nombre de produit "non-spécialisé automatisme" WDXXXX
n'intégre pas ce genre d'outils. Il faut acquérir un composant tiers
(il faut bien que nous aussi on vive...)
et dans ce cas google est ton ami ....
je conseille au monsieur aussi de faire de nombreux essais avant de
se lancer...
il faut qualifier :
le soft,
le composant
l'API
sans essais poussés point de salut...
car ce qui semble marcher au labo, risque de te peter
à la gueule en prod.
<buissness>
si le monsieur le désire, il peut me contacter et nous nous
ferons un plaisir de lui faire une étude chiffrée et une qualification.
</buissness>
Dominique "QNX" Lecocq
www.binact.com
> C'est bien .... quellle marque?
Hier un Roche.
Mardi prochain un Kone.
Ah ben je suis dans le monde de la biologie... plutot des PMEs que des
industries...
> par exemple :
> je souhaite connecté un API contenant 1000 variables à surveiller.
tu parles du mini-API de biomerieux ?
Donc on ne doit pas parler de la meme chose quand on parle d'API.
Et puis bon... support reseau... Moi j'veux bien...
Mais pour l'instant on a encore des clients qui n'ont pas de reseau, donc on
a des liaisons serie,
et meme si tous nos clients etaient en reseau, il
n'existe a l'heure actuelle (dans notre domaine) que tres peu d'automates
dotes d'ne interface reseau... Et tous ont une interface serie...
A part ca, j'implemente chaque protocole de communication moi-meme pour
l'instant.
Ah ben voila on y arrive.
Deja qu'en ayant les protocoles fournis par les constructeurs, c'est pas
toujours evident parce que quelque fois il y a des omissions ou des
erreurs...
Alors si en plus il y a un "machin" au milieu sur lequel t'as aucun
controle... misere le jour ou la connexion est interrompue...
Ca fait 3 interlocuteurs qui se renvoient la balle plutot que 2...
En plus les standards..... Moi c'que j'en pense....
Par exemple, pas mal des automates ont un protocole de communication au
format ASTM.
C'est un standard americain...
Ben franchement, si t'arrive a piloter un des automates avec le programme
d'un autre, meme si tous les deux sont en ASTM, t'es costaud... (sauf dans
la meme gamme, des fois ca marche, et encore...)
Parce que c'est standard, mais c'est jamais pareil...
(pas les memes champs, les memes champs mais qui servent pas a la meme
chose, etc etc...
et quand les differrences ne sont pas au niveau
presentation du message, elles sont au niveau protocole...)
> C'est bien .... quellle marque?
Hier un Roche.
Mardi prochain un Kone.
Ah ben je suis dans le monde de la biologie... plutot des PMEs que des
industries...
> par exemple :
> je souhaite connecté un API contenant 1000 variables à surveiller.
tu parles du mini-API de biomerieux ?
Donc on ne doit pas parler de la meme chose quand on parle d'API.
Et puis bon... support reseau... Moi j'veux bien...
Mais pour l'instant on a encore des clients qui n'ont pas de reseau, donc on
a des liaisons serie,
et meme si tous nos clients etaient en reseau, il
n'existe a l'heure actuelle (dans notre domaine) que tres peu d'automates
dotes d'ne interface reseau... Et tous ont une interface serie...
A part ca, j'implemente chaque protocole de communication moi-meme pour
l'instant.
Ah ben voila on y arrive.
Deja qu'en ayant les protocoles fournis par les constructeurs, c'est pas
toujours evident parce que quelque fois il y a des omissions ou des
erreurs...
Alors si en plus il y a un "machin" au milieu sur lequel t'as aucun
controle... misere le jour ou la connexion est interrompue...
Ca fait 3 interlocuteurs qui se renvoient la balle plutot que 2...
En plus les standards..... Moi c'que j'en pense....
Par exemple, pas mal des automates ont un protocole de communication au
format ASTM.
C'est un standard americain...
Ben franchement, si t'arrive a piloter un des automates avec le programme
d'un autre, meme si tous les deux sont en ASTM, t'es costaud... (sauf dans
la meme gamme, des fois ca marche, et encore...)
Parce que c'est standard, mais c'est jamais pareil...
(pas les memes champs, les memes champs mais qui servent pas a la meme
chose, etc etc...
et quand les differrences ne sont pas au niveau
presentation du message, elles sont au niveau protocole...)
> C'est bien .... quellle marque?
Hier un Roche.
Mardi prochain un Kone.
Ah ben je suis dans le monde de la biologie... plutot des PMEs que des
industries...
> par exemple :
> je souhaite connecté un API contenant 1000 variables à surveiller.
tu parles du mini-API de biomerieux ?
Donc on ne doit pas parler de la meme chose quand on parle d'API.
Et puis bon... support reseau... Moi j'veux bien...
Mais pour l'instant on a encore des clients qui n'ont pas de reseau, donc on
a des liaisons serie,
et meme si tous nos clients etaient en reseau, il
n'existe a l'heure actuelle (dans notre domaine) que tres peu d'automates
dotes d'ne interface reseau... Et tous ont une interface serie...
A part ca, j'implemente chaque protocole de communication moi-meme pour
l'instant.
Ah ben voila on y arrive.
Deja qu'en ayant les protocoles fournis par les constructeurs, c'est pas
toujours evident parce que quelque fois il y a des omissions ou des
erreurs...
Alors si en plus il y a un "machin" au milieu sur lequel t'as aucun
controle... misere le jour ou la connexion est interrompue...
Ca fait 3 interlocuteurs qui se renvoient la balle plutot que 2...
En plus les standards..... Moi c'que j'en pense....
Par exemple, pas mal des automates ont un protocole de communication au
format ASTM.
C'est un standard americain...
Ben franchement, si t'arrive a piloter un des automates avec le programme
d'un autre, meme si tous les deux sont en ASTM, t'es costaud... (sauf dans
la meme gamme, des fois ca marche, et encore...)
Parce que c'est standard, mais c'est jamais pareil...
(pas les memes champs, les memes champs mais qui servent pas a la meme
chose, etc etc...
et quand les differrences ne sont pas au niveau
presentation du message, elles sont au niveau protocole...)
"Fabrice Burghgraeve"
> Et puis bon... support reseau... Moi j'veux bien...
> Mais pour l'instant on a encore des clients qui n'ont pas de reseau,
> a des liaisons serie,
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...)
> et meme si tous nos clients etaient en reseau, il
> n'existe a l'heure actuelle (dans notre domaine) que tres peu
> dotes d'ne interface reseau... Et tous ont une interface serie...
On en voit quand même de plus en plus, souvent aussi pour le transfert
d'images ou de courbes mais c'est vrai que c'est encore rare et surtout
ça ne concerne que les nouvelles générations d'automates.
> A part ca, j'implemente chaque protocole de communication moi-meme pour
> l'instant.
Il n'y a pas vraiment d'autres moyens...
Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
implémenter en C soit même).
s parler de ces automates (mêmes récents!) qui dialoguent par le port
série avec 2000 octects à chaque trame, sans contrôle de N° trame ni de
checksum !!!
Les plus sérieux sont sans conteste les ricains (la FDA est très
exigeante en matière de logiciel dans le domaine de la santé).
Quand on voit qu'en France, on se contente de préconisations agrémentées
d'un résumé des textes législatifs, rédigés par une association...
http://www.sfil.asso.fr/sfil/pages/fr/32.htm
Ca m'arrive souvent.
Heureusement, la traçabilité que je met en place dans mes programmes me
permet toujours de prouver qu'à mon niveau tout est Ok (en général :-).
> En plus les standards..... Moi c'que j'en pense....
> Par exemple, pas mal des automates ont un protocole de communication au
> format ASTM.
> C'est un standard americain...
> Ben franchement, si t'arrive a piloter un des automates avec le
> d'un autre, meme si tous les deux sont en ASTM, t'es costaud... (sauf
> la meme gamme, des fois ca marche, et encore...)
Hum, si le programme est bien conçu dès le départ, tu peux y arriver.
Pour les rares connexions que j'ai développées avec Windev (je développe
le plus souvent en C, pour notre système embarqué), j'ai pu récupérer
99% du code de l'un pour faire l'autre et changé quelques paramètres
(Kryptor, Vitros ECI, Autodelfia et Helena Platinum).
> Parce que c'est standard, mais c'est jamais pareil...
> (pas les memes champs, les memes champs mais qui servent pas a la meme
> chose, etc etc...
Facile à implémenter en paramètre dans ton driver.
Je ne peux pas encore en parler en détails mais nous avons un projet de
"driver universel" pour automate de biologie, en Java, que j'espère bien
pouvoir faire publier en Open source...
A+
--
Romain Petit
"Fabrice Burghgraeve" <f_pas_de_spam_burghgraeve@computeretservices.com>
> Et puis bon... support reseau... Moi j'veux bien...
> Mais pour l'instant on a encore des clients qui n'ont pas de reseau,
> a des liaisons serie,
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...)
> et meme si tous nos clients etaient en reseau, il
> n'existe a l'heure actuelle (dans notre domaine) que tres peu
> dotes d'ne interface reseau... Et tous ont une interface serie...
On en voit quand même de plus en plus, souvent aussi pour le transfert
d'images ou de courbes mais c'est vrai que c'est encore rare et surtout
ça ne concerne que les nouvelles générations d'automates.
> A part ca, j'implemente chaque protocole de communication moi-meme pour
> l'instant.
Il n'y a pas vraiment d'autres moyens...
Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
implémenter en C soit même).
s parler de ces automates (mêmes récents!) qui dialoguent par le port
série avec 2000 octects à chaque trame, sans contrôle de N° trame ni de
checksum !!!
Les plus sérieux sont sans conteste les ricains (la FDA est très
exigeante en matière de logiciel dans le domaine de la santé).
Quand on voit qu'en France, on se contente de préconisations agrémentées
d'un résumé des textes législatifs, rédigés par une association...
http://www.sfil.asso.fr/sfil/pages/fr/32.htm
Ca m'arrive souvent.
Heureusement, la traçabilité que je met en place dans mes programmes me
permet toujours de prouver qu'à mon niveau tout est Ok (en général :-).
> En plus les standards..... Moi c'que j'en pense....
> Par exemple, pas mal des automates ont un protocole de communication au
> format ASTM.
> C'est un standard americain...
> Ben franchement, si t'arrive a piloter un des automates avec le
> d'un autre, meme si tous les deux sont en ASTM, t'es costaud... (sauf
> la meme gamme, des fois ca marche, et encore...)
Hum, si le programme est bien conçu dès le départ, tu peux y arriver.
Pour les rares connexions que j'ai développées avec Windev (je développe
le plus souvent en C, pour notre système embarqué), j'ai pu récupérer
99% du code de l'un pour faire l'autre et changé quelques paramètres
(Kryptor, Vitros ECI, Autodelfia et Helena Platinum).
> Parce que c'est standard, mais c'est jamais pareil...
> (pas les memes champs, les memes champs mais qui servent pas a la meme
> chose, etc etc...
Facile à implémenter en paramètre dans ton driver.
Je ne peux pas encore en parler en détails mais nous avons un projet de
"driver universel" pour automate de biologie, en Java, que j'espère bien
pouvoir faire publier en Open source...
A+
--
Romain Petit
"Fabrice Burghgraeve"
> Et puis bon... support reseau... Moi j'veux bien...
> Mais pour l'instant on a encore des clients qui n'ont pas de reseau,
> a des liaisons serie,
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...)
> et meme si tous nos clients etaient en reseau, il
> n'existe a l'heure actuelle (dans notre domaine) que tres peu
> dotes d'ne interface reseau... Et tous ont une interface serie...
On en voit quand même de plus en plus, souvent aussi pour le transfert
d'images ou de courbes mais c'est vrai que c'est encore rare et surtout
ça ne concerne que les nouvelles générations d'automates.
> A part ca, j'implemente chaque protocole de communication moi-meme pour
> l'instant.
Il n'y a pas vraiment d'autres moyens...
Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
implémenter en C soit même).
s parler de ces automates (mêmes récents!) qui dialoguent par le port
série avec 2000 octects à chaque trame, sans contrôle de N° trame ni de
checksum !!!
Les plus sérieux sont sans conteste les ricains (la FDA est très
exigeante en matière de logiciel dans le domaine de la santé).
Quand on voit qu'en France, on se contente de préconisations agrémentées
d'un résumé des textes législatifs, rédigés par une association...
http://www.sfil.asso.fr/sfil/pages/fr/32.htm
Ca m'arrive souvent.
Heureusement, la traçabilité que je met en place dans mes programmes me
permet toujours de prouver qu'à mon niveau tout est Ok (en général :-).
> En plus les standards..... Moi c'que j'en pense....
> Par exemple, pas mal des automates ont un protocole de communication au
> format ASTM.
> C'est un standard americain...
> Ben franchement, si t'arrive a piloter un des automates avec le
> d'un autre, meme si tous les deux sont en ASTM, t'es costaud... (sauf
> la meme gamme, des fois ca marche, et encore...)
Hum, si le programme est bien conçu dès le départ, tu peux y arriver.
Pour les rares connexions que j'ai développées avec Windev (je développe
le plus souvent en C, pour notre système embarqué), j'ai pu récupérer
99% du code de l'un pour faire l'autre et changé quelques paramètres
(Kryptor, Vitros ECI, Autodelfia et Helena Platinum).
> Parce que c'est standard, mais c'est jamais pareil...
> (pas les memes champs, les memes champs mais qui servent pas a la meme
> chose, etc etc...
Facile à implémenter en paramètre dans ton driver.
Je ne peux pas encore en parler en détails mais nous avons un projet de
"driver universel" pour automate de biologie, en Java, que j'espère bien
pouvoir faire publier en Open source...
A+
--
Romain Petit
salut :)
Donc c'est vrai qu'on pourrait s'arranger pour avoir un "driver ASTM" qui
marcherait sur plusieurs connexion, mais je ne pense pas que ce soit bcp
plus rapide de creer le fichier de description pour aller avec le driver
universel, que de reutiliser les fonctions C deja ecrites pour les
"recombiner"...
(Je ne re-ecris pas completement le code a chaque fois que je fais un
nouveau programme de connexion heureusement)
Du coup, c'est rigolo quand un certain concurrent justifie le prix de ses
connexions par le fait qu'il doive mettre 5 ingenieurs pendant 1 semaine
pour ecrire le programme :)
j'espere qu'il les paye pas plus de 500 euros par mois :)
meurf...
dans certains cas oui...
pour les automates comme par exemple l'electra si je me souviens bien, c'est
de l'ASTM, mais le message est decoupe en blocs de 512 plus ou moins
n'importe ou dans le message...
pour le STAGO, les flags d'alarme sont dans le manufacturer record.
pour l'helena, t'as des resultats dans le result record, d'autres dans le
comment record...
Puis pour certains automates, il faut faire des ajustements du resultat
(arrondi a 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'exterieur...
Et puis les exigences particulieres du client, style, pour telle analyse, ne
pas prendre les resultats positifs...
Pour faire un driver universel qui gere tous ces cas...
Alors qu'un petit programme bien specifique pour chaque automate, mais
suffisament souple pour s'adapter a chaque client sans le re-ecrire...
Bon courage pour ton projet...
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
salut :)
Donc c'est vrai qu'on pourrait s'arranger pour avoir un "driver ASTM" qui
marcherait sur plusieurs connexion, mais je ne pense pas que ce soit bcp
plus rapide de creer le fichier de description pour aller avec le driver
universel, que de reutiliser les fonctions C deja ecrites pour les
"recombiner"...
(Je ne re-ecris pas completement le code a chaque fois que je fais un
nouveau programme de connexion heureusement)
Du coup, c'est rigolo quand un certain concurrent justifie le prix de ses
connexions par le fait qu'il doive mettre 5 ingenieurs pendant 1 semaine
pour ecrire le programme :)
j'espere qu'il les paye pas plus de 500 euros par mois :)
meurf...
dans certains cas oui...
pour les automates comme par exemple l'electra si je me souviens bien, c'est
de l'ASTM, mais le message est decoupe en blocs de 512 plus ou moins
n'importe ou dans le message...
pour le STAGO, les flags d'alarme sont dans le manufacturer record.
pour l'helena, t'as des resultats dans le result record, d'autres dans le
comment record...
Puis pour certains automates, il faut faire des ajustements du resultat
(arrondi a 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'exterieur...
Et puis les exigences particulieres du client, style, pour telle analyse, ne
pas prendre les resultats positifs...
Pour faire un driver universel qui gere tous ces cas...
Alors qu'un petit programme bien specifique pour chaque automate, mais
suffisament souple pour s'adapter a chaque client sans le re-ecrire...
Bon courage pour ton projet...
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
salut :)
Donc c'est vrai qu'on pourrait s'arranger pour avoir un "driver ASTM" qui
marcherait sur plusieurs connexion, mais je ne pense pas que ce soit bcp
plus rapide de creer le fichier de description pour aller avec le driver
universel, que de reutiliser les fonctions C deja ecrites pour les
"recombiner"...
(Je ne re-ecris pas completement le code a chaque fois que je fais un
nouveau programme de connexion heureusement)
Du coup, c'est rigolo quand un certain concurrent justifie le prix de ses
connexions par le fait qu'il doive mettre 5 ingenieurs pendant 1 semaine
pour ecrire le programme :)
j'espere qu'il les paye pas plus de 500 euros par mois :)
meurf...
dans certains cas oui...
pour les automates comme par exemple l'electra si je me souviens bien, c'est
de l'ASTM, mais le message est decoupe en blocs de 512 plus ou moins
n'importe ou dans le message...
pour le STAGO, les flags d'alarme sont dans le manufacturer record.
pour l'helena, t'as des resultats dans le result record, d'autres dans le
comment record...
Puis pour certains automates, il faut faire des ajustements du resultat
(arrondi a 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'exterieur...
Et puis les exigences particulieres du client, style, pour telle analyse, ne
pas prendre les resultats positifs...
Pour faire un driver universel qui gere tous ces cas...
Alors qu'un petit programme bien specifique pour chaque automate, mais
suffisament souple pour s'adapter a chaque client sans le re-ecrire...
Bon courage pour ton projet...
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
Excuse mon ignorance, mais des automates j'en connecte toutes les
mais je ne sais pas non plus ce qu'est un driver OPC...
Déjà qu'en ayant les protocoles fournis par les constructeurs, c'est pas
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
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...)
Sans prendre parti ni juger la partie technique d'un automate, les
axsym(abbot) sont parmi les plus agréables que j'ai eu à faire
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 analyse,
pas prendre les résultats positifs...
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...
Par contre, il y a souvre et slit et secrit :)
Qu'est-ce qu'il faut de plus pour faire une connexion d'automate en série
:)
et pour les automates en réseau, je suppose que ca doit marcher avec
socketcree etc :)
ou ftp :)
(on en a des qu'on peut connecter comme ca : on leur mets un serveur ftp
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 qui
viennent...)
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...
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...)
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...)
Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
implémenter en C soit même).
Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine, la
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.
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
A qui tu fais allusion ?
Du coup, c'est rigolo quand un certain concurrent justifie le prix de ses
connexions par le fait qu'il doive mettre 5 ingénieurs pendant 1 semaine
pour écrire le programme :)
Excuse mon ignorance, mais des automates j'en connecte toutes les
mais je ne sais pas non plus ce qu'est un driver OPC...
Déjà qu'en ayant les protocoles fournis par les constructeurs, c'est pas
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
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...)
Sans prendre parti ni juger la partie technique d'un automate, les
axsym(abbot) sont parmi les plus agréables que j'ai eu à faire
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 analyse,
pas prendre les résultats positifs...
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...
Par contre, il y a souvre et slit et secrit :)
Qu'est-ce qu'il faut de plus pour faire une connexion d'automate en série
:)
et pour les automates en réseau, je suppose que ca doit marcher avec
socketcree etc :)
ou ftp :)
(on en a des qu'on peut connecter comme ca : on leur mets un serveur ftp
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 qui
viennent...)
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...
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...)
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...)
Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
implémenter en C soit même).
Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine, la
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.
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
A qui tu fais allusion ?
Du coup, c'est rigolo quand un certain concurrent justifie le prix de ses
connexions par le fait qu'il doive mettre 5 ingénieurs pendant 1 semaine
pour écrire le programme :)
Excuse mon ignorance, mais des automates j'en connecte toutes les
mais je ne sais pas non plus ce qu'est un driver OPC...
Déjà qu'en ayant les protocoles fournis par les constructeurs, c'est pas
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
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...)
Sans prendre parti ni juger la partie technique d'un automate, les
axsym(abbot) sont parmi les plus agréables que j'ai eu à faire
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 analyse,
pas prendre les résultats positifs...
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...
Par contre, il y a souvre et slit et secrit :)
Qu'est-ce qu'il faut de plus pour faire une connexion d'automate en série
:)
et pour les automates en réseau, je suppose que ca doit marcher avec
socketcree etc :)
ou ftp :)
(on en a des qu'on peut connecter comme ca : on leur mets un serveur ftp
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 qui
viennent...)
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...
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...)
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...)
Sauf peut-être avec Kermit (mais c'est finalement aussi facile à
implémenter en C soit même).
Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine, la
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.
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
A qui tu fais allusion ?
Du coup, c'est rigolo quand un certain concurrent justifie le prix de ses
connexions par le fait qu'il doive mettre 5 ingénieurs pendant 1 semaine
pour écrire le programme :)
Quelques remarques : En fait, destiné uniquement aux informaticiens qui font
de la connexion
d'automates d'analyses médicales
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 )
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 )
Romain à dit (un petit Salut au Passage )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 le
lancer à partir de Windev.
( Bien sur c'est plus ennuyeux à partir de tes systèmes embarqués
(pour ne pas les nommés )
en passant tes systèmes embarqués peuvent-il connecter un automate en
réseau NFS maintenant et utilisé le 2eme port de com ?? )
Peut être n'utilises-tu plus ceux que j'ai connu mais ceux d'Intertecnica
???
Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine, la
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.
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 pire
qu'un protocole foireux
Dans certains cas avec des protocole foireux je suis arrivé en examinant
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 VS
( SR60) qui travaille sans checksum
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
A qui tu fais allusion ?
Il doit parler de PGP ?
Moi j'en suis a 35 laboratoire , 127 connexions en service ( + 7
connexion qui ne sont plus en service
(remplacement d'automates). dont plus de 50 cette année
( et aucune à
LYON ( remarque pour Romain ) )
Autre chose certain fournisseur ( Bayer pour ne pas le nommé ) facture le
développement d'une connexion au premier client , ce n'est pas normal (Pour
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 politique
est bonne, c'est pourquoi c'est aussi la mienne )
Quelques remarques : En fait, destiné uniquement aux informaticiens qui font
de la connexion
d'automates d'analyses médicales
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 )
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 )
Romain à dit (un petit Salut au Passage )
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 le
lancer à partir de Windev.
( Bien sur c'est plus ennuyeux à partir de tes systèmes embarqués
(pour ne pas les nommés )
en passant tes systèmes embarqués peuvent-il connecter un automate en
réseau NFS maintenant et utilisé le 2eme port de com ?? )
Peut être n'utilises-tu plus ceux que j'ai connu mais ceux d'Intertecnica
???
Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine, la
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.
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 pire
qu'un protocole foireux
Dans certains cas avec des protocole foireux je suis arrivé en examinant
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 VS
( SR60) qui travaille sans checksum
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
A qui tu fais allusion ?
Il doit parler de PGP ?
Moi j'en suis a 35 laboratoire , 127 connexions en service ( + 7
connexion qui ne sont plus en service
(remplacement d'automates). dont plus de 50 cette année
( et aucune à
LYON ( remarque pour Romain ) )
Autre chose certain fournisseur ( Bayer pour ne pas le nommé ) facture le
développement d'une connexion au premier client , ce n'est pas normal (Pour
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 politique
est bonne, c'est pourquoi c'est aussi la mienne )
Quelques remarques : En fait, destiné uniquement aux informaticiens qui font
de la connexion
d'automates d'analyses médicales
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 )
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 )
Romain à dit (un petit Salut au Passage )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 le
lancer à partir de Windev.
( Bien sur c'est plus ennuyeux à partir de tes systèmes embarqués
(pour ne pas les nommés )
en passant tes systèmes embarqués peuvent-il connecter un automate en
réseau NFS maintenant et utilisé le 2eme port de com ?? )
Peut être n'utilises-tu plus ceux que j'ai connu mais ceux d'Intertecnica
???
Ca m'hallucine à chaque fois de voir qu'on travaille dans un domaine, la
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.
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 pire
qu'un protocole foireux
Dans certains cas avec des protocole foireux je suis arrivé en examinant
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 VS
( SR60) qui travaille sans checksum
C'est pas gentil, ca va faire mal a une connaissance commune ;-)
A qui tu fais allusion ?
Il doit parler de PGP ?
Moi j'en suis a 35 laboratoire , 127 connexions en service ( + 7
connexion qui ne sont plus en service
(remplacement d'automates). dont plus de 50 cette année
( et aucune à
LYON ( remarque pour Romain ) )
Autre chose certain fournisseur ( Bayer pour ne pas le nommé ) facture le
développement d'une connexion au premier client , ce n'est pas normal (Pour
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 politique
est bonne, c'est pourquoi c'est aussi la mienne )
"Alex Jaime" a utilisé son clavier pour écrire :
Ben on est au moins 3, il faut qu'on ouvre
fr.comp.developpement.connexion.automates.LABM !!
Hyrys, Phoresis (tous les Sebia ?), de nombreux Sysmex, les "machins"
cmonodirectionnels qui envoient sur le port série comme ils impriment
(IMX, CLA...), certains Menarini (ha8140)...
Pas mal. J'espère que cela t'as permis de changer de voiture :-)
Tu ne t'es pas encore mis à Java ?
"Alex Jaime" a utilisé son clavier pour écrire :
Ben on est au moins 3, il faut qu'on ouvre
fr.comp.developpement.connexion.automates.LABM !!
Hyrys, Phoresis (tous les Sebia ?), de nombreux Sysmex, les "machins"
cmonodirectionnels qui envoient sur le port série comme ils impriment
(IMX, CLA...), certains Menarini (ha8140)...
Pas mal. J'espère que cela t'as permis de changer de voiture :-)
Tu ne t'es pas encore mis à Java ?
"Alex Jaime" a utilisé son clavier pour écrire :
Ben on est au moins 3, il faut qu'on ouvre
fr.comp.developpement.connexion.automates.LABM !!
Hyrys, Phoresis (tous les Sebia ?), de nombreux Sysmex, les "machins"
cmonodirectionnels qui envoient sur le port série comme ils impriment
(IMX, CLA...), certains Menarini (ha8140)...
Pas mal. J'espère que cela t'as permis de changer de voiture :-)
Tu ne t'es pas encore mis à Java ?
