27/10/2007, 20:52:51
Bonsoir,
Voici mon retour d'expérience:
STATUS
>Quelle méthode utilisez vous? La première, la seconde ou encore une autre?
Désormais, je programme en utilisant systématiquement deux adresses de
groupe (ta méthode #2). Je l’ai fait depuis qu'un changement de
version logicielle de mes switchs (ABB) leur a donné un retour de
status systématiquement disponible pour chaque sortie :-)
En avantages
- Le majeur : Le status renvoyé par l’actuator est obligatoirement le
plus juste puisque seul l’actuator connaît la vraie position du relai
de sortie.
- En corolaire, lorsque le switch dispose d’une commande manuelle, le
status est aussi transmis lors d’une manœuvre du relai à la main.
C’est plutôt imparable.
- Ceci permet d’utiliser plusieurs adresses de groupe pour commander
le même actuator et conserver sans problème une visualisation juste de
l’état. Et tout pareil lorsque la commande est déclenchée via une «
scène ».
- Cela permet d’être très clair avec les flags Read => Pas de Read
pour la commande Switch et Read pour le Status. C’est très confortable
pour les superviseurs qui sont assurés lors du scan de démarrage de
récupérer des états fiables.
Comme inconvénients :
- Le flux du bus est multiplié par deux (tout message de changement
d’état ON/OFF est doublé d’un status). Donc à prendre en compte dans
l’analyse de charge.
- Les adresses de groupe sont doublées, ce qui peut faire atteindre
très vite les limites de certaines licences (Ex Serveur OPC de la
Konnex)
Nota : J’ai été confronté à certains interrupteurs qui ne disposent
pas de messages spécifiques permettant de piloter les LED séparément
des boutons (versions avec des BCU1 notamment). Pour ces
interrupteurs, la LED reflètait l’état d’un des boutons, par exemple
l’état du bouton ON. Dans de tels cas, je colle l’adresse de groupe du
status sur l’objet de communication ON en plus de l’adresse de
commande ON, en prenant garde à la mettre en seconde position (pour le
Send). Je ne sais pas si c’est très clean, mais j’ai observé que cela
fonctionne bien.
> Pour faire une fonction centrale qui éteint tout,
J’utilise volontiers les scènes. Ceci limite le nombre d’adresses de
groupe. Par exemple Scène « Nuit » => Les actuators de lampes la
reçoivent et sont programmés pour s’éteindre. Cela sépare les
fonctions et rend la programmation plus lisible pour la maintenance,
quoique... Quand au status, en étant programmé via sa propre adresse,
il est bien transmis.
Sinon je crée une adresse de groupe spécifique dans la quelle je colle
tous les ON ou OFF concernés avec les inter concernés. (Ex : Eclairage
de la chambre = agir sur 3 prises séparées à partir de plusieurs
points).
Nota : Dans le cas de fonctions centrales, comme avec la chambre et
ses 3 prises, il est difficile de déterminer un status ! Une solution
riche pourrait consister à envoyer les 3 status des actuators dans une
porte NOT-AND dont la sortie dirait OFF si tout le monde a son status
OFF. Je ne suis pas allé jusque là .
Régis
Voici mon retour d'expérience:
STATUS
>Quelle méthode utilisez vous? La première, la seconde ou encore une autre?
Désormais, je programme en utilisant systématiquement deux adresses de
groupe (ta méthode #2). Je l’ai fait depuis qu'un changement de
version logicielle de mes switchs (ABB) leur a donné un retour de
status systématiquement disponible pour chaque sortie :-)
En avantages
- Le majeur : Le status renvoyé par l’actuator est obligatoirement le
plus juste puisque seul l’actuator connaît la vraie position du relai
de sortie.
- En corolaire, lorsque le switch dispose d’une commande manuelle, le
status est aussi transmis lors d’une manœuvre du relai à la main.
C’est plutôt imparable.
- Ceci permet d’utiliser plusieurs adresses de groupe pour commander
le même actuator et conserver sans problème une visualisation juste de
l’état. Et tout pareil lorsque la commande est déclenchée via une «
scène ».
- Cela permet d’être très clair avec les flags Read => Pas de Read
pour la commande Switch et Read pour le Status. C’est très confortable
pour les superviseurs qui sont assurés lors du scan de démarrage de
récupérer des états fiables.
Comme inconvénients :
- Le flux du bus est multiplié par deux (tout message de changement
d’état ON/OFF est doublé d’un status). Donc à prendre en compte dans
l’analyse de charge.
- Les adresses de groupe sont doublées, ce qui peut faire atteindre
très vite les limites de certaines licences (Ex Serveur OPC de la
Konnex)
Nota : J’ai été confronté à certains interrupteurs qui ne disposent
pas de messages spécifiques permettant de piloter les LED séparément
des boutons (versions avec des BCU1 notamment). Pour ces
interrupteurs, la LED reflètait l’état d’un des boutons, par exemple
l’état du bouton ON. Dans de tels cas, je colle l’adresse de groupe du
status sur l’objet de communication ON en plus de l’adresse de
commande ON, en prenant garde à la mettre en seconde position (pour le
Send). Je ne sais pas si c’est très clean, mais j’ai observé que cela
fonctionne bien.
> Pour faire une fonction centrale qui éteint tout,
J’utilise volontiers les scènes. Ceci limite le nombre d’adresses de
groupe. Par exemple Scène « Nuit » => Les actuators de lampes la
reçoivent et sont programmés pour s’éteindre. Cela sépare les
fonctions et rend la programmation plus lisible pour la maintenance,
quoique... Quand au status, en étant programmé via sa propre adresse,
il est bien transmis.
Sinon je crée une adresse de groupe spécifique dans la quelle je colle
tous les ON ou OFF concernés avec les inter concernés. (Ex : Eclairage
de la chambre = agir sur 3 prises séparées à partir de plusieurs
points).
Nota : Dans le cas de fonctions centrales, comme avec la chambre et
ses 3 prises, il est difficile de déterminer un status ! Une solution
riche pourrait consister à envoyer les 3 status des actuators dans une
porte NOT-AND dont la sortie dirait OFF si tout le monde a son status
OFF. Je ne suis pas allé jusque là .
Régis