Analyse post programation

[Valdub]

Bonjour à tous,

voila ça fait quelques années que je travail dans l'industrie (dépannage principalement) et rencontre un problème d'ordre organisationnel.
je suis automaticien dans une petite boite où je fais surtout de petites modifications sur du siemens et du schneider voir des petits projets.

mon problème principal est que je met un temps fou à programmer et que je suis rarement satisfait de mon travail final.

j'essai de m'améliorer à chaque fois mais les retouches successives dans les DB on tendance à les rendes moins lisible et j'ai toujours un peu de mal a organiser mes FC correctement.

personne dans ma boite ne sais ce qu'est une analyse fonctionnel et je dois vous avouer que j'ai moi même un peu oublié (et ça n'est pas non plus la solution miracle).

du coup je vous le demande:
- Comment organiser vous votre travaille avant de commencer à programmer.
- définition et hiérarchisation des défauts et types de défauts
- définitions des OB, FC, FB, DB
- ......
- avez vous des structures type que vous ressortez régulièrement? Quel type???
- ......

je re-potasse et essai de faire des outils en rentrant le soir, mais ne serait pas contre des pistes de réflexion.

Merci d'avance

[tuscaonline]

Salut,

Pour moi la première étape c'est la collecte des renseignements, dont tu déduis la liste des entrées et sortie, éventuellement des schémas de procédé simplifié (si ils n'existent pas)

A partir de la liste ES et des schéma de procédé tu peux commencé à appréhender comment vas fonctionner le procédé et donc d'en tirer une analyse fonctionnel qui contient le fonctionnement de chaque organe de la machine.

Une fois que ce document est validé et approuvé alors tu peux commencer a programmer.

Quand à l'organisation du programme elle découle de l'AF ainsi souvent on à des boites (FB, DFB etc etc) toutes prêtent pour gérer le fonctionnements et les défauts des actionneurs (moteur vannes ...) après on fait des FC pour décrire le fonctionnement du procédé, un ou plusieurs par sous ensemble définis en AF.

L'AF te sers a définir le cahier de test site (SAT), c'est pas fun a faire mais indispensable.

Donc la règle pour gagner du temps c'est d'écrire ce que tu vas faire avant de commencer à faire.


@ +

[Damall]

Salut,

moi, j'essaye toujours de garder la même façon de faire, par exemple :

je réserve toujours les FC/FB/DB 1 à 199 pour les blocs de la bibliothèque standards SIEMENS.
je réserve aussi la zone des FC/FB/DB de 200 à 299 pour la partie SAFETY (si besoin).

Ensuite, je me réserve des zones de 10 FC/FB/DB pour les fonctions (autant de fonction que nécessite l'application) par exemple, une fonction générale, une fonction hydraulique, une fonction communication, etc... et les fonctions process.

Ensuite, chaque fonction est faite de la même façon, par exemple FC500 HYD - Général, FC501 HYD - Défauts, FC502 HYD - Alarmes ou FC300 GEN - Général, FC301 GEN - Diag PROFIBUS, FC302 GEN - Diag PROFINET, FC303 GEN - Diag ET200s, FC304 GEN - Mode de marche, FC306 GEN - Défauts.

A chaque fois, dans ma fonction général, j'appelle mes blocs liées à ma fonction.

Pour les DB, je me crée toujours un DB de front, pour la supervision, j'ai six DB, un DB commandes TOR, un DB infos TOR, un DB consignes, un DB mesures, un DB défauts et un DB alarmes.

voilà en gros pour moi, avec cette structure, je m'en sort plutôt pal mal.

Mais chacun fait un peu comme il le sent, le tout c'est que le programme soit bien structuré, bien commenté, par de FC/FB trop chargé, et bien respecter la norme PLC OPEN (avec ça c'est déjà un bon point).

@+

[Valdub]

Bonjour,

Ok Pour l'analyse fonctionnel, SADT en général j'établie des fonctions élémentaire (positionnement, alimentation produit, évacuation, .....) et ne pousse pas plus loin. je fais les grafcet sur papier en vitesse avant de passer au code.
donc c'est surtout l'étape papier : Définition du besoin, du fonctionnement et des contraintes que je dois approfondir.

