Pourquoi utiliser un automate plutôt qu'un microcontrôleur?

Pourquoi tout le monde utilise-t-il des automates programmables dans des environnements industriels au lieu d'une solution basée sur un microcontrôleur?

Pour une tâche plus longue, le programme de l'automate est aussi compliqué qu'un programme de microcontrôleur.

Une solution basée sur un microcontrôleur peut être plus personnalisable et moins chère.

Je pense que les gens sont un facteur important. Les ingénieurs qui peuvent concevoir un microcontrôleur pour gérer une usine sont en train de fabriquer des lots de petits périphériques. Les ingénieurs qui travaillent sur des automates de marque utilisent des packages logiciels standard, ils ne doivent pas gérer de programmation de bas niveau, la plupart des problèmes rencontrés par quelqu'un d'autre ont déjà été résolus avec ce matériel (communications avec des périphériques étranges, problèmes d'E / S, PID). De plus, les ingénieurs sont interchangeables, avec une bonne spécification ou un bon code indiquant que vous n’avez pas besoin de l’ingénieur qui a construit un système là-bas lorsque vous devez modifier le code.

C'est aussi un peu comme demander pourquoi quelqu'un achèterait un PC alors qu'il pourrait construire son propre ordinateur.

Le coût plus élevé des automates est compensé par les tests (souvent dans des environnements hostiles) auxquels ils sont (ou devraient être) soumis. Pourriez-vous concevoir un système de microcontrôleur personnalisé? Oui, mais alors vous devrez probablement le certifier.

La personnalisation n'est pas vraiment un problème majeur lorsque vous avez une grande usine pleine d'équipement; En fait, vous voulez le contraire, vous voulez que les choses soient aussi standardisées que possible.

En outre, la logique à relais est déjà à peu près normalisée - à l'exception des fonctionnalités propres au fournisseur - qui simplifie le débogage / le portage de logiciels entre automates plutôt que le portage entre différents microcontrôleurs.

L'enjeu environnemental (physique, isolation électrique, EMI, etc.) est énorme et a déjà été couvert par d'autres réponses.

Vous devez également prendre en compte la manière dont les automates vous fournissent un environnement très déterministe. Ils sont bien compris et sont en place depuis les années 1970.

Vous savez combien de temps chaque ligne va prendre et vous avez la garantie que le comportement est basé sur des paramètres d'entrée connus. Avec la programmation en microcontrôleur pur, il peut être compliqué de comprendre exactement comment un changement de fonction affectera le fonctionnement complet du programme.

La logique à relais est facile à comprendre et à programmer pour le contrôle de la machine. Nous avons des électriciens qui les programment sans aucune ingénierie. Ils peuvent facilement dépanner les systèmes électriques de la ligne et effectuer les réparations appropriées. Ils peuvent également écrire leurs propres programmes et apporter des modifications aux programmes existants. L’environnement de débogage est bien meilleur (et je veux dire WAY) mieux que ce que vous pouvez normalement accomplir avec les micros intégrés.

Avec les systèmes de sécurité, il est de plus en plus important d’utiliser des automates de sécurité, ainsi que leurs capacités redondantes et leurs chiens de garde, pour garantir un fonctionnement correct.

Vous savez qu'il y a quelques automates dans la gamme inférieure à 100 $ / ch: Contrôleurs logiques programmables (API) de la série CLICK® (empilable Micro Brick) et beaucoup dans la gamme inférieure à 500 $ avec une entrée / sortie limitée.

Certains modules sont essentiellement des packages de "micro-contrôleurs" industrialisés. Par exemple, la plupart des régulateurs de température PID peuvent être considérés comme tels.

Cela dit, vous pouvez commencer à découvrir des secteurs de l'industrie dans lesquels des ordinateurs dotés d'un système d'exploitation temps réel s'occupent directement des tâches de contrôle et du contrôle de la machine. Cela continuera à se développer spécialement avec les E / S en réseau.

Toutes les personnes qui travaillent avec des automates programmables ne sont pas des experts en électronique.

J'ai commencé à faire de la PLC en tant que pur processus. Je ne pouvais pas utiliser un multimètre, je ne comprenais pas vraiment la différence entre tension et courant. J'avais fait du C dans une classe d'université, mais c'était tout.

Les langues de haut niveau sont énormes. En deux semaines de formation, je pouvais apprendre l’ensemble du jeu d’introduction d’un automate, et c’était suffisant pour la programmation de base. Je n'ai jamais eu à m'inquiéter des bibliothèques, de la gestion des E / S, de l'allocation de mémoire, de ces choses-là.

Et comme mentionné précédemment applications de sécurité. Je ne ferais pas confiance à un microcontrôleur homebref de quiconque revendique une qualification SIL-3.

Pensez aux utilisateurs finaux: un automate est plus convivial pour une personne ayant un arrière-plan EE léger. Plus facile à utiliser, plus facile à maintenir, plus un automate donne un contrôle d'automatisation d'usine de haut niveau. Pensez à une énorme usine qui a besoin de 10 000 fonctions différentes, vous ne pouvez pas toutes les construire, le temps / coût est énorme comparé à l’utilisation de logiciels commerciaux standard.

Si vous êtes un vrai EE, ne prenez pas un tel travail, c’est un travail ennuyeux et peu technologique. Un vrai travail d'EE consiste à utiliser un MCU pour créer un boîtier PLC avec d'autres joueurs.

Un autre facteur qui n’a pas encore été mentionné est que certains fournisseurs d’API ont déployé des efforts considérables pour démontrer que leurs systèmes peuvent se comporter comme prévu, même en présence de divers types d’adversité (en présence d’adversité rendant impossible un fonctionnement normal, on peut se fier au dispositif pour déclencher une sortie de défaut ou faire en sorte que d'autres sorties se mettent dans une condition de sécurité intrinsèque). Bien qu'il soit possible de programmer de nombreux types de microcontrôleurs pour offrir une telle robustesse, même en présence de problèmes pouvant renverser un ou plusieurs bits de registre en cours de fonctionnement (par exemple, en effectuant des calculs redondants à l'aide de formules différentes, de telle sorte qu’une extrême coïncidence serait nécessaire pour écarter les deux ensembles de calculs de manière à produire des résultats cohérents), l’effort requis pour écrire et valider un tel logiciel serait énorme par rapport à la complexité de ce qu’il faisait réellement. Il est beaucoup plus facile d'utiliser un API doté de telles fonctionnalités de sécurité.

D'après mon expérience, j'ai vu à la fois des microcontrôleurs et des automates programmables utilisés dans des environnements industriels.

Le facteur déterminant est "Qui va prendre en charge / maintenir / modifier l'équipement après sa mise en service?"

Dans les environnements industriels, on passe plus de temps à lire (voir Recherche des pannes) que ce qui est passé à l'écrire. Cela ne signifie pas que vous essayez de trouver des problèmes dans le code, mais que vous utilisez le code pour aider à diagnostiquer les problèmes sur le terrain. Ce sont souvent les électriciens qui sont le plus à même de lire des schémas électriques que du code au format texte (d'où la popularité des "langages de programmation" de type graphique, tels que la logique à relais). Sur des sites plus importants, avec des ingénieurs en automatisation dédiés, cela devient un facteur moins important.

Des problèmes d'inertie historique pour une solution particulière sont étroitement liés à ce qui précède. Les antécédents techniques du personnel et l’expérience antérieure avec le matériel et les fournisseurs imposent des conditions préalables pour les projets généralement organisés en lignes telles que ("nous utilisons déjà le fournisseur X et avons des pièces de rechange sous la main - toute mise en œuvre future nécessite l’utilisation de X-YZ ").

"Comment cet équipement va-t-il communiquer avec le reste de mes équipements / de mon usine / de mon site / de ma société?" Ceci est généralement pré-résolu pour les automates et constitue un problème supplémentaire pour les solutions de micro-contrôleurs à faible volume.

J'ai vu des micro-contrôleurs implémentés lorsqu'une solution très personnalisée était justifiée (mais généralement uniquement en tant que projet fournisseur et pris en charge par le fournisseur). Les raisons sont généralement liées à la vitesse d'exécution ou à la nécessité de disposer le matériel et le code très proches (absence de possibilité de retard de communication et nécessité de séparer le processus critique des autres codes non liés).

Le microcontrôleur est un appareil, l'automate est un équipement. Utilisez le microcontrôleur "sur les extrémités" si vous êtes un amateur impécunieux ou si vous êtes un fabricant de produit de masse. Pour les solutions industrielles personnalisées, PLC est le seul choix.

Ils peuvent tous deux atteindre le même objectif. Même si un système piloté par un micro-contrôleur est peut-être meilleur marché, la programmation en code C est une entreprise gigantesque. Pour maîtriser les langues C, des tonnes de formation sont nécessaires.

Cela étant dit, je travaille dans un domaine qui utilise des MCU pour communiquer avec un programme C ++ afin de suivre et de réguler le courant et la tension de grands circuits de charge de redresseur pour batteries industrielles (batteries de plus de 200 AH). Il y a environ 100 redresseurs. Trouver l'ancien AD-DA avec le contrôleur STD et la carte relais est presque impossible. Une fois que ces planches vont mal c'est tout.

C’est la raison pour laquelle nous sommes en train de mettre à niveau tous les automates compacts ou contrôlés logix de la gamme allen bradley. Sont-ils chers? Oui. Est-ce que l'embauche d'un programmeur connaissant le C ++ coûte cher? Oui. En utilisant RS Linx / Logix, plusieurs personnes prêtes à travailler pour l’entreprise peuvent écrire / éditer des programmes à l’aide de ce logiciel. Si l'on ajoute à cela la quantité de support et d'expansion, l'utilisation des API peut être plus rapide et plus rentable.

Un autre facteur à mentionner est le cycle de vie du produit. En règle générale, le support des API est disponible pendant de nombreuses années. Je supporte encore certains automates Texas Instruments de 1985 et 1987. Ils étaient bien construits et extrêmement fiables. Les pièces de rechange sont disponibles dans les centres de réparation industriels ou sur eBay à ce stade et commandent des prix élevés.

Essayez de trouver des puces, des conseils et des outils de remplacement pour faire fonctionner votre micro (insérer votre micro préféré) dans 30 ans.

J'aime les réponses ci-dessus et j'ai pensé que je devrais aussi participer. PLC vs Micro Controller a également beaucoup à voir avec l’échelle et le coût. Par exemple, vous pouvez très rapidement programmer une machine à laver avec un automate. Mais votre machine à laver coûterait trois fois plus cher que le prix de l’automate. Vous concevez donc un microcontrôleur avec un seul programme pouvant être répliqué 100 000 fois. Le coût de l'ingénierie pour cela est élevé, mais plus de 100 000 unités sont très faibles avec un coût final bas pour l'équipement.

Vous pouvez également programmer une centrale électrique complète dans un microcontrôleur. Cependant, vous passerez probablement 20 fois plus de temps à le programmer (et à 20 fois plus de temps à le déboguer) (avec beaucoup de réponses ci-dessus) - Coût matériel réduit oui, mais les ingénieurs sont chers, en particulier les bons. Vous pouvez également utiliser un API avec un coût matériel plus élevé, mais la programmation horaire est beaucoup moins longue, ce qui réduit les coûts d’ingénierie.

Notez également que je ne voudrais pas être une personne qui devait programmer BACnet, Modbus, CIP et un pilote Ethernet HMI dans un micro-contrôleur. Les Plcs peuvent le faire avec quelques cartes supplémentaires et quelques heures de configuration.

Parmi les autres bonnes réponses, en un mot: la normalisation.

Matériel standard, communication standard, IDE de développement standard, langages standard.

Différentes marques offrent des saveurs différentes, mais en général, une fois que vous avez appris une marque de PLC, le changement de marque est plus un fardeau de licence que de technologie.

Pour la programmation standard et les paramètres électriques, il convient d’utiliser un API à la place du microcontrôleur.

Les microcontrôleurs sont utilisés lorsque vous traitez avec des produits, en particulier de faible puissance et de petite taille, comme ceux destinés aux automobiles et à un usage médical. Vous n'utilisez pas de PLC ici.

Mais lorsque vous utilisez des machines telles que le badging, la découpe, etc., vous pouvez facilement utiliser le PLC.

De plus, les automates programmables standardisent l’application des puces intégrées.

Le langage de programmation pour les API est très simple et convivial, les ports d’extension utilisés dans les API sont également plus pertinents en comparaison avec les microcontrôleurs, et principalement "dans les microcontrôleurs si une broche est endommagée, il est plus difficile de dépanner" pour toutes ces raisons. l’industrie utilisera plutôt le microcontrôleur. Il en existe d’autres, mais ce sont là les principaux problèmes auxquels l’industrie doit faire face.

J'ai construit et utilisé des automates au fil des ans. Je suggère qu'il y a une convergence du marché, avec des micros de type PLC Wi-Fi qui coûtent maintenant 49 $ et se vendent comme des petits pains.

Les fabricants de PLC ressentent la pression des prix.

De nouveaux PLCS rentables tels que le logo Siemens peuvent être mieux adaptés à des applications simples.

Les automates programmables qui utilisent Arduino au lieu de la logique à contacts se trouvent juste sur le marché. On en a pour son argent. Rechercher kickstarter pour PLC

-Martin

La réponse simple est de toujours utiliser le PLC. . . . Mais si l’API n’est pas réalisable en raison de facteurs tels que le coût, la taille ou la complexité de l’application, alors nous devrions opter pour le micro-contrôleur car les automates sont plus robustes et sont destinés à l’environnement industriel (impliquant beaucoup de vibrations mécaniques, de hautes températures, de poussières). , pointes électriques, etc.), dont la fiabilité a été testée, utilise des méthodes de programmation standard permettant aux ingénieurs moins compétents d’apporter des modifications, etc.