Contrôleurs logiques programmables (PLC)

Avant l'avènement des circuits logiques à semi-conducteurs, les systèmes de contrôle logique étaient conçus et construits exclusivement autour de relais électromécaniques. Les relais sont loin d'être obsolètes dans la conception moderne, mais ont été remplacés dans bon nombre de leurs anciens rôles de dispositifs de contrôle de niveau logique, relégués le plus souvent aux applications exigeant une commutation à courant élevé et/ou à haute tension.

Les systèmes et processus nécessitant un contrôle « marche/arrêt » abondent dans le commerce et l'industrie modernes, mais de tels systèmes de contrôle sont rarement construits à partir de relais électromécaniques ou de portes logiques discrètes. Au lieu de cela, les ordinateurs numériques répondent au besoin, qui peut être programmé pour faire une variété de fonctions logiques.

L'histoire des automates programmables

À la fin des années 1960, une société américaine nommée Bedford Associates a sorti un appareil informatique qu'ils ont appelé le MODICON . En tant qu'acronyme, cela signifiait Mod ular Di Con troller, et devint plus tard le nom d'une division de l'entreprise consacrée à la conception, la fabrication et la vente de ces ordinateurs de contrôle à usage spécial.

D'autres sociétés d'ingénierie ont développé leurs propres versions de cet appareil, et il est finalement devenu connu en termes non exclusifs sous le nom d'PLC , ou P rogrammable L logique C contrôleur. Le but d'un automate était de remplacer directement les relais électromécaniques en tant qu'éléments logiques, en substituant à la place un ordinateur numérique à semi-conducteurs avec un programme stocké, capable d'émuler l'interconnexion de nombreux relais pour effectuer certaines tâches logiques.

Ladder Logic et automates de programmation

Un API possède de nombreuses bornes « d'entrée », à travers lesquelles il interprète les états logiques « haut » et « bas » des capteurs et des commutateurs. Il possède également de nombreuses bornes de sortie, à travers lesquelles il émet des signaux "haut" et "bas" pour alimenter les lumières, les solénoïdes, les contacteurs, les petits moteurs et d'autres appareils se prêtant au contrôle marche/arrêt.

Dans un effort pour rendre les API faciles à programmer, leur langage de programmation a été conçu pour ressembler à des schémas logiques à relais. Ainsi, un électricien industriel ou un ingénieur électricien habitué à lire des schémas de logique à relais se sentirait à l'aise de programmer un API pour exécuter les mêmes fonctions de contrôle.

Les automates programmables sont des ordinateurs industriels et, en tant que tels, leurs signaux d'entrée et de sortie sont généralement de 120 volts alternatifs, tout comme les relais de commande électromécaniques qu'ils ont été conçus pour remplacer. Bien que certains automates aient la capacité d'entrer et de sortir des signaux de tension continue de bas niveau de l'amplitude utilisée dans les circuits de porte logique, c'est l'exception et non la règle. Les normes de connexion de signal et de programmation varient quelque peu entre les différents modèles d'API, mais elles sont suffisamment similaires pour permettre ici une introduction « générique » à la programmation d'API.

L'illustration suivante montre un automate simple, tel qu'il peut apparaître d'une vue de face. Deux bornes à vis fournissent une connexion à 120 volts CA pour alimenter les circuits internes de l'API, étiquetés L1 et L2. Six bornes à vis sur le côté gauche permettent la connexion aux périphériques d'entrée, chaque borne représentant un "canal" d'entrée différent avec sa propre étiquette "X".

La borne à vis inférieure gauche est une connexion « commune », qui est généralement connectée à L2 (neutre) de la source d'alimentation 120 VAC.

À l'intérieur du boîtier de l'API, connecté entre chaque borne d'entrée et la borne commune, se trouve un dispositif opto-isolateur (diode électroluminescente) qui fournit un signal logique « élevé » électriquement isolé aux circuits de l'ordinateur (un phototransistor interprète la lumière de la LED ) lorsqu'une alimentation de 120 VCA est appliquée entre la borne d'entrée respective et la borne commune. Une LED d'indication sur le panneau avant de l'API donne une indication visuelle d'une entrée « excitée » :

