1.3 Variables API, adressage et types de données

La CPU range ses données dans plusieurs zones de mémoire. Trois d'entre elles se désignent directement par une lettre :

• I (input) : la mémoire image des entrées. La CPU y recopie l'état des entrées physiques au début de chaque cycle.
• Q : la mémoire image des sorties. Le programme y écrit, et la CPU recopie ces valeurs vers les sorties physiques.
• M : les mémentos, une zone de travail interne à la CPU, sans lien avec le câblage.

Le fonctionnement en mémoire image a une conséquence pratique : pendant un cycle, le programme travaille sur une « photographie » des entrées. Une entrée qui change en plein cycle ne sera vue qu'au cycle suivant. C'est ce qui rend le comportement du programme reproductible.

Il existe aussi un accès direct à la périphérie, noté avec le suffixe :P (par exemple "Moteur":P). Il contourne la mémoire image. Vous le croiserez surtout dans la table de forçage permanent, qui ne s'applique qu'aux entrées et sorties de périphérie : TIA Portal y ajoute ce suffixe de lui-même (chapitre 2.3).

Une adresse indique aussi combien de bits on lit. Sans lettre supplémentaire, on accède à un bit : il faut alors préciser l'octet et le bit. Avec B, W ou D, on accède respectivement à un octet, un mot ou un double mot, désigné par le numéro de son premier octet.

Le piège classique est le recouvrement. %MW10 occupe les octets 10 et 11 ; %MW11 occupe les octets 11 et 12. Utiliser les deux dans un même programme, c'est écrire deux fois dans l'octet 11 sans le voir. C'est l'une des raisons pour lesquelles l'éditeur recommande de s'éloigner de l'adressage absolu.

Sous chaque CPU, le dossier Variables API contient une ou plusieurs tables de variables. Chaque ligne associe un nom, un type de données, une adresse et un commentaire. On peut créer plusieurs tables pour ranger les variables par fonction : une par poste de la machine, par exemple.

Exemple pédagogique : les noms et adresses sont ceux d'une machine fictive.

Le commentaire n'est pas un luxe. C'est lui qui dit, au technicien de nuit, sur quel pupitre se trouve le bouton ou à quel endroit est posée la cellule. Recopier le repère du schéma électrique dans le commentaire fait gagner un temps précieux au diagnostic.

On n'est pas obligé de passer par la table pour créer une variable. Dans l'éditeur de programme, un opérande encore inconnu peut être déclaré sur place avec Ctrl+Shift+I (définir la variable), et une variable existante se renomme avec Ctrl+Shift+T : TIA Portal met alors à jour toutes les utilisations.

Chaque variable a un type, qui fixe sa taille et la façon dont la CPU l'interprète. Le type n'est pas une formalité : additionner un entier et un réel, ou comparer une durée à un nombre, oblige à des conversions explicites.

Un cas fréquent : la valeur d'une entrée analogique arrive sous la forme d'un entier brut, pas d'une pression en bars. Il faut la mettre à l'échelle (convertir en réel, puis ramener à l'étendue de mesure du capteur) avant de l'utiliser dans un calcul ou de l'afficher. L'étendue et le codage exacts sont donnés par la documentation du module et du capteur.

Le guide de programmation S7-1200/S7-1500 de l'éditeur formule trois recommandations qui structurent la façon moderne de programmer ces automates.

1. L'adressage symbolique plutôt qu'absolu. On écrit "KM_Moteur_Convoyeur" plutôt que %Q0.0. Le programme se lit sans table de correspondance, et une réaffectation d'adresse ne demande qu'une modification dans la table des variables.

2. Les blocs à accès optimisé. Dans un bloc optimisé, la CPU range elle-même les variables selon leur type, au plus près de ce que le processeur lit le plus vite. L'accès est toujours symbolique, ce qui supprime les incohérences dues à un accès absolu erroné ; une modification de la déclaration ne provoque pas d'erreur d'accès, y compris pour les écrans ; et chaque variable peut être déclarée rémanente individuellement. Les blocs non optimisés ne subsistent sur S7-1200/1500 que pour des raisons de compatibilité.

3. Des blocs de données globaux plutôt que des mémentos. Le titre même de la section du guide est explicite :

« No bit memory but global data blocks » (pas de mémentos, mais des blocs de données globaux).

— Programming Guideline for S7-1200/1500, section 4.2

Les mémentos (%M) restent utilisables, et vous en trouverez dans beaucoup de programmes existants. Mais pour un programme neuf, les données partagées se rangent dans des DB globaux, structurés et nommés. Le chapitre 2.1 montre comment.

Quand plusieurs éléments de la machine se ressemblent (cinq vérins, trois convoyeurs), on ne crée pas cinq fois les mêmes variables à la main. On définit un type de données API (parfois appelé UDT) : une structure qui regroupe, par exemple, la commande, les capteurs de fin de course et le défaut d'un vérin. Il se crée dans le dossier « Types de données API » de l'arbre du projet.

On déclare ensuite autant de variables de ce type que de vérins, ou un ARRAY, un tableau d'éléments identiques indexés. Modifier le type met à jour toutes les variables qui l'utilisent : la cohérence est garantie.

Reste la rémanence : que devient une variable quand la CPU est mise hors tension ? Par défaut, les données reprennent leur valeur initiale au redémarrage. Une variable déclarée rémanente conserve sa dernière valeur : c'est ce qu'on veut pour un compteur de pièces ou une consigne réglée par l'opérateur. Dans les blocs optimisés, la rémanence se règle variable par variable.

Aucune norme n'impose de convention de nommage aux programmes d'automates : chaque entreprise, souvent chaque bureau d'études, a la sienne. L'important est d'en avoir une et de l'appliquer partout dans le projet. Voici un exemple de règles simples :

• un préfixe qui dit ce qu'est l'objet (BP_ bouton, KM_ contacteur, Capteur_, typ_ pour un type) ;
• un nom qui dit ce qu'il fait, pas où il est câblé (Capteur_Presence_Carton plutôt que Entree_3) ;
• pas d'espace ni de caractère accentué, pour éviter les soucis d'échange avec d'autres outils ;
• le repère du schéma électrique dans le commentaire.

Sur une machine existante, on reprend la convention en place, même imparfaite. Un programme qui mélange deux conventions est plus difficile à lire qu'un programme cohérent dans une convention discutable.

Avant de modifier ou de supprimer une variable, il faut savoir qui s'en sert. Les références croisées listent, pour un objet, tous les endroits du projet où il est lu ou écrit : blocs, réseaux, écrans. Elles s'affichent avec Shift+Alt+F11 ; Shift+F11 ouvre les informations de références croisées de l'objet sélectionné.

Dans l'éditeur de programme, on navigue aussi de point d'utilisation en point d'utilisation (Ctrl+Shift+G pour le suivant, Ctrl+Shift+F pour le précédent), et l'on saute à la définition d'un opérande avec Ctrl+Shift+D.

Un cas typique de dépannage : une sortie ne s'active pas. On part de la variable de la sortie, on regarde dans les références croisées quel réseau l'écrit, et l'on remonte les conditions une à une. C'est aussi le moyen de repérer une sortie écrite à deux endroits du programme, un défaut fréquent et déroutant : c'est la dernière écriture du cycle qui l'emporte.