Automatisme 2

Formation - Une méthode à maîtriser - 02/2025

3.3 Logique de prog d’une séquence

Logique de programmation d’une séquence
Règle générale : Il y a des contraintes « cachées » dans le choix de programmation d’une séquence. Le code doit surtout réagir comme prévu dans les demandes du cahier de charge, mais il doit également être simple, claire, compréhensible, avec suffisamment de commentaires pour faciliter le dépannage par la lecture du code.
Aujourd’hui, presque toutes les informations doivent être incluses dans le code sous forme de commentaire, car souvent la personne qui fait le dépannage n’est pas forcément la personne qui l'a codé. Elle peut ne pas avoir une connaissance approfondie du process.

Remarques liées à la forme :
Note : Un code qui est « beau » visuellement n’est pas nécessairement « bon », mais un code « bon » doit être « beau ».
Toutes les remarques liées à la forme ne sont pas obligatoires, mais sont fortement conseilles !
Certaines erreurs de programmation peuvent être identifiées plus rapidement si le code est développé d’une manière soignée.
Les chapitres suivants décrivent les règles à privilégier.

3.3.1 L’indentation

Il faut utiliser la tabulation pour mieux comprendre le déroulement du code :

step 1110 indentation correcte

Figure 17 : step 1110 indentation correcte

Exemple correct d'indentation.

step 1110 indentation incorrecte

Figure 18 : step 1110 indentation incorrecte

Casse dans les commentaires :
L’utilisation des majuscules ou minuscules et accents – il faut utiliser toujours le même style : soit tout en majuscule, soit tout en minuscule, soit la première lettre en majuscule (les accents sont « tolérés » dans les commentaires).
Note : Jamais de variables (simples, structures, instances, etc.) avec des accents (même si le logiciel le permet) – uniquement des caractères ASCII !!

step 100 nommage correct

Figure 19 : step 100 nommage correct

step 100 nommage incorrect

Figure 20 : step 100 nommage incorrect

3.3.2 La séparation visuelle des fonctions

Le logiciel TIA Portal – Siemens a l’option de rajouter une REGION pliée ou dépliée une délimitation logique du code. Cette facilité n’existe pas en Unity.
Pour un repérage facile dans des sections longues, il faut utiliser des commentaires qui mettent en évidence le passage d’une fonction à une autre comme celle de la Purge vers le transfert.

step 1000 Commenter Purge: start

Figure 21 : step 1000 Commenter Purge: start

En plus pour les commentaires des noms d’étapes, il faudrait mettre :

step 3110 Commentaire step Trieur

Figure 22 : step 3110 Commentaire step Trieur

  1. Le nom de la section : GEST_TRI_PST_TCCI ;
  2. La fonction : POUSSE FIN ;
  3. Le descriptif des actions de l’étape : CONTROLE MESURE | TRIEUR EN PRODUIT.

3.3.3 Séparateur espace

L’utilisation correcte du formatage visuel des caractères espace, tabulation, retour chariot, en plus de l’indentation peut rendre la lecture du code plus simple.
Exemples : toujours un espace (pas plus) devant et derrière un symbole de contrôle tel que " + ", " - ", " * ", " := ", " = ", " < ", " > ", etc.

Exemple de séparateur correct

Figure 23 : Exemple de séparateur correct

Exemple incorrect sans séparateur

Figure 24 : Exemple incorrect sans séparateur

Exemples d’alignement du code en colonne avec tabulation

Exemple correct d'alignement

Figure 25 : Exemple correct d'alignement

Exemple incorrect sans alignement

Figure 26 : Exemple incorrect sans alignement

Exemples : l’espacement entre lignes de code (dans la même section) :

  • 1 ligne de délimitation entre deux étapes de la même fonction ;
  • 2 lignes de délimitation entre deux zones de la même fonction ;
  • 3 lignes de délimitation entre deux fonctions.
Séparateur 1 ligne entre étapes

Figure 27 : Séparateur 1 ligne entre étapes

Séparateur 2 lignes inter zones

Figure 28 : Séparateur 2 lignes inter zones

Séparateur 3 lignes entre fonctions

Figure 29 : Séparateur 3 lignes entre fonctions

Remarques liées au contenu
En dehors des sections atypique (gestion communication, gestion soutirage, etc.), il faut privilégier les grafcets linaire (dans la mesure du possible), avec des étapes simples (pas d’optimisation du code), et des transitions simples.
Exemple : au lieu de traiter un asservissement d’un niveau avec un contrôle supplémentaire d’une vanne et un démarrage d’une pompe dans une seule étape, il faut plutôt faire plusieurs étapes avec des transitions simples.
Il faut éviter les else_if .
Prendre en compte tous les cas possibles :
IF temp >= paramètre THEN … ELSE … END_IF;
au lieu de :IF temp > paramètre THEN … END_IF;
Puis : IF temp < paramètre THEN … END_IF;
Dans le deuxième cas la condition d'égalité temp = paramètre n’est pas prise en compte.
Dans un process pour les situation critiques, il faut utiliser les synchronisations entre les séquences.
Exemple : entre le positionnement d’un circuit et le cycle de la NEP.
Pour les autres cas, il faudrait utiliser d’autres astuces pour rendre le dépannage simple, rapide et sans risque.

Si les séquences sont synchronisées, une mauvaise réinitialisation peut entraîner une casse.

Une solution est l’utilisation des branches (numéros des étapes) pour des fonctions différentes liées au même équipement.
Exemple : la fonction Vidange a alloué les étapes de 1000 à 1999 et la fonction Purge manifold de 2000 à 2999 de la même séquence de gestion. Cette affectation empêche l’activation des deux fonctions en simultanée car une seule étape est active à un moment donné.
Il faut éviter l’insertion des saut généraux liés à plusieurs étapes dans la mesure du possible.
Exemple : si défaut actif et 1120 <= numéro d’étape < 2320, faire un repli sur une étape d’attente. Dans des séquences avec beaucoup de code, le dépannage est très compliqué.