Contrôleur logique ABA S/1.2.1 : partage de blocs fonctions

[Medmax]

Moyenne x entrées

Le but du bloc est de calculer la moyenne des nombres en entrée. Il est facile d'adapter ce bloc à tout type de datapoints (1 byte unsigned, 2 byte float, etc.) et à un plus grand nombre d'entrées.

Exemple :
On désire calculer la moyenne de température d'une pièce qui comporte plusieurs capteurs

Fonctionnement : 
1) Adapter les entrées et la sortie du bloc fonction au type de datapoint souhaité (2 byte float pour une température dans l'exemple)
2) Ajouter plus d'entrées si nécessaire, il suffit de modifier la constante par le nombre d'entrées, de copier/coller le N-CONV et le DIV pour chaque nouvelle entrée, et d'ajouter au bloc ADD le résultat des nouveaux blocs DIV.
3) Créer le nouveau bloc fonction après ces modifications, et connecter simplement les valeurs aux entrées pour avoir la moyenne en sortie.
4) Attention chaque entrée doit être utilisée sans quoi la moyenne ne sera pas correcte.

Schéma :

PS: la conversion des entrées en 4 byte float avant les calculs est pour garder le résultat dans la limite des valeurs du datapoint, sinon le ABB retourne 0 (pas vraiment le cas avec les t°, mais avec des 1 byte 0-255 par exemples ça arrive).

Download :

Bonjour,

Merci pour le bloc, ça fonctionne bien avec 2 entrées.

Question 1: 
Est-ce qu'il y a un moyen d'éditer un bloc importé. Je n'ai pas trouvé de fonction "Edit" et le webinaire ABB sur le contrôleur semble confirmer qu'il n'est pas possible de modifier un bloc de fonction importé...c'est bien dommage

Question 2:
J'essaye de faire une moyenne sur 4 entrées pour une grande pièce donc je m'inspire de ta logique. Cela fonctionne mais mes températures sont arrondies en sortie des convertisseurs (N-Conv). Comme je n'ai pas accès au détail de ton bloc je ne vois pas ce que j'oublie. 

Si quelqu'un a une idée? 

[kalhimeo]

en effet il n'est pas possible d'éditer un bloc importé et c'est bien dommage.

ton problème est dû au fait que ton n-conv converti en "1 byte unsigned" (couleur rouge), alors qu'il faudrait convertir en "4 byte float" (brun). De tête je ne sais plus comment cela est défini, mais je pense que c'est la constante qui doit être sélectionnée comme "4 byte float" pour qu'il adapte automatiquement.

[Medmax]

Je confirme c'est bien le "datatype" de la constante qui détermine la logique d'arrondi. Problème réglé. Merci pour ton retour!

[richardpub]

pour recréer un .xml, il faut prendre le fichier .fbxml et le renommer en .xml. Voir le post de Ives. D'où l'intérêt de publier sur le forum, le fichier.fbxml

Ives 
Posting Freak

Messages : 3,427
Sujets : 39

[Polo46]

 Convertir des secondes en années, jours, heures, minutes et secondes

