Forum automatisme

L'égalité sur le niveau ça me fait un peu peur, en générale on préfère les <= ou >=

à la prochaine

hello,

ton bout de programme ne me donne pas du tout envie de le lire ...

juste quelques petits conseils "généraux" :


**************************************

* donne un nom compréhensible à chaque variable déclarée (pas de MW1, MW2 ni de NV_PT ...)
même si le nom fait 20 caractères de long, l'essentiel c'est de comprendre exactement à quoi sert la variable

c'est l'exercice le plus dur à réaliser et le plus important : trouver le bon nom

**************************************

* si tu utilises des préfixes aux variables, fait le dans le sens du plus général vers le plus détaillé ; exemple :

WCMD_VAR_ECLUSE
LSP_VAR_ECLUSE

à remplacer par

Ecluse_Var_WCmd
Ecluse_Var_LSP


l'ensemble est écluse
le sous-ensemble est le variateur
le sous-sous-ensemble est le mot de commande ...

quand tu feras une recherche sur une liste de variables triées alphabétiquement, tu me remercieras (tout sera bien groupé)


--> les majuscules, ça fatigue les yeux
choisis ta propre convention et respecte là du début à la fin du programme
il a plein de méthodes qui existent :

CamelCase : https://fr.wikipedia.org/wiki/CamelCase
Hongroise : https://fr.wikipedia.org/wiki/Notation_hongroise
avec des underscores à tout va
.....

plus généralement : https://fr.wikipedia.org/wiki/Convention_de_nommage
(l'article en anglais est + détaillé) : https://en.wikipedia.org/wiki/Naming_co ... ogramming)


**************************************

* ne fais pas tout en langage ST ; chaque langage a ses avantages et inconvénients

il n'y a pas 5 langages pour rien ... et pour n'en utiliser qu'un seul au bout du compte

tout tes triggers pour tester les fronts, je les place habituellement dans une section ladder en début de programme (appelée "PREL" ou "Généralités" par ex)
l'avantage avec le ladder, est que tu disposes des contacts "P" et "N" qui sont des blocs triggers déguisés (c'est carnaval...) ; c'est juste beaucoup plus lisible et compréhensible