Les signaux de sortie sont générés par les circuits informatiques de l'API activant un dispositif de commutation (transistor, TRIAC ou même un relais électromécanique), connectant la borne « Source » à l'une des bornes de sortie étiquetées « Y- ». La borne "Source", de manière correspondante, est généralement connectée au côté L1 de la source d'alimentation 120 VAC. Comme pour chaque entrée, une LED d'indication sur le panneau avant de l'automate donne une indication visuelle d'une sortie « excitée » :

De cette façon, l'API est capable de s'interfacer avec des dispositifs du monde réel tels que des commutateurs et des solénoïdes. La logique réelle du système de contrôle est établi à l'intérieur de l'automate au moyen d'un programme informatique. Ce programme dicte quelle sortie est alimentée dans quelles conditions d'entrée.

Bien que le programme lui-même semble être un schéma logique à relais, avec des symboles de commutateur et de relais, il n'y a pas de contacts de commutateur ou de bobines de relais réels fonctionnant à l'intérieur de l'API pour créer les relations logiques entre l'entrée et la sortie. Ce sont des imaginaires contacts et bobines, si vous voulez. Le programme est entré et visualisé via un ordinateur personnel connecté au port de programmation de l'API. Considérez le circuit et le programme API suivants :

Lorsque le bouton-poussoir n'est pas actionné (non enfoncé), aucune alimentation n'est envoyée à l'entrée X1 de l'automate. Suite au programme, qui montre un contact X1 normalement ouvert en série avec une bobine Y1, aucune « puissance » ne sera envoyée à la bobine Y1. Ainsi, la sortie Y1 de l'automate reste hors tension, et le voyant qui lui est connecté reste éteint.

Cependant, si le bouton-poussoir est enfoncé, l'alimentation sera envoyée à l'entrée X1 de l'API. Tous les contacts X1 apparaissant dans le programme prendront l'état activé (non normal), comme s'il s'agissait de contacts de relais actionnés par la mise sous tension d'une bobine de relais nommée « X1 ».

Dans ce cas, la mise sous tension de l'entrée X1 entraînera la « fermeture » ​​du contact X1 normalement ouvert, en envoyant « l'alimentation » à la bobine Y1. Lorsque la bobine Y1 du programme « s'active », la sortie réelle Y1 deviendra alimentée, allumant la lampe qui y est connectée :

Il faut comprendre que le contact X1, la bobine Y1, les fils de connexion et « l'alimentation » apparaissant sur l'écran de l'ordinateur personnel sont tous virtuels . Ils n'existent pas en tant que véritables composants électriques. Ils existent en tant que commandes dans un programme informatique - un logiciel uniquement - qui ressemble à un vrai schéma de relais.

Il est tout aussi important de comprendre que l'ordinateur personnel utilisé pour afficher et éditer le programme de l'API n'est pas nécessaire pour le fonctionnement continu de l'API. Une fois qu'un programme a été chargé dans l'API à partir de l'ordinateur personnel, l'ordinateur personnel peut être débranché de l'API et l'API continuera à suivre les commandes programmées.

J'inclus l'affichage de l'ordinateur personnel dans ces illustrations uniquement pour votre bien, pour vous aider à comprendre la relation entre les conditions réelles (fermeture de l'interrupteur et état de la lampe) et l'état du programme (« alimentation » via des contacts virtuels et des bobines virtuelles).

Comportement du système de contrôle

La vraie puissance et la polyvalence d'un automate se révèlent lorsque nous voulons modifier le comportement d'un système de contrôle. L'automate étant un appareil programmable, nous pouvons modifier son comportement en modifiant les commandes que nous lui donnons, sans avoir à reconfigurer les composants électriques qui lui sont connectés.

Par exemple, supposons que nous voulions faire fonctionner ce circuit interrupteur et lampe de manière inversée :appuyez sur le bouton pour que la lampe s'éteigne éteignez , et relâchez-le pour l'activer on . La solution « matérielle » exigerait qu'un interrupteur à bouton-poussoir normalement fermé soit remplacé par l'interrupteur normalement ouvert actuellement en place. La solution "logicielle" est beaucoup plus simple :il suffit de modifier le programme pour que le contact X1 soit normalement fermé plutôt que normalement ouvert.