La sortie "comptage" de certains actionneurs exprime en secondes le temps de la fermeture (ou l'ouverture) du relais.
Elle est codée en 4 octets, DPT 12.100.

Au bout d'un certain temps, la lecture du temps en secondes devient absconse. Il est alors plus intuitif de la traduire en valeurs intelligibles.
Exemple : 501039 secondes, c'est 5jours, 19heures, 10minutes et 39 secondes.

La logique utilisée pour la translation est la suivante :

https://postimg.cc/WtS3mn5c

Si on n'utilise pas le bloc SUB (soustraction) avant d'effectuer une division, le bloc DIV renverra la valeur avec une virgule et le bloc d'entrée arrondira cette valeur par excès ou par défaut. Ainsi, 1000 secondes divisés par 60 renverront 16.66 qui seront arrondis à 17.

D'autres actionneurs sortent la valeur en heures (DPT 7.007 - 2octets). Auquel cas il faudra adapter la logique en supprimant les blocs minutes et secondes, et bien évidemment remplacer les blocs d'entrée et de sortie par le format ad hoc.

Note : la valeur maxi envoyée pour une sortie 4 octets est (2^32)-1, soit 4 294 967 295 secondes. Ainsi exprimé, c'est 136 années, 70 jours, 6 heures, 28 minutes et 15 secondes...  Confused
Polo

[Polo46]

Moyenne x entrées

Le but du bloc est de calculer la moyenne des nombres en entrée. Il est facile d'adapter ce bloc à tout type de datapoints (1 byte unsigned, 2 byte float, etc.) et à un plus grand nombre d'entrées.

Exemple :
On désire calculer la moyenne de température d'une pièce qui comporte plusieurs capteurs

Fonctionnement : 
1) Adapter les entrées et la sortie du bloc fonction au type de datapoint souhaité (2 byte float pour une température dans l'exemple)
2) Ajouter plus d'entrées si nécessaire, il suffit de modifier la constante par le nombre d'entrées, de copier/coller le N-CONV et le DIV pour chaque nouvelle entrée, et d'ajouter au bloc ADD le résultat des nouveaux blocs DIV.
3) Créer le nouveau bloc fonction après ces modifications, et connecter simplement les valeurs aux entrées pour avoir la moyenne en sortie.
4) Attention chaque entrée doit être utilisée sans quoi la moyenne ne sera pas correcte.

Schéma :

PS: la conversion des entrées en 4 byte float avant les calculs est pour garder le résultat dans la limite des valeurs du datapoint, sinon le ABB retourne 0 (pas vraiment le cas avec les t°, mais avec des 1 byte 0-255 par exemples ça arrive).

Download :

Bonjour,

Merci pour le bloc, ça fonctionne bien avec 2 entrées.

Question 1: 
Est-ce qu'il y a un moyen d'éditer un bloc importé. Je n'ai pas trouvé de fonction "Edit" et le webinaire ABB sur le contrôleur semble confirmer qu'il n'est pas possible de modifier un bloc de fonction importé...c'est bien dommage

Question 2:
J'essaye de faire une moyenne sur 4 entrées pour une grande pièce donc je m'inspire de ta logique. Cela fonctionne mais mes températures sont arrondies en sortie des convertisseurs (N-Conv). Comme je n'ai pas accès au détail de ton bloc je ne vois pas ce que j'oublie. 

Si quelqu'un a une idée? 

CC euh pour la moyenne des températures, j'aurais juste monté le truc ainsi :
https://postimg.cc/7Cg72h7V


Dis-moi...

[richardpub]

[quote pid='64941' dateline='1735471780']
Bonjour,

Question 1: 
Est-ce qu'il y a un moyen d'éditer un bloc importé. Je n'ai pas trouvé de fonction "Edit" et le webinaire ABB sur le contrôleur semble confirmer qu'il n'est pas possible de modifier un bloc de fonction importé...c'est bien dommage


[/quote]


Je reprends mon post pour donner une réponse:

Pour recréer un .xml qui comprend le contenu d'un bloc de fonction importé , il faut prendre le fichier .fbxml et le renommer en .xml. Voir le post de Ives. D'où l'intérêt de publier sur le forum, le fichier.fbxml



Mais je n'ai peut être pas bien compris ta demande

[demotica]

Déclenchement à une heure précise (Ex: Pour baisser les volets à 20h) 

Je reprends du service après quelques temps de pause

Je ne sais pas vous, mais je trouve limite qu'on ait pas cette fonction intégrée directement dans ce contrôleur logique. On peut faire par plage mais pas à une heure précise ! 

Objectif 
Ici, l'objectif est de baisser tous mes volets et remonter mon BSO à une heure précise tous les soirs. Bon, ceci en attendant que je daigne enfin installer ma station météo. Là ce sera en fonction de la tombée de la nuit et quand il pleut avec fenêtres ouvertes 

Le topo 
Simuler une impulsion tous les jours à la même heure et une seule fois par jour ! 

Comme je passe par un bloc calendar simple qui True dans la plage définie (ici 20:00:00 et 20:00:01) et False en déhors, il fallait éviter l'envoie de 0 lors du passage à false. C'est le rôle du bloc Filter que j'ai paramétré pour ne laisser passer que le 1 (0 est bloqué).


