04/08/2007, 20:30:32
On 4 août, 19:05, Marc Assin <raym...@warichet.com> wrote:
>
> Deuxième de figure: Dimmer (le sujet de la discussion)
> On désire installer un dimmer, commandé par un des PB de la plaquette
> On charge l'appli 3190/1 (dim/switch). On paramètre le 6226 pour:
> input 1,3,4=switch,
> input 2=dim.
> Le 6226 montre *5* CO !!! (sw obj pour input 1, sw & dim obj pour
> input 2, sw obj input 3, sw obj pour input 4.
> IL N'Y A PLUS DE STATUS pour les input 1,3,4 !!!
> Ben c'est foutu ! comment veux tu encore configurer quoi que ce soit ?
> On ne peut pas accrocher une fonction s'il n'y a pas le CO
> correspondant. On est d'accord ?
>
> Donc, ce que je voulais dire: dès l'instant oú tu veux installer un
> dimmer sur le PB, tu es obligé de charger l'appli ad-hoc qui prend
> toute la place mémoire dans le BCU et donc il n'y a plus de place pour
> le status feed-back, et c'est merdu :-(
>
> Qu'est-ce que tu en penses ?
Ce que j'en pense, c'est que depuis les début de l'EIB avec les BCU1,
on fait des retours d'état sur des entrées par une 2nde adresse de
groupe sur un objet de commande 1 bit. Cela sert à bien associer les
leds liées aux entrées (ton cas) et surtout à optimiser une fonction
télérupteur avec commande groupée (le BP inverse l'état de la sortie à
chaque appui)
Quand les 6226xx sont en fonction switch, on peut paramétrer les leds
pour qu'elles soient liées à l'objet de commande (on a à ce moment que
4 adresses de groupes en tout), ou les paramétrer pour que les leds
aient leur propre objet de com (soit en tout 8 adresses) et dans ce
cas on peux faire dire ce qu'on veut aux leds (le temps qu'il fait,
une alarme...)
Donc si je reprends ton exemple :
en sw objet input 1,2,3 ,4 tu mets 2 adresses de groupes. Dans l'ordre
1- les commandes, 2- les retours d'état et tu valides le flag E sur
ces objets.
Normalement les leds vont suivre l'état des sorties.
@+
>
> Deuxième de figure: Dimmer (le sujet de la discussion)
> On désire installer un dimmer, commandé par un des PB de la plaquette
> On charge l'appli 3190/1 (dim/switch). On paramètre le 6226 pour:
> input 1,3,4=switch,
> input 2=dim.
> Le 6226 montre *5* CO !!! (sw obj pour input 1, sw & dim obj pour
> input 2, sw obj input 3, sw obj pour input 4.
> IL N'Y A PLUS DE STATUS pour les input 1,3,4 !!!
> Ben c'est foutu ! comment veux tu encore configurer quoi que ce soit ?
> On ne peut pas accrocher une fonction s'il n'y a pas le CO
> correspondant. On est d'accord ?
>
> Donc, ce que je voulais dire: dès l'instant oú tu veux installer un
> dimmer sur le PB, tu es obligé de charger l'appli ad-hoc qui prend
> toute la place mémoire dans le BCU et donc il n'y a plus de place pour
> le status feed-back, et c'est merdu :-(
>
> Qu'est-ce que tu en penses ?
Ce que j'en pense, c'est que depuis les début de l'EIB avec les BCU1,
on fait des retours d'état sur des entrées par une 2nde adresse de
groupe sur un objet de commande 1 bit. Cela sert à bien associer les
leds liées aux entrées (ton cas) et surtout à optimiser une fonction
télérupteur avec commande groupée (le BP inverse l'état de la sortie à
chaque appui)
Quand les 6226xx sont en fonction switch, on peut paramétrer les leds
pour qu'elles soient liées à l'objet de commande (on a à ce moment que
4 adresses de groupes en tout), ou les paramétrer pour que les leds
aient leur propre objet de com (soit en tout 8 adresses) et dans ce
cas on peux faire dire ce qu'on veut aux leds (le temps qu'il fait,
une alarme...)
Donc si je reprends ton exemple :
en sw objet input 1,2,3 ,4 tu mets 2 adresses de groupes. Dans l'ordre
1- les commandes, 2- les retours d'état et tu valides le flag E sur
ces objets.
Normalement les leds vont suivre l'état des sorties.
@+