Dans l'illustration suivante, nous avons le système modifié montré dans l'état où le bouton-poussoir n'est pas actionné (pas étant pressé) :

Dans cette illustration suivante, le commutateur est montré actionné (enfoncé) :

L'un des avantages de la mise en œuvre du contrôle logique dans le logiciel plutôt que dans le matériel est que les signaux d'entrée peuvent être réutilisés autant de fois que nécessaire dans le programme. Par exemple, prenons le circuit et le programme suivants, conçus pour alimenter la lampe si au moins deux des trois interrupteurs à bouton-poussoir sont actionnés simultanément :

Pour construire un circuit équivalent utilisant des relais électromécaniques, trois relais avec deux contacts normalement ouverts chacun devraient être utilisés, pour fournir deux contacts par commutateur d'entrée. En utilisant un API, cependant, nous pouvons programmer autant de contacts que nous le souhaitons pour chaque entrée "X" sans ajouter de matériel supplémentaire, puisque chaque entrée et chaque sortie n'est rien de plus qu'un seul bit dans la mémoire numérique de l'API (soit 0 ou 1) , et peut être rappelé autant de fois que nécessaire.

De plus, comme chaque sortie de l'automate n'est également qu'un bit dans sa mémoire, nous pouvons affecter des contacts dans un programme automate « actionné » par un état de sortie (Y). Prenons par exemple ce système suivant, un circuit de commande marche-arrêt du moteur :

L'interrupteur à bouton-poussoir connecté à l'entrée X1 sert d'interrupteur « Start », tandis que l'interrupteur connecté à l'entrée X2 sert d'« Arrêt ». Un autre contact du programme, nommé Y1, utilise directement l'état de la bobine de sortie comme contact d'étanchéité, de sorte que le contacteur du moteur continue d'être alimenté après le relâchement du bouton-poussoir « Démarrage ». Vous pouvez voir le contact normalement fermé X2 apparaître dans un bloc de couleur, indiquant qu'il est dans un état fermé (« électriquement conducteur »).

Si nous devions appuyer sur le bouton "Démarrer", l'entrée X1 s'activerait, "fermant" ainsi le contact X1 dans le programme, envoyant "l'alimentation" à la "bobine" Y1, activant la sortie Y1 et appliquant une alimentation 120 volts CA au bobine de contacteur de moteur réel. Le contact parallèle Y1 se "fermera" également, verrouillant ainsi le "circuit" dans un état sous tension :

Maintenant, si nous relâchons le bouton-poussoir "Démarrer", le "contact" X1 normalement ouvert retournera à son état "ouvert", mais le moteur continuera à fonctionner car le "contact" scellé Y1 continue d'assurer la "continuité" pour « alimenter » la bobine Y1, gardant ainsi la sortie Y1 sous tension :

Pour arrêter le moteur, il faut appuyer momentanément sur le bouton poussoir « Stop », qui alimente l'entrée X2 et « ouvre » le « contact » normalement fermé », rompant la continuité vers la « bobine » Y1 :

Lorsque le bouton-poussoir « Stop » est relâché, l'entrée X2 se désactive, ramenant le « contact » X2 à son état normal « fermé ». Le moteur, cependant, ne redémarrera pas tant que le bouton-poussoir « Démarrage » n'est pas actionné, car le « scellement » de Y1 a été perdu :

Conception à sécurité intégrée dans les systèmes contrôlés par API

