2.1 Structure du programme : OB, FC, FB et blocs de données

Dans l'arbre du projet, sous la CPU, le dossier Blocs de programme contient tout le code de l'automate. Quand on ajoute un bloc (Ctrl+N dans l'éditeur de programme), TIA Portal propose quatre types. Chacun a une place précise dans l'architecture, et ce n'est pas une question de goût : le type décide de qui peut appeler le bloc et de ce qu'il devient entre deux cycles.

Le guide de programmation S7-1200/S7-1500 publié par l'éditeur (Programming Guideline, entrée 81318674) pose le principe qui guide tout ce chapitre : découper la tâche d'automatisation en unités fonctionnelles, redécouper ces unités en fonctions plus petites, jusqu'à obtenir des blocs réutilisables plusieurs fois avec des paramètres différents. Et définir clairement les interfaces entre ces unités.

Chaque bloc peut être écrit dans n'importe quel langage disponible sur la CPU : un FB en CONT peut appeler une FC écrite en SCL. Le type de bloc et le langage sont deux choix indépendants ; le langage fait l'objet du chapitre suivant.

Les blocs d'organisation sont appelés par le système d'exploitation de la CPU, jamais par votre code. Ce sont eux qui déterminent quand le programme s'exécute. Le guide de l'éditeur liste les situations qu'ils gèrent : le comportement au démarrage, le traitement cyclique du programme, le traitement déclenché par alarme et le traitement des erreurs.

Plusieurs OB Main sont possibles. Le guide précise qu'ils sont traités successivement, dans l'ordre de leur numéro. L'éditeur recommande d'y ranger des parties de programme qui pourraient être remplacées d'une machine à l'autre, et d'éviter les échanges directs entre ces OB : s'ils doivent partager des données, on passe par un DB global. Sur S7-1200 comme sur S7-1500, le guide indique jusqu'à 100 OB cycliques et de démarrage.

D'autres OB existent selon la CPU : alarmes de processus (déclenchées par un front sur une entrée), alarmes cycliques (exécutées à intervalle fixe, utiles pour une régulation), alarmes temporisées, et OB d'erreur. Leur liste exacte dépend de la gamme et de la version de firmware : c'est la boîte de dialogue d'ajout de bloc qui fait foi pour la CPU de votre projet.

Une fonction (FC) est un bloc sans stockage de données d'un cycle à l'autre. Tout ce dont elle a besoin lui est transmis à l'appel par ses paramètres, et tout ce qu'elle produit ressort par ses sorties ou sa valeur de retour. Rien n'est conservé en elle entre deux appels.

Ce que dit le guide de l'éditeur

• les FC n'ont pas de mémoire cyclique ; les paramètres doivent être fournis à chaque appel ;
• une FC peut avoir plusieurs sorties ;
• en SCL, sa valeur de retour se réutilise directement dans une expression, comme une fonction mathématique ;
• pour conserver durablement une donnée produite par une FC, on l'écrit dans un DB global ;
• dans un bloc à accès optimisé, les variables temporaires sont initialisées à leur valeur par défaut à chaque appel (S7-1500 et S7-1200 à partir du firmware V4) : le comportement est reproductible, pas aléatoire.

Usage type : une FC « Mise à l'échelle » qui reçoit une valeur brute de carte analogique et renvoie une grandeur physique, appelée pour chaque capteur de l'installation avec des paramètres différents. Le même code sert dix fois, sans dix copies.

Un bloc fonctionnel (FB) est un bloc avec mémoire. Cette mémoire s'appelle le DB d'instance : chaque appel du FB dispose de son propre bloc de données, dans lequel ses valeurs sont conservées d'un cycle à l'autre. L'appel d'un FB avec son jeu de données s'appelle une instance.

Trois propriétés à retenir, toutes tirées du guide de l'éditeur :

• le DB d'instance n'a pas à être créé à la main : TIA Portal le propose et le crée automatiquement quand on insère l'appel du FB ;
• sa structure est définie par l'interface du FB et ne se modifie que dans le FB ;
• les variables temporaires ne sont pas conservées : elles doivent être initialisées à chaque cycle avant d'être lues.

La recommandation qui en découle : programmer de sorte que les données d'une instance ne soient modifiées que par son FB. Un FB « Moteur » dont personne d'autre n'écrit le DB d'instance peut être copié dans n'importe quel projet sans surprise.

Quand un FB en appelle un autre, le FB appelé peut ranger ses données dans le DB d'instance de l'appelant au lieu d'avoir son propre DB. C'est la multi-instance. Le cas le plus courant : les temporisations et compteurs IEC (TON, TOF, CTU…), qui sont eux-mêmes des FB. Déclarés en multi-instance dans la section Static d'un FB « Convoyeur », ils voyagent avec lui.

Le guide recommande explicitement d'utiliser les blocs « IEC Timer » et « IEC Counter » plutôt que les temporisations SIMATIC adressées de façon absolue, et de les déclarer si possible en multi-instance, pour garder un nombre de blocs réduit.

Depuis la version V14, une instance peut aussi être transmise en paramètre InOut : on écrit une fonction standard et l'instance utilisée n'est choisie qu'au moment de l'appel. C'est une technique avancée, utile pour des bibliothèques de blocs, qu'un débutant peut laisser de côté.

Un DB global contient des données accessibles à tout le programme : consignes, paramètres de recette, état d'une cellule partagé entre plusieurs FB, données échangées avec la supervision. C'est la réponse de l'éditeur à une vieille habitude : le guide consacre une section entière au principe « pas de mémentos, mais des blocs de données globaux ». Là où un ancien programme utilisait des bits %M éparpillés, on range aujourd'hui des variables nommées dans des DB structurés.

Blocs à accès optimisé

Sur S7-1200 et S7-1500, les blocs sont par défaut à accès optimisé : les variables sont rangées par le système selon leur type, et on y accède uniquement par leur nom. Le guide en tire plusieurs avantages : accès toujours le plus rapide possible, pas d'incohérence due à un accès absolu erroné, modifications de déclaration sans erreur d'accès côté supervision, et possibilité de rendre rémanente chaque variable individuellement. Les blocs non optimisés n'existent plus que pour des raisons de compatibilité. Sur S7-1500, un DB optimisé peut dépasser 64 ko, jusqu'à 16 Mo.

Types de données API

Un type de données API (souvent appelé UDT) décrit une structure réutilisable : par exemple « Moteur » = commande, retour de marche, défaut, compteur d'heures. On le définit une fois dans le dossier des types de données API, puis on déclare autant de variables de ce type que nécessaire, dans un DB ou dans l'interface d'un bloc. Modifier le type met à jour toutes ses utilisations. Les tableaux (Array) complètent le dispositif : un tableau de 20 éléments « Moteur » remplace 20 groupes de variables écrits à la main.

Bibliothèques

Enfin, le guide recommande de ranger dans des dossiers les parties de programme qui vont ensemble et de les stocker dans la bibliothèque du projet ou dans une bibliothèque globale, partagée entre projets. C'est ainsi qu'un bureau d'études capitalise ses blocs « Moteur », « Vanne » ou « Alarme » au lieu de les réécrire. Le chapitre sur les variables et types de données détaille les types élémentaires.

Prenons un scénario pédagogique : un convoyeur d'alimentation, deux pompes identiques et une mesure de niveau analogique. Voici un découpage cohérent avec les recommandations de l'éditeur.

1. OB100 : initialise les modes de marche et remet la séquence au repos.
2. OB1 : appelle, dans l'ordre, la gestion des modes, le FB « Convoyeur », deux instances du FB « Pompe », la FC « Mise à l'échelle » du niveau.
3. FB « Pompe » : commande, retour de marche, défaut de discordance, temporisation de surveillance déclarée en multi-instance.
4. FC « Mise à l'échelle » : reçoit la valeur brute et les bornes, renvoie le niveau en unité physique.
5. DB global « Paramètres » : seuils de niveau, temporisations réglables, consignes affichées sur le pupitre.
6. Type de données API « Pompe_Etat » : utilisé dans l'interface du FB et lu par la supervision.