16/12/2010, 10:04:19
Merci, je crois que j'ai saisi.
--Cédric
Le 16/12/10 09:49, marc.assin a écrit :
> On 16 déc, 09:19, Ferllings<ferlli...@gmail.com> wrote:
>
>> Il est uniquement transi au module,
>> pour savoir comment il doit d coder les data, c'est ca?
> Je pense que oui.
>
> Amha, l'émetteur et le récepteur, n'ont aucune conaissance l'un de
> l'autre.
> Le set-up étant fait séparément dans ETS. Ils ne communiquent que au
> moment de l'envoi/réception du télégramme.
> Suppose que le récepteur a été configuré avec un data type sur 1 Byte
> et il reçoit un bit ? çà ne va pas bien se passer.
> Mais pire encore, configuré sur integer 16 bit et il recoit un float,
> il va l'interprêter ... tout de travers....
>
>> Dans le cas d'une visu, vu quelle ne peut pas connaitre le DPT,
> Ah ben non !
> Je ne sais pas de quelle Visu tu parles, en ce qui concerne le HS (et
> bien d'autres superviseurs évolués) on est censé exporter le data
> (souvent via le format OPC) et l'importer dans la Visu. Donc ETS et la
> Visu sont bien cohérents.
> Là où on fout le bouzouff, c'est quand on fait une modif dans ETS et
> on "oublie" de la reporter dans le Visu, mais les puristes diront
> qu'on est censé aborder la Visu avec une config EST stable.
>
>
>> il faut la configurer manuellement?
> manuellement ??? heuuu, oui, si ce n'est qu'une entry ou deux, oui,
> mais c'est source d'erreur.
> Perso, même pour une seule entry, je fais export de ETS via OPC. Le
> résultat étant un .esf, c'est du texte. Avec NotePad, je vire tout
> sauf la/les nouvelles entry et je les importe dans la Visu.
> Le piège à con... si on change le data type... importer une nouvelle
> version de l'entry ne marche pas. Dans la Visu, il faut d'abord
> détruire l'entry erronée avant que d'importer la nouvelle version (çà
> ne s'écrase pas).
> De même que les GA non utilisés dans la Visu doivent être enlevés à la
> main.
>
--Cédric
Le 16/12/10 09:49, marc.assin a écrit :
> On 16 déc, 09:19, Ferllings<ferlli...@gmail.com> wrote:
>
>> Il est uniquement transi au module,
>> pour savoir comment il doit d coder les data, c'est ca?
> Je pense que oui.
>
> Amha, l'émetteur et le récepteur, n'ont aucune conaissance l'un de
> l'autre.
> Le set-up étant fait séparément dans ETS. Ils ne communiquent que au
> moment de l'envoi/réception du télégramme.
> Suppose que le récepteur a été configuré avec un data type sur 1 Byte
> et il reçoit un bit ? çà ne va pas bien se passer.
> Mais pire encore, configuré sur integer 16 bit et il recoit un float,
> il va l'interprêter ... tout de travers....
>
>> Dans le cas d'une visu, vu quelle ne peut pas connaitre le DPT,
> Ah ben non !
> Je ne sais pas de quelle Visu tu parles, en ce qui concerne le HS (et
> bien d'autres superviseurs évolués) on est censé exporter le data
> (souvent via le format OPC) et l'importer dans la Visu. Donc ETS et la
> Visu sont bien cohérents.
> Là où on fout le bouzouff, c'est quand on fait une modif dans ETS et
> on "oublie" de la reporter dans le Visu, mais les puristes diront
> qu'on est censé aborder la Visu avec une config EST stable.
>
>
>> il faut la configurer manuellement?
> manuellement ??? heuuu, oui, si ce n'est qu'une entry ou deux, oui,
> mais c'est source d'erreur.
> Perso, même pour une seule entry, je fais export de ETS via OPC. Le
> résultat étant un .esf, c'est du texte. Avec NotePad, je vire tout
> sauf la/les nouvelles entry et je les importe dans la Visu.
> Le piège à con... si on change le data type... importer une nouvelle
> version de l'entry ne marche pas. Dans la Visu, il faut d'abord
> détruire l'entry erronée avant que d'importer la nouvelle version (çà
> ne s'écrase pas).
> De même que les GA non utilisés dans la Visu doivent être enlevés à la
> main.
>