Un point important à souligner ici est que à sécurité intégrée la conception est tout aussi importante dans les systèmes contrôlés par API que dans les systèmes contrôlés par relais électromécaniques. Il faut toujours tenir compte des effets d'un câblage défectueux (ouvert) sur le ou les appareils contrôlés. Dans cet exemple de circuit de commande de moteur, nous avons un problème :si le câblage d'entrée pour X2 (l'interrupteur « Stop ») s'ouvrait en panne, il n'y aurait aucun moyen d'arrêter le moteur !

La solution à ce problème est une inversion de logique entre le « contact » X2 à l'intérieur du programme de l'automate et le véritable bouton-poussoir « Stop » :

Lorsque le bouton-poussoir « Stop » normalement fermé n'est pas actionné (non enfoncé), l'entrée X2 de l'API sera alimentée, « fermant » ainsi le « contact » X2 à l'intérieur du programme. Cela permet de démarrer le moteur lorsque l'entrée X1 est alimentée, et lui permet de continuer à fonctionner lorsque le bouton-poussoir « Démarrage » n'est plus enfoncé. Lorsque le bouton-poussoir « Stop » est actionné, l'entrée X2 se désexcite, « ouvrant » ainsi le « contact » X2 à l'intérieur du programme de l'automate et arrêtant le moteur.

Ainsi, nous voyons qu'il n'y a pas de différence opérationnelle entre cette nouvelle conception et la conception précédente. Cependant, si le câblage d'entrée sur l'entrée X2 venait à échouer, l'entrée X2 se désexciterait de la même manière que lorsque le bouton-poussoir « Stop » est enfoncé. Le résultat, alors, pour une panne de câblage sur l'entrée X2 est que le moteur s'arrête immédiatement.

Il s'agit d'une conception plus sûre que celle illustrée précédemment, où une défaillance du câblage de l'interrupteur « Stop » aurait entraîné une incapacité pour éteindre le moteur. En plus des éléments de programme d'entrée (X) et de sortie (Y), les automates fournissent des bobines et des contacts « internes » sans connexion intrinsèque avec le monde extérieur. Ceux-ci sont utilisés de la même manière que les « relais de contrôle » (CR1, CR2, etc.) sont utilisés dans les circuits de relais standard :pour fournir une inversion de signal logique si nécessaire.

Pour démontrer comment l'un de ces relais "internes" peut être utilisé, considérons l'exemple de circuit et de programme suivant, conçu pour émuler la fonction d'une porte NAND à trois entrées. Étant donné que les éléments du programme API sont généralement conçus par des lettres simples, j'appellerai le relais de contrôle interne « C1 » plutôt que « CR1 » comme il serait d'usage dans un circuit de contrôle de relais :

Dans ce circuit, la lampe restera allumée tant que tout des boutons-poussoirs restent inactifs (non enfoncés). Pour éteindre la lampe, nous devrons actionner (appuyer) tout trois commutateurs, comme ceci :

Fonctionnalité API avancée

Cette section sur les automates programmables n'illustre qu'un petit échantillon de leurs capacités. En tant qu'ordinateurs, les automates programmables peuvent exécuter des fonctions de temporisation (pour l'équivalent de relais temporisés), de séquençage de tambour et d'autres fonctions avancées avec une précision et une fiabilité bien supérieures à celles possibles à l'aide de dispositifs logiques électromécaniques. La plupart des automates ont une capacité de bien plus de six entrées et six sorties. La photographie suivante montre plusieurs modules d'entrée et de sortie d'un seul automate Allen-Bradley.

Chaque module ayant seize « points » d'entrée ou de sortie, cet API a la capacité de surveiller et de contrôler des dizaines d'appareils. Installé dans une armoire de commande, un automate prend peu de place, surtout compte tenu de l'espace équivalent qui serait nécessaire à des relais électromécaniques pour assurer les mêmes fonctions :

Surveillance et contrôle à distance des automates via des réseaux informatiques numériques

Un avantage des automates qui ne ne peuvent tout simplement pas être dupliqué par des relais électromécaniques est la surveillance et le contrôle à distance via des réseaux informatiques numériques. Parce qu'un automate n'est rien de plus qu'un ordinateur numérique à usage spécial, il a la capacité de communiquer assez facilement avec d'autres ordinateurs. La photographie suivante montre un ordinateur personnel affichant une image graphique d'un processus réel au niveau du liquide (une station de pompage ou de « relevage » pour un système municipal de traitement des eaux usées) contrôlé par un automate programmable.

La station de pompage réelle est située à des kilomètres de l'écran de l'ordinateur personnel :