En effet pour chaque volet j'ai un seul object up/down, le sens du mouvement étant déterminé par les valeurs envoyées (1 : desc, 0: monté)

PS: Je l'ai fait pour mes volets, mais les applications peuvent être nombreuses. Amusez-vous bien !

[parfeu63]

Bonjour a tous,
je rencontre quelques difficultés avec la programmation d'un ABA/S 1.2.1,

je désire envoyer un numéro de scène (fermeture de stores ban valeur: 5) sur une adresse de groupe dont le DPT est 17.001.

mais ma variable de 8 bits non signé a un soucis de type !!!
   

sur la documentation du ABA/S ils ont une solution avec le bloc "delay" mais là encore je suis bloqué 

quelqu'un a t il réalisé ceci?

je vous remercie si vous avez une idée
bonne journée a vous tous

[XeNo]

Bonjour,
J'imagine que tu as une station météo pour récupérer les infos. Tu as bien souvent des alertes intégrées (vent et gel) pour gerer ce type de cas. Essaie de regarder de ce côté.

[parfeu63]

Bonjour,
J'imagine que tu as une station météo pour récupérer les infos. Tu as bien souvent des alertes intégrées (vent et gel) pour gerer ce type de cas. Essaie de regarder de ce côté.

Bonjour,
je n'ai pas de station météo a proprement dit, j'ai un capteur de vent 4-20mA attaché a une entrée analogique MDT, l'ensemble me revient moins cher, d'où le fait de vouloir automatiser moi même les seuils de déclenchement a partir de la gestion des valeurs de scènes.
j'ai contacté l'assistance de ABB, 
wait and see
on croise les doigts

[parfeu63]

Bonjour a tous,
je rencontre quelques difficultés avec la programmation d'un ABA/S 1.2.1,

je désire envoyer un numéro de scène (fermeture de stores ban valeur: 5) sur une adresse de groupe dont le DPT est 17.001.

mais ma variable de 8 bits non signé a un soucis de type !!!


sur la documentation du ABA/S ils ont une solution avec le bloc "delay" mais là encore je suis bloqué 

quelqu'un a t il réalisé ceci?

je vous remercie si vous avez une idée
bonne journée a vous tous

Bonjours, je réponds a ma question 
car j'ai trouvé ce qui manquait grâce a une lecture du programme par ABB Assistance !

en effet j'avais oublié de cocher dans la fonction "mux" l'envoi des données en cas de changement.
c'est bête ou idiot mais quand on a la tête dans le guidon, on passe quelques fois a coté des principe de base.
le premier étant de se relire.

merci a tous.

[Stf_d]

Ce n'est pas une fonction, mais une astuce pour créer un compteur avec une sortie sur 1 bit.

Sans cette bidouille, la sortie du compteur n'accepte d'être connectée qu'à une entrée 1 à 4 bytes.

- Ajouter un UP COUNT, un EQUAL, et un CONST (1 bit)
- Connecter v de UP COUNT à i1 de EQUAL
- Connecter o de CONST à i2 de EQUAL
- Normalement v de UP COUNT s'est configuré en 1 bit
- Dans UP COUNT, cocher valeur limite à 1

Optionnel, si on est intéressé uniquement par la sortie à 1 :
- Dans EQUAL, décocher Entrée 2 en tant que paramètre
- Dans EQUAL, cocher Entrée 2, pour comparer avec un 1
- Supprimer CONST

J'utilise cette possibilité dans une diagramme plus vaste qui regarde la position du soleil, la luminosité, et qui doit envoyer un seul ordre de descente des volets/bso.
Mon souci était que si on décidait de stopper la descente, pour profiter de la nuit qui tombe, dès que des nouvelles valeurs de luminosité arrivaient, ça réenclenchait la descente.

[Stf_d]

