Organisation DB défauts + synthèse défauts

[JeremAuto07]

Très bien je part alors sur l'idée de faire un tableau de word. Deux mots par zone me semble interessant (un mot pour les défauts, et un pour les alarmes).

Avez vous quelques exemple de programme montrant vos façons de structurer tout ça ?

Pour ma part, j'ai un FC Défauts/Alarmes par zone dans lesquels je code en ladder mes différentes conditions d'apparition des défauts et alarmes avec auto maintien pour mémoriser certain défauts acquittables uniquement via BP réarmement, et d'autres qui sont auto acquittés ou temporisé etc

[steph68]

Pour ma part, j'ai un FC Défauts/Alarmes par zone

Commence par faire un FB par zone avec un tableau d'alarmes déclaré dans la zone "static" du genre "Alarmes := ARRAY[0..1] OF WORD;"
Tu verras, c'est déjà plus sympa d'adresser ton bit en écrivant directement #Alarmes[0].%X3 que d'écrire "DB_ALARMES".Zone1.Alarmes[0].%X3

Ensuite tu crées un dernier FB qui va agréger tous les autres FB d'alarmes.
C'est lui qui va déclarer les zones (exemple Zone1 := FB_ALARMES_ZONE1, Zone2 := FB_ALARMES_ZONE2 ...).
C'est sur ce dernier FB que tu généreras un DB d'instance (que tu appelleras depuis l'OB1 par exemple).
Tu auras un joli DB qui ressemblera beaucoup à celui que tu veux saisir manuellement dans ta version (le "DB_ALARMES").

je code en ladder mes différentes conditions d'apparition des défauts et alarmes avec auto maintien pour mémoriser certain défauts acquittables uniquement via BP réarmement, et d'autres qui sont auto acquittés ou temporisé etc

Ce n'est pas comme ça qu'il faut faire la gestion des défauts.

Premièrement: génère la somme des alarmes (ce que tu appelles "synthèse"), elle te servira à bloquer tes modes de marche et d'arrêt de ton process.
Suffit de mettre 2 comparaisons "#Alarmes[0] <> 0" et "#Alarmes[1] <> 0" en OU vers une bobine.

Deuxièmement: en cas de front descendant du bouton d'acquittement, tu effaces ta table d'alarmes par un bloc MOVE à 2 sorties (soit mettre 0 dans #Alarmes[0] et #Alarmes[1])

Troisièmement: tu évalues uniquement l'apparition de chaque alarme.

Soit avec une bobine SET si tu veux que ton alarme soit acquittée
Soit avec une bobine normale si tu veux que ton alarme s'auto-acquitte
Après tu peux rajouter des tempos si tu veux (que tu instancieras directement dans le FB, les fameux blocs TON et TOF)

Tu ne t'occupes pas du RESET, c'est déjà fait dans la 2ème partie.

Personnellement mes alarmes font parties du bloc qui gère les modes de marche et d'arrêt (mode Auto / Manu, départ cycle, arrêt cycle, initialisation, machine en référence, en fin de cycle, états ...)
Mais ici je n'ai pas voulu trop t'embrouiller dans les explications ...
Regarde comment tu peux intégrer ça à tes MMA (un FB MMA commun à toutes les zones ?).

Si ton IHM n'est pas un SIEMENS (pourquoi, ça s'intègre bien dans TIA ?! tu te tires une balle dans le pied en choisissant autre chose), tu peux déclarer un tableau de BOOL pour les alarmes.
"Alarmes := ARRAY[1...32] OF BOOL;"
Et faire une boucle FOR en SCL pour faire la somme.
Et une autre boucle FOR pour reseter la table.
Ce sera moins performant que la version avec des WORD.

@+

[JeremAuto07]

Salut !

Superbe explication

L'IHM est également une imposition client donc après vérification il n'accepte que les Bit pour les alarmes...

Pour les MMA j'ai en réalité un FC dans lequel j'ai programmé touts les défauts ainsi que la synthèse défauts bloquants et synthèse alarmes, et les conditions initiales permettant d'autorisé la marche du système (sélecteur sur auto + pas de défauts bloquants + tempo démarrage API terminé = marche zone) ce bit est utilisé pour coller le contacteur de marche de la zone et pour autorisé dan un autre FC la marche du régulateur PID. J'ai pris par habitue de créer pour chaque FC un bloc de donnée pour stoker des mémoires etc du FC concerné ce qui reviens à utiliser un FB finalement.

Petit exemple de ma première version de programme:

[philou77]

Salut !

Superbe explication
L'IHM est également une imposition client donc après vérification il n'accepte que les Bit pour les alarmes...

c'est quoi la ref de ton ihm ?

[JeremAuto07]

C'est un KEP CMT2108X2

[philou77]

Re !

Une alarme, ça peut être un bit d'octet de db !

[JeremAuto07]

Je vais regarde ça de plus près alors,

Ensuite tu crées un dernier FB qui va agréger tous les autres FB d'alarmes.
C'est lui qui va déclarer les zones (exemple Zone1 := FB_ALARMES_ZONE1, Zone2 := FB_ALARMES_ZONE2 ...).
C'est sur ce dernier FB que tu généreras un DB d'instance (que tu appelleras depuis l'OB1 par exemple).
Tu auras un joli DB qui ressemblera beaucoup à celui que tu veux saisir manuellement dans ta version (le "DB_ALARMES").

mettre les FB dans un FB l'idée me semble intéressante tu pourrai montrer un exemple ?

J'ai peut être pas expliqué aussi que les zones sont toutes différentes entre elles, elles ne comportent pas le même nombre d'élément chauffant, parfois électrique, parfois eau chaude etc

[philou77]

RE !

Bon en partant de l'idée d'intégrer un FB dans un FB


UDT1 (Etat Alarme)
Pres_Alarm BOOL
Pres_Def BOOL
res_2
res_3
res_4
res_5
res_6
res_7

UDT2 (Alarmes)
Alarme_0 BOOL
Alarme_1 BOOL
Alarme_2 BOOL
Alarme_3 BOOL
Alarme_4 BOOL
Alarme_5 BOOL
Alarme_6 BOOL
Alarme_7 BOOL

UDT3 (Defauts)
idem que alarme mais avec DEFAUT_n

1 - Créer un fB de gestion défaut pour une zone (par ex FB10)
- en STAT, déclarer
Etat_Alarme UDT1
B_AL_0 UDT2
B_DEF_0 UDT3
- En IN tu peux mettre Ack et Sous Tension
programmer les défauts de la zone voulue dans le FB 10

à la fin du FB 10
faire
U #Etat_Defaut_0.Pres_Alarm
R #Etat_Defaut_0.Pres_Alarm // mettre bit alarme à 0

test Octet 0
LAR1 P##Alarme_0 // charger adresse du bit de l'alarme_0 (inconvénient de cette méthode.. faut pas être en accès optimisé)
L B [AR1, P#0.0] // charger un octet à partir de l'adresse du bit d'alarme 0
L 0 // charger 0
<>I // si différent
S #Etat_Defaut_0.Pres_Alarm // mettre bit alarme à 1

répeter à partir de LAR1 pour chaque octet


Là on test un octet, mais on pourrait charger un mot, ou un double mot, ce serait presque pareil
Faire pareil pour les défauts


Ensuite.... creer un FB100 MULTI INSTANCE
dans les stat declarer
Zone_1 FB10

dans le réseau 1 du FB100
appeler #Zone_1

enregistrer le FB100

Dans l'ob 1
appeler le FB100 avec son db d'instance par Ex DB100
et là, dans le DB tu trouveras toutes tes infos en BOOL et nommées de tes précédentes déclarations
Zone_1.Etat_Alarme.Pres_Def
..
..
Zone_1.B_AL_0.Alarme_0
..
Zone_1.B_DF_0.Defaut_0

donc dans ton afficheur, tu devras piocher dans le DB100 !!

Copier le FB10 et coller avec nouveau nom pour nouvelle Zone
Reprogrammer les défaut de la nouvelle zone
Créer la nouvelle zone en STAT dans le FB100
appeler la nouvelle zone
enregistrer
actualiser l'appel du FB100 dans l'ob1

[philou77]

Re !

Petit problème, dans step 7 ou tia, je n'arrive pas à exporter les sources un DB d'instance..

alors dans kep, je ne peux pas importer les variable du DB.
sauf a générer un fichier excel à la main et importer celui-ci

un poil galère...!

[JeremAuto07]

Salut !

Je comprend ta façons de faire je trouve ça intéressent. Mais pour extraire les DB pour l'IHM c'est merdique ^^
Pour ce projet je pense que je vais faire un tableau de bool par zone (donc par FC) et envoyer ces tableaux dans mon DB défauts qui lui est structuré par zone. Cela me permettra d'envoyer uniquement le DB Défatus vers l'IHM, et chaque variable aura un tag.

Si d'autre personne souhaite partager leurs façons de faire car il à du bon à prendre dans toutes les façons de faire

Pour ma part j'aime particulièrement bien l'idée de mettre les Alarmes et Défauts dans les bit de mot, la seule chose qui me fait peur c'est de ne pas avoir de tag par bit et que cela devienne vite le bord** dans le programme mais je me trompe peut être.