là tu commences à tester un front au milieu de ton programme, tu te rends compte plus tard que tu en as encore besoin plus loin dans ton programme ... et puis plus tôt (avant l'appel du bloc TRIGGER) et c'est là que ça coincera ...

la position de chaque chose à son importance ...

un front se teste au début (PREL), une tempo s'exécute en fin de programme (POST), les alarmes s'effacent en masse (RAZ) au début, mais s'écrivent une à une en fin de programme ....

tout comme le combinatoire sur les entrées (PREL) et puis sur les sorties (POST) ... on n'apprend plus le PREL / CHART / POST à l'école ??

vu comme tu es parti, ça va être la grosse pagaille ... tu découvriras tout ça à tes dépends


**************************************

* concernant les constantes

les constantes (ou valeur magique) dans un programme c'est pas propre ; ça doit être déclaratif
et codesys permet de déclarer des constantes (ça ne prend pas de place mémoire) et également les énumérations (c'est un autre sujet)

déjà 0 et 1 pour du BOOL c'est FALSE et TRUE

ensuite déclarer en constante : Ecluse_Var_Vitesse_Nominale = 50;

et puis lire dans le programme : Ecluse_Var_Consigne := Ecluse_Var_Vitesse_Nominale;
c'est bcp plus propre...

**************************************

* concernant les commentaires

//Vitesse en x0.1Hz

--> inutile dans le programme en ST mais très utile en commentaire de variable (lorsque tu déclares la variable)

//Arrêt moteur Ecluse

--> inutile ; si la variable s'appelait "Ecluse_Var_Vitesse" ou "Ecluse_Var_Consigne" ça coulerait de source

faut arrêter de faire des commentaires bidons et non informatifs (du genre "j'écris 5 dans le mot "vitesse" pour passer en petite vitesse" --> la ligne "Ecluse_Var_Consigne := Ecluse_Var_Vitesse_Mini;" parle d'elle même, pas de commentaire nécessaire sur une telle ligne de programme)

**************************************

voilà ... mon avis à 2 cents ... prends le temps d'e-penser

@+

entièrement d'accord avec steph68
pense à une chose va falloir mettre en service et aussi un jour quelqu'un d'autre va lire ton programme, faut penser aux copains.

Merci pour vos conseils Steph68 je vais essayer de les appliquer!

steph68 a écrit :on n'apprend plus le PREL / CHART / POST à l'école ??

vu comme tu es parti, ça va être la grosse pagaille ... tu découvriras tout ça à tes dépends

Sûrement mais je suis comme dirait... en autodidacte.

Mais comme vous dîtes je vais également apprendre de mes erreurs.

Concernant le PERL CHART POST cela ne s'applique qu'a la programmation graphcet? Je vois comment faire sous PL7 pro (merci Google) mais pas vraiment sous somachine. Ai-je juste a créer un nouveau "POU"?

Concernant le PERL CHART POST cela ne s'applique qu'a la programmation graphcet? Je vois comment faire sous PL7 pro (merci Google) mais pas vraiment sous somachine. Ai-je juste a créer un nouveau "POU"?

PREL / CHART / POST c'est une philosophie, un mode de pensée, une façon de structurer on appelle ça un paradigme
ça a été bcp employé sur PL7 mais ce n'est pas Telemecanique qui l'a inventé

PREL = préliminaire

tu vas y trouver tout le combinatoire (= équations booléennes) de préparation à ton programme
tout ce qui est lié aux entrées physiques (la préparation des fronts par ex)
on y trouve également les équations générales des modes de marche et d'arrêt (machine en AU, machine en AUTO, MANU ...)
les commandes de RAZ / INIT des grafcets
la gestion de la reprise à chaud / froid
l'initialisation du programme

CHART = séquentiel

tu vas y trouver la logique séquentielle de ton programme (les grafcets entre autres mais pas que)

POST = postérieur

tu vas y trouver tout le combinatoire de tes sorties, alarmes, messages IHM, tempos ...
tout ce qui va vers l'extérieur de l'automate et qui est le résultat de ton séquentiel


après je n'ai pas dis qu'il faut faire que 3 sections PREL / CHART / POST à ton programme et tout mettre dedans
tu peux très bien structurer ton programme en modules par exemple tout en respectant cette philosophie
mais le plus simple quand on débute c'est 3 sections "PREL / CHART / POST" d'autant plus que le programme est petit

1 POU = 1 tâche ; tu ne dois en avoir qu'une seule et elle doit être cyclique (te concernant uniquement)

ça rejoins juste ce que j'ai déjà dis auparavant : "l'ordre de chaque chose à son importance"

lecture (PREL) --> traitement (CHART) --> écriture (POST)

@+

steph68 a écrit :

1 POU = 1 tâche ; tu ne dois en avoir qu'une seule et elle doit être cyclique (te concernant uniquement)

@+

Un POU sous codesys 3 en faites c'est un bloc de programme qui peux être FC, FB ou PRG. Il doit y en avoir plusieurs pour organiser ton programme. Après ces POU tu dois les appeler dans une tâche.

La gestion des taches est dans le dossier => configuration des taches, au début il n' a que la MAST mais tu peux en ajouter d'autres si tu veux une approche un peu plus temps réel c'est utile.

steph68 a écrit : PREL / CHART / POST c'est une philosophie, un mode de pensée, une façon de structurer on appelle ça un paradigme
ça a été bcp employé sur PL7 mais ce n'est pas Telemecanique qui l'a inventé

T'es sûr que c'est pas Télémécanique qui l'a inventé ?
J'ai jamais vu cette structure ailleurs qu'en PL7 et c'est quand même très lié au grafcet, inventé par Telemécanique, justement !
C'est de qui, alors ?

On voit que le lobbying de télémécanique auprès des écoles française a bien marché.

Il faut respecter quelques règles dans la hiérarchie du programme : traité les entrée en début de programme, exécuté les algorithmes et autre calcul puis mettre à jour les sorties à la fin , il faut plus se rappelé de ça que des mots PREL, CHART, POST qui sont très souvent liée au Grafcet quand même.