Pourquoi votre cerveau raisonne en ST (et pas en ladder)

Dans l'article Programmation automate : quel langage choisir ?, je vous disais que l'argument le plus important en faveur du ST, c'est que votre cerveau raisonne en ST et pas en langage graphique. Promis, on y revient : le voici.

Écoutez-vous réfléchir

Quand un client vous décrit son besoin, il ne vous dessine pas des contacts et des bobines. Il vous parle en phrases :

« Si la porte reste ouverte plus de 30 secondes alors que l'alarme est armée, on déclenche la sirène. Elle sonne jusqu'à ce que quelqu'un acquitte. »

Et vous, quand vous réfléchissez à la solution, vous faites pareil : si ceci et cela, alors je fais ça, sinon… En ST, cette phrase s'écrit presque mot pour mot :

// Porte ouverte plus de 30 s avec l'alarme armée : on déclenche la sirène
tonPorte(IN := bPorteOuverte AND bAlarmeArmee, PT := T#30S);

IF tonPorte.Q THEN
    bSirene := TRUE;
END_IF

// La sirène sonne jusqu'à l'acquittement
IF bAcquit THEN
    bSirene := FALSE;
END_IF

Le même traitement en ladder (LD) :

     bPorteOuverte   bAlarmeArmee    +-----------+          bSirene
|------| |-------------| |-----------| TON       |-----------(S)----|
|                                    | PT: T#30S |                  |
|                                    +-----------+                  |
|                                                                    |
|      bAcquit                                              bSirene |
|------| |--------------------------------------------------(R)----|

Le schéma est juste. Mais vous ne l'avez pas pensé comme ça : vous l'avez traduit. Le « ET » devient deux contacts en série, le « OU » deviendrait une branche en parallèle, le « jusqu'à » devient une bobine SET et une bobine RESET. Chaque traduction demande un effort, et chaque traduction est une occasion de se tromper.

Ce n'est pas un hasard : le ladder a été conçu pour que les électriciens retrouvent leurs schémas à relais sur les premiers automates. C'est la traduction d'une ancienne technologie, pas de votre raisonnement.

Dès que ça se complique, le graphique décroche

Sur trois lignes de logique, la différence reste faible. Elle devient flagrante dès qu'on sort de la simple combinaison de contacts.

Une séquence

« On attend le départ cycle, puis on sort le vérin. Une fois sorti, on ouvre la vanne pendant 5 secondes, puis on rentre le vérin et on recommence. » Vous venez de décrire des étapes. En ST, ce sont des étapes :

CASE iEtape OF
    0:  // Attente du départ cycle
        IF bDepartCycle THEN
            iEtape := 10;
        END_IF

    10: // Sortie du vérin
        bSortirVerin := TRUE;
        IF bVerinSorti THEN
            iEtape := 20;
        END_IF

    20: // Ouverture de la vanne pendant 5 s
        bVanne := TRUE;
        tonRemplissage(IN := TRUE, PT := T#5S);
        IF tonRemplissage.Q THEN
            tonRemplissage(IN := FALSE);
            bVanne := FALSE;
            iEtape := 30;
        END_IF

    30: // Rentrée du vérin, puis retour au début
        bSortirVerin := FALSE;
        IF bVerinRentre THEN
            iEtape := 0;
        END_IF
END_CASE

On lit le cycle de haut en bas, comme on l'a raconté. En ladder, la même séquence s'éparpille en dizaines de réseaux de bits d'étape, de maintiens et de conditions de transition, et il faut reconstruire le film dans sa tête.

Un calcul sur plusieurs valeurs

« Je veux la moyenne de mes 8 sondes de température, sans compter celles qui sont en défaut. » En ST :

VAR
    arTemperature : ARRAY[1..8] OF REAL;
    abDefautSonde : ARRAY[1..8] OF BOOL;
    rSomme        : REAL;
    rMoyenne      : REAL;
    i, iNbValides : INT;
    bDefautMesure : BOOL;
END_VAR

rSomme := 0.0;
iNbValides := 0;

FOR i := 1 TO 8 DO
    IF NOT abDefautSonde[i] THEN
        rSomme := rSomme + arTemperature[i];
        iNbValides := iNbValides + 1;
    END_IF
END_FOR

IF iNbValides > 0 THEN
    rMoyenne := rSomme / INT_TO_REAL(iNbValides);
    bDefautMesure := FALSE;
ELSE
    bDefautMesure := TRUE;  // plus aucune sonde exploitable
END_IF

Passez à 32 sondes : vous changez un chiffre. En langage graphique, vous recopiez 8 fois (ou 32 fois) les mêmes blocs ADD et SEL, et vous priez pour ne pas avoir décalé un indice en route.

Ce n'est pas qu'une question de goût

Puisque le ST est du texte, tout ce qu'on sait faire avec du texte devient possible :

• Commenter ligne par ligne, au plus près de ce que fait le code, comme dans les exemples ci-dessus.
• Comparer deux versions d'un programme et voir exactement ce qui a changé, ou le suivre dans un gestionnaire de versions comme Git.
• Rechercher et remplacer une variable dans tout le projet en quelques secondes.
• Copier un morceau de code dans un mail, un rapport ou… un article de blog.
• Déboguer précisément : en mode en ligne, Codesys affiche la valeur de chaque variable directement dans le code, et on pose un point d'arrêt sur la ligne qui pose problème.

Et le ladder, alors ?

Il garde sa place. Pour quelques verrouillages simples qu'un électricien de maintenance devra lire sur site, à 3 heures du matin, avec un PC portable posé sur l'armoire, un réseau ladder reste parlant. Le SFC donne une bonne vue d'ensemble d'une grosse séquence, et le CFC se prête bien aux chaînes de régulation.

Codesys permet d'ailleurs de mélanger les langages dans un même projet : chaque POU peut être écrit dans le langage qui lui convient. La bonne question n'est pas « quel langage je préfère ? » mais « qui va lire ce programme, et comment va-t-il le raisonner ? ».

Le test tout simple

La prochaine fois que vous démarrez un programme, écrivez d'abord en français, sous forme de commentaires, ce que l'automate doit faire. Vous verrez que le code ST vient presque tout seul sous chaque commentaire. C'est la preuve que votre cerveau raisonnait déjà en ST.

Pour aller plus loin : Concevoir un programme automate, de l'analyse au code et Codesys : premiers pas en ST.