Pour faire suite à mon message précédent, voici le bloc de fonction que j'utilise pour demander la fermeture des VR/BSO en fonction de la position du soleil, et de la luminosité.
Ce que je souhaitais c'était :
- Que la fermeture se déclenche uniquement en fonction de la luminosité ne se déclenche pas uniquement en fonction de la luminosité, pour éviter une fermeture intempestive en cas de météo très sombre, d'éclipse, etc...
- Que cette fermeture ne se déclenche qu'une seule fois, pour les cas où on souhaite la stopper et profiter de la nuit qui tombe.
- Le déclenchement de la fermeture ne pourra se refaire que si entre temps la luminosité est passée au-dessus d'une valeur de 200 lux.

Je pense qu'il y a des façons beaucoup plus simple de gérer ça, en particulier avec les valeurs limites de la station météo. Mais sait-on jamais, ça pourrait être utile à d'autres

Le déclenchement unique m'a donné beaucoup de fil à retordre.... Ca doit porter un nom...que je ne connais pas.


   

Téléchargement ci-dessous ↓

[Ives]

Bonjour,

Dans ce type de demande, il est toujours difficile d’apporter une aide pertinente, notamment parce que la description du cahier des charges manque parfois de clarté.

Par exemple :

• « Que la fermeture se déclenche uniquement en fonction de la luminosité, pour éviter une fermeture intempestive en cas de météo très sombre, d’éclipse, etc. »
  et
• « Le déclenchement de la fermeture ne pourra se refaire que si, entre-temps, la luminosité est repassée au-dessus d’une valeur de 200 lux »
  

semblent exprimer la même condition sous deux formulations différentes… sauf si une nuance fonctionnelle particulière est attendue.

ensuite  tu indiques que l'action peut être annulée ou non mais que se passe t-il exactement en cas d'annulation immédiate ou après 30 secondes .....etc.

Plus généralement, ce dessin humoristique illustre la problématique générale :

C'est pour cette raison que dans tout projet d'automatique on utilise des outils de description fonctionnelle tels que le GRAFCET ou le GEMMA qui permettent de structurer clairement le cahier des charges.

L’essentiel est que tu sois parvenu à tes fins, mais sans méthodologie ni compétences, cela devient forcément plus long et plus compliqué !

[Stf_d]

Par exemple :

• « Que la fermeture se déclenche uniquement en fonction de la luminosité, pour éviter une fermeture intempestive en cas de météo très sombre, d’éclipse, etc. »
  et
  
• « Le déclenchement de la fermeture ne pourra se refaire que si, entre-temps, la luminosité est repassée au-dessus d’une valeur de 200 lux »
  

semblent exprimer la même condition sous deux formulations différentes… sauf si une nuance fonctionnelle particulière est attendue.

Oupss ! J'ai fait une erreur dans la description. Il fallait lire :  « Que la fermeture ne se déclenche pas uniquement en fonction de la luminosité, pour éviter une fermeture intempestive en cas de météo très sombre, d’éclipse, etc. ». C'est pour cette raison que je vérifie que le soleil est sous l'horizon, et suffisamment à l'ouest.

ensuite  tu indiques que l'action peut être annulée ou non mais que se passe t-il exactement en cas d'annulation immédiate ou après 30 secondes .....etc.

Là, je ne comprends pas ta remarque. La descente des VR/BSO est envoyée une seule fois, ce qui fait qu'ensuite on peut les manipuler comme on le souhaite. La fermeture automatique ne se redéclenchera que le lendemain soir, si la luminosité est remontée au dessus de 200 lux entre temps. J'imagine qu'il n'y a pas de journée où on ne les dépasse pas à un moment ou à un autre. Si c'est le cas, j'ajusterai.

Je ne demande pas d'aide en particulier. Je souhaitais juste partager ce que j'ai fait en me disant que la partie "envoie unique" pourrait peut-être intéresser.

[richardpub]

L'intension de partager ce que tu as fait est vraiment la bonne méthode pour faire progresser au mieux chacun sur le forum.
Il est intéressant de publier sur le forum, le fichier.fbxml après export dans ETS.

Ensuite pour recréer un .xml qui comprend le contenu d'un bloc de fonction importé , il faut prendre le fichier .fbxml et le renommer en .xml.
Cela permet de comprendre la structure d'un bloc de fonction et de pouvoir l'adapté plus rapidement.