Qu'est-ce qu'un cycle de balayage d'un automate programmable ? Comment les automates programmables exécutent-ils les programmes ?
Chaque automate programmable industriel (API) exécute la même boucle fondamentale dès sa mise sous tension : lecture des entrées, exécution de la logique, écriture des sorties, et répétition. Ce cycle, appelé cycle de balayage, détermine la réactivité de l’API aux événements du monde réel et fixe les performances maximales de tout processus contrôlé.
Comprendre le fonctionnement du cycle d'analyse permet aux programmeurs d'optimiser le code, de résoudre les problèmes de réactivité et de choisir le processeur adapté aux applications exigeantes. Ce guide explique précisément le fonctionnement du cycle d'analyse et les facteurs qui l'influencent.
L'unité centrale de l'automate programmable exécute son programme en boucle continue et séquentielle. Chaque itération complète se compose de quatre phases distinctes.
Le processeur capture l'état actuel de tous les modules d'entrée et stocke ces valeurs dans une section de mémoire dédiée appelée table d'images d'entrée. Cette opération a lieu au début de chaque cycle de balayage.
Pour les entrées numériques, le processeur lit une simple valeur 1 (marche) ou 0 (arrêt). Pour les entrées analogiques, il convertit le signal réel (4-20 mA, 0-10 V ou données d'un capteur de température) en une valeur numérique et la stocke en mémoire.
Cette phase est rapide — généralement de 1 à 10 millisecondes pour l'ensemble du balayage d'entrée, en fonction du nombre de modules d'entrée et de leur configuration.
Une fois les données d'entrée fraîches chargées en mémoire, le processeur exécute le programme utilisateur instruction par instruction. Chaque instruction est évaluée par rapport aux valeurs actuelles de la table d'images d'entrée, et les résultats sont écrits dans la table d'images de sortie.
C’est ici que s’exécutent les instructions logiques en relais, les blocs fonctionnels ou les instructions en texte structuré. Le processeur lit la table d’images d’entrée, effectue des opérations logiques ou arithmétiques et stocke les résultats dans la table d’images de sortie ; mais, point crucial, il n’écrit pas encore dans les modules de sortie physiques.
L'écriture en mémoire est considérablement plus rapide que la communication avec les modules d'E/S physiques. Le report des écritures de sortie physiques jusqu'à la fin de l'analyse garantit que toutes les sorties changent simultanément, évitant ainsi les états intermédiaires instables.
L'analyse du programme est généralement la phase la plus longue. Sa durée est proportionnelle à la taille du programme, à sa complexité et au nombre d'instructions.
Une fois l'analyse du programme terminée, le processeur écrit simultanément les valeurs de la table d'images de sortie dans les modules de sortie physiques. Les sorties numériques s'activent ou se désactivent. Les sorties analogiques appliquent leurs valeurs calculées au processus.
Cette écriture coordonnée garantit que les sorties reflètent un instantané cohérent de l'évaluation logique ; aucune modification de sortie n'est observée pendant l'analyse du programme. L'analyse des sorties dure généralement de 1 à 5 millisecondes selon le nombre de modules de sortie.
La phase finale couvre tout ce que le processeur doit faire entre les cycles :
· Communication avec les panneaux IHM et autres périphériques réseau
· Traitement des instructions temporelles (minuteries, horloge temps réel)
· Mise à jour des diagnostics et des registres de défauts
· Gestion des demandes de communication provenant d'autres automates programmables ou systèmes SCADA
Le temps consacré aux opérations de maintenance varie en fonction de la charge de communication. Un automate programmable avec de multiples connexions IHM et une messagerie réseau importante peut y consacrer un temps considérable.
Le temps de balayage correspond à la durée totale des quatre phases d'un cycle complet. Mesuré en millisecondes, il détermine directement la rapidité de réponse d'un automate programmable aux variations d'entrée.
Valeurs typiques :
· Petit programme (100 à 500 instructions) : 1 à 5 ms
· Programme moyen (1 000 à 5 000 instructions) : 5 à 20 ms
· Programme volumineux (plus de 10 000 instructions) : 20 à 100 ms
Le rapport entre le temps de lecture et la vitesse de la machine est crucial. Une machine d'emballage fonctionnant à 100 emballages par minute dispose de 600 millisecondes par cycle. Si le temps de lecture de l'automate programmable est de 50 ms, la machine dispose encore de 550 ms de temps de réponse ; en revanche, si ce temps atteint 500 ms, la machine ne répond plus.
Pour les applications d'emballage, d'embouteillage ou de contrôle de mouvement à grande vitesse, des temps de balayage inférieurs à 2 ms sont souvent nécessaires.
Une question fréquente : pourquoi le processeur écrit-il dans une table en mémoire plutôt que directement sur les sorties ?
L'approche par table d'images résout trois problèmes. Premièrement, elle garantit des mises à jour atomiques des sorties : chaque sortie d'une analyse donnée reflète la même évaluation logique. Deuxièmement, elle permet aux instructions du programme de lire leurs propres états de sortie sans créer de boucle de rétroaction. Troisièmement, elle réduit considérablement la surcharge liée aux communications d'E/S en regroupant les écritures.
Sans tables d'images, une seule analyse de la logique à relais pourrait déclencher des dizaines d'écritures de sortie individuelles à différents moments de l'exécution, créant un comportement instable de la machine.
L'exécution standard d'un cycle de balayage évalue chaque instruction à chaque balayage, même si les conditions ont changé. Pour la plupart des applications, cela est acceptable, mais cela gaspille du temps CPU en évaluant une logique inactive.
La plupart des automates programmables modernes prennent en charge l'exécution de tâches par interruption ou périodiques pour gérer les événements critiques sans perturber le cycle principal.
Interruptions temporelles (TDI) : exécutent une routine spécifique à un intervalle précis, indépendamment du cycle principal. Utilisées pour le comptage à haute vitesse, le traitement d’encodeurs ou la régulation PID à intervalles fixes.
Interruptions déclenchées par événement : elles s’exécutent lorsqu’une condition spécifique survient (transition sur front d’entrée, événement de communication ou défaut). Les réponses de sécurité critiques utilisent souvent les interruptions pour garantir le temps de réponse quelle que soit la position de balayage principale.
Pour Siemens S7-1500, la logique temps réel peut s'exécuter dans des blocs d'organisation d'interruptions cycliques (OB) avec des priorités configurables. Allen Bradley ControlLogix utilise des tâches périodiques et événementielles avec des fréquences configurables.
Mesure du temps de numérisation : La plupart des environnements de programmation affichent le temps de numérisation en temps réel. Dans Studio 5000, l’onglet Général des propriétés du contrôleur affiche les statistiques d’exécution. Dans TIA Portal, le menu En ligne > Diagnostics fournit les données relatives au temps de numérisation.
Réduction du temps de numérisation :
· Déplacer les instructions de communication (fonctions MSG) hors de l'analyse du programme principal vers des tâches périodiques
· Simplifiez les expressions complexes : remplacez les opérations arithmétiques imbriquées par des valeurs précalculées lorsque cela est possible.
· Utilisez des références directes plutôt que des balises copiées lorsque cela est possible.
· Réduisez le nombre de messages sur les réseaux EtherNet/IP ou PROFINET.
· Envisagez un processeur plus rapide si le temps d'analyse dépasse les exigences de l'application malgré l'optimisation.
La communication réseau est la cause la plus fréquente d'augmentation inattendue du temps de cycle. Chaque requête IHM, chaque lecture SCADA et chaque message entre automates programmables consomme du temps processeur pendant la phase de maintenance.
Lorsqu'un automate programmable doit communiquer avec de nombreux appareils, la charge de communication peut augmenter plus rapidement que le processeur ne peut la gérer, ce qui entraîne une augmentation progressive des temps de cycle jusqu'à ce qu'un seuil soit franchi et que le comportement de la machine se dégrade.
Bonne pratique : séparer les fonctions de contrôle et de communication réseau critiques en temps réel sur des segments de réseau ou des processeurs distincts. Utiliser un processeur pour le contrôle de la machine et un autre pour la collecte et le traitement des données.
Le cycle de balayage d'un automate programmable est essentiel au bon fonctionnement de tout système de contrôle industriel. La compréhension de ses quatre phases (lecture des entrées, exécution du programme, écriture des sorties et maintenance) permet aux programmeurs de concevoir un code efficace et de résoudre les problèmes de réactivité.
Le temps de numérisation n'est pas qu'une simple spécification technique. Il définit le comportement en temps réel de votre machine. Pour la plupart des applications, un temps de numérisation de 10 à 20 ms est imperceptible pour les opérateurs. Pour les équipements à grande vitesse, une milliseconde, voire moins, fait la différence entre un fonctionnement acceptable et une panne catastrophique.
Connaissez les exigences de votre processus. Mesurez le temps de balayage réel en fonctionnement (et pas seulement lors de la mise en service) et concevez votre architecture de contrôle pour maintenir ces performances tout au long du cycle de vie de la machine.
Q : Un processeur plus rapide signifie-t-il toujours un temps de numérisation plus rapide ?
R : Pas toujours. Le temps d'analyse dépend de la complexité du programme, de la charge du réseau et de la configuration des E/S. Un processeur plus rapide est utile, mais l'élimination des instructions inutiles et l'optimisation des communications offrent des gains plus importants dans la plupart des applications.
Q : Que se passe-t-il si une entrée change d'état pendant l'analyse du programme ?
A : Le processeur ne détecte l'événement qu'au début de la prochaine analyse. Si une entrée change en cours d'exécution puis revient à sa valeur initiale avant la prochaine analyse, l'automate programmable risque de ne jamais détecter l'événement. Pour les événements plus rapides que la durée d'une analyse, utilisez un traitement des entrées par interruption.
Q : Quel est l'impact de la modification en ligne sur le temps de numérisation ?
A : Lorsque vous modifiez le programme pendant le fonctionnement de l'automate (édition en ligne), le processeur peut brièvement interrompre l'analyse ou exécuter des opérations supplémentaires pour synchroniser le nouveau code. Des modifications importantes en ligne peuvent entraîner une augmentation temporaire du temps d'analyse de 2 à 5 fois la valeur normale.
Q : Dois-je me préoccuper du temps de numérisation pour les processus lents comme le traitement de l'eau ?
A : Pour les processus s'étalant sur quelques secondes ou minutes, un temps d'analyse de 100 ms est négligeable. Toutefois, les entrées et alarmes liées à la sécurité doivent toujours être traitées avec un délai minimal, quelle que soit la vitesse du processus. Utilisez des interruptions pour toute entrée nécessitant une réponse plus rapide que l'analyse normale.
Q : La durée de numérisation peut-elle varier pendant le fonctionnement ?
R : Oui. Le temps de numérisation est proportionnel à la complexité du programme et à la charge de communication. Une machine inactive peut numériser plus rapidement que la même machine fonctionnant à pleine vitesse de production avec une interaction IHM active et des modifications de recettes.
· [Automates programmables Siemens](https://www.tztechio.com/siemens) — S7-1500, S7-1200
· [Automates programmables Allen Bradley](https://www.tztechio.com/allen-bradley) — ControlLogix, CompactLogix
· [Automates programmables Mitsubishi](https://www.tztechio.com/mitsubishi) — MELSEC iQ-R
Continuez à lire, restez informé, abonnez-vous et nous vous invitons à nous dire ce que vous en pensez.
De plus, avec votre autorisation, nous souhaitons placer des cookies pour rendre votre visite et votre interaction avec slOC plus personnelles. Pour cela, nous utilisons des cookies analytiques et publicitaires. Grâce à ces cookies, nous et des tiers pouvons suivre et collecter votre comportement Internet à l'intérieur et à l'extérieur de super-instrument.com. Grâce à cela, nous et des tiers adaptons super-instrument.com et les publicités à vos intérêts. En cliquant sur Accepter, vous acceptez cela. Si vous refusez, nous utilisons uniquement les cookies nécessaires et vous ne recevrez malheureusement aucun contenu personnalisé. Veuillez consulter notre politique en matière de cookies pour plus d'informations ou pour modifier votre consentement à l'avenir.
Accept and continue Decline cookies
