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 :
Figure 17 : step 1110 indentation correcte
Exemple correct d'indentation.
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 !!
Figure 19 : step 100 nommage correct
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.
Figure 21 : step 1000 Commenter Purge: start
En plus pour les commentaires des noms d’étapes, il faudrait mettre :
Figure 22 : step 3110 Commentaire step Trieur
- Le nom de la section : GEST_TRI_PST_TCCI ;
- La fonction : POUSSE FIN ;
- 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.
Figure 23 : Exemple de séparateur correct
Figure 24 : Exemple incorrect sans séparateur
Exemples d’alignement du code en colonne avec tabulation
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.
Figure 27 : Séparateur 1 ligne entre étapes
Figure 28 : Séparateur 2 lignes inter zones
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 dé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é.