pour les db, généralement, je fais un DB pour les entrée, 1 DB Programme, 1 DB Défaut, 1 DB Sortie, 1 DB Panel.
Je pensais regrouper toutes les tempos dans un DB "IEC-Tempo" et ajouter deux DB pour la COM "input et output" mais ton système n'est pas mal non plus Damall
Effectivement il peut-être intéressent d'augmenter le nombre de DB et de plus les affecter plus histoire que si j'ajoute une consigne je n'ai pas le souci de devoir tout décaler.

l’inconvénient du DB panel c'est qu'il est sencé être spécialisé alors que pour l'affichage des défaut je ne passe pas par lui. j'ai aussi parfois des variables qui se retrouves doublé pour avoir leur valeur associé dans le DB Panel.

merci pour vos retour,

je vais essayer de revoir mon mode de fonctionnement et de pousser un peu plus loin l'AF

a+

[Damall]

Effectivement il peut-être intéressent d'augmenter le nombre de DB et de plus les affecter plus histoire que si j'ajoute une consigne je n'ai pas le souci de devoir tout décaler.

J'ai eu une mauvaise expérience avec les DB avec plusieurs choses dedans, j'ai un sous traitant qui m'a fait un DB avec toutes les mesures et les consignes dans le même DB.

Un électriciens a voulu modifier une consigne, en croyant bien faire, il a modifié la valeur dans le DB et a charger le DB dans l'automate. Hors dans le DB hors ligne, toutes les mesures étant à 0, toutes les mesures sont passées à 0 un tour de cycle et a arrêter toutes l'installation, car cette installation était une station d'eau qui alimentait toutes l'usine, donc tout c'est arrêté.

voilà donc une preuve qu'il faut bien séparer les choses.

@+

[Bernardo59]

Bonjour,

Je fais exactement comme Damall !
Il s'agit même d'un standard du CEA.

[Valdub]

je comprend bien la problématique. ça me rappel également quelques chose sur une machine présente chez nous.

@ Bernardo59
CEA???? Celui-ci??? http://www.cea.fr/
D'où tien tu cette info???

quelles lectures permettent de se rendre au courant de ce genre d'avancé/Recherche/Standard (après notre forum préféré)????

Encore Merci pour vos réponces

[Bernardo59]

Bonjour,

Oui je parle bien du Commissariat à l’énergie Atomique ! Je l'ai vu sur plusieurs installations et un client m'a même spécifié que c'était un standard de chez eux.
Il ne s'agit pas du standard de CEA mais de l'installation CEA sur Marcoule.
Je trouve ça propre comme programmation, je l'utilise moi même pour programmer.

[Damall]

Après, il y a aussi la norme IEC 61131 (PLC Open)

http://www.plcopen.org/

La respecter c'est déjà un grand pas vers un programme propre, en plus il y a un logiciel qui permet de vérfier si les règles sont respecter...

http://www.itris-automation.com/plc-checker/

@+

[AndoniFERRE]

Bonjour,

Je pense que Damall a plutôt bien résumé la façon de procéder.
J'utilise la même méthode, même lorsque je dois modifier des programmes, selon les modifs, soit je rajoute dans les blocs concernés afin de retrouver facilement, soit je crée un bloc spécifique pour les modifs.

Concernant la propreté des programmes, j'ai repris la méthode de la personne qui m'as appris pas mal de choses lorsque j'ai commencer à travailler.
Déjà de faire au plus simple, mais ça, ça parait évident
Ensuite de reprendre le programme au fur et à mesure, tout en veillant à faire une sauvegarde de ce qui fonctionnait, et épurer au mieux.

Un programme n'est jamais clean du premier coup. Il y a forcément des phases de développement et d'ajustement.
Malheureusement en dépannage on a pas forcément le temps d'arriver à la deuxième phase, étant obligé de repartir sur autre chose juste après.