Allen-Explication des protocoles de communication des automates Bradley : EtherNet/IP, DeviceNet, ControlNet et bien plus encore

Si vous gérez ou maintenez un système de contrôle basé sur Allen-Bradley, vous avez probablement été confronté à cette situation. Un module PLC est abandonné, ou le prix du fournisseur d'origine triple soudainement, et vous commencez à chercher un module de remplacement ou compatible à la place. Les spécifications semblent correctes, le connecteur physique correspond et le prix est raisonnable. Mais avant de passer commande, une question a tendance à passer inaperçue : ce module parle-t-il réellement le même protocole, de la même manière, que celui qu'il remplace ?

C'est la partie de la communication d'Allen-Bradley qui est rarement expliquée clairement. La plupart des guides expliquent ce qu'est EtherNet/IP, DeviceNet ou ControlNet en termes généraux, mais très peu relient ces connaissances aux décisions pratiques auxquelles les ingénieurs sont confrontés lors de l'approvisionnement en pièces détachées. Dans cet article, nous aborderons les principaux protocoles de communication Allen-Bradley PLC, où chacun s'intègre dans un système réel, et, tout aussi important, ce qu'il faut vérifier avant d'acheter un module de remplacement ou compatible afin de ne pas vous retrouver avec un problème de communication après l'installation.

Qu'est-ce qu'un protocole de communication PLC et pourquoi c'est important

Définition en langage clair

Un protocole de communication est simplement un ensemble de règles convenues qui permettent à deux appareils d'échanger correctement des données. Pensez-y comme à un langage partagé : si un automate et une IHM utilisent le même protocole, ils comprennent les messages de chacun. Si ce n’est pas le cas, la connexion peut sembler correcte physiquement alors qu’aucune donnée utilisable ne passe réellement entre eux.

Pourquoi le choix du protocole affecte la disponibilité du système et les coûts de maintenance

Les inadéquations de protocole sont l’une des causes de temps d’arrêt les plus courantes et les plus évitables. Un système de contrôle construit autour d'un protocole inapproprié pour son échelle aura du mal à se développer par la suite, et mélanger des équipements anciens et nouveaux sans vérifier la compatibilité des protocoles conduit souvent à des défauts intermittents difficiles à diagnostiquer car le câblage et l'alimentation semblent corrects. Les coûts de maintenance sont également affectés. Le dépannage d'un problème au niveau du protocole- prend généralement plus de temps que la réparation d'un défaut de câblage, car les symptômes indiquent rarement directement la cause. Comprendre sur quel protocole repose votre système et ce que ce protocole exige de tout appareil qui y est connecté est la première étape pour éviter ces problèmes.

Une fois cette base en place, examinons les protocoles que vous êtes le plus susceptible de rencontrer dans un environnement Allen-Bradley, en commençant par celui qui domine les nouvelles installations aujourd'hui.

Protocoles Ethernet modernes-basés sur

EtherNet/IP

EtherNet/IP (Ethernet Industrial Protocol) est le protocole de communication sur lequel sont construits la plupart des nouveaux systèmes Allen-Bradley. Il fonctionne sur du matériel Ethernet standard et utilise le protocole industriel commun (CIP) au niveau de la couche application, qui est la même base de protocole partagée avec DeviceNet et ControlNet. Cette base commune est l'une des raisons pour lesquelles EtherNet/IP s'intègre si facilement dans une architecture Rockwell Automation.

Quelques éléments font d'EtherNet/IP le choix par défaut pour les nouvelles versions. Il utilise des commutateurs et du câblage Ethernet courants, de sorte que les coûts matériels restent faibles et que les services informatiques peuvent prendre en charge le réseau avec des outils qu'ils connaissent déjà. Il s'adapte bien, car un réseau Ethernet commuté ne partage pas la bande passante entre tous les appareils comme le font les anciens protocoles basés sur un bus-. Et comme EtherNet/IP est si largement adopté, les capteurs, lecteurs et passerelles tiers-le prennent presque toujours en charge dès le départ, ce qui rend l'intégration multi-fournisseurs beaucoup moins pénible qu'auparavant.

Si votre système doit partager des données avec un MES, un historien ou un tableau de bord cloud, EtherNet/IP est proche d'un choix par défaut, car il peut s'asseoir sur le même réseau physique que votre infrastructure informatique sans couche de passerelle distincte.

Quels modèles AB le prennent en charge :La plupart des contrôleurs Allen{{1}Bradley de la-génération actuelle, y compris les plates-formes ControlLogix et CompactLogix, incluent EtherNet/IP en standard, avec un port de communication-intégré. Certains modèles de contrôleurs plus anciens ou plus spécialisés peuvent nécessiter un module de communication supplémentaire-pour atteindre un réseau EtherNet/IP plutôt que de le prendre en charge de manière native. Il est donc préférable de confirmer le modèle spécifique et la révision du micrologiciel plutôt que de supposer une prise en charge sur toute une famille de produits. Si vous recherchez un contrôleur ou un module de communication et souhaitez confirmer ce qu'un numéro de pièce spécifique prend en charge, notreAllen-Bradley PLCetModule API Allen-Bradleyles pages répertorient le stock actuel avec les détails du protocole, ou vous pouvez nous envoyer directement le numéro de modèle.

Référence rapide EtherNet/IP

La communication moderne basée sur Ethernet-couvre la plupart des nouvelles installations, mais une grande partie des systèmes Allen-Bradley installés s'appuient encore sur des protocoles antérieurs à EtherNet/IP. Ceux-ci sont encore très utilisés, il vaut donc la peine de les comprendre également.

Anciens protocoles basés sur-bus

AppareilNet

DeviceNet connecte des appareils de terrain simples tels que des capteurs, des boutons-poussoirs et des démarreurs de moteur à un automate via un bus partagé, plutôt que de câbler chaque appareil individuellement. Il fonctionne sur la technologie CAN (Controller Area Network) et fonctionne généralement à des vitesses allant jusqu'à 500 kbps en fonction de la longueur du câble. Un avantage pratique est que DeviceNet transporte à la fois l'alimentation et le signal sur le même câble, ce qui réduit les coûts d'installation pour un grand nombre d'appareils simples. Vous le verrez le plus souvent dans les applications discrètes-sensibles aux coûts, telles que les lignes de conditionnement ou les équipements destinés au secteur agroalimentaire, où un grand nombre de capteurs compte plus que le débit brut.

ContrôleNet

ControlNet a été conçu pour une priorité différente : un contrôle déterministe et critique en termes de temps- plutôt qu'un câblage sur site-à faible coût. Il utilise un schéma de découpage temporel-pour garantir la bande passante pour le trafic planifié, ce qui le rend bien adapté aux applications telles que le contrôle de mouvement multi-où la synchronisation des messages doit être prévisible plutôt que simplement rapide. Là où DeviceNet est choisi parce que vous devez connecter de nombreux appareils simples à moindre coût, ControlNet est choisi parce que l'application ne peut pas tolérer une latence variable des messages. Si votre système implique un contrôle coordonné des mouvements ou des processus avec des exigences de synchronisation strictes, ControlNet reste une solution plus appropriée que DeviceNet, même si les deux partagent la même base CIP qu'EtherNet/IP.

Pourquoi ces protocoles sont toujours utilisés et ce qu'il faut surveiller

De nos jours, les nouvelles installations démarrent rarement avec DeviceNet ou ControlNet, mais de nombreux équipements construits à partir de ceux-ci fonctionnent toujours de manière fiable sur le terrain. Remplacer l'intégralité d'un réseau pour passer à EtherNet/IP coûte cher et, dans de nombreux cas, le risque et le coût d'une interruption imprévue lors d'une migration dépassent les avantages liés à la mise à niveau d'un équipement déjà fonctionnel. Le principal défi de maintenance de ces réseaux existants n'est pas le protocole lui-même, mais l'approvisionnement en appareils de terrain et modules de communication compatibles, car les pièces d'origine deviennent plus difficiles à trouver. Lorsqu'un composant DeviceNet ou ControlNet doit être remplacé, la version du protocole et la capacité du nœud méritent d'être soigneusement confirmées, car les réseaux plus anciens pardonnent moins les petites discordances qu'un réseau Ethernet commuté moderne.

Au-delà de ces protocoles-basés sur un bus, les systèmes Allen-Bradley s'appuient également sur une ancienne génération de normes de réseau série et propriétaires qui méritent d'être comprises, en particulier si vous disposez d'un équipement antérieur à DeviceNet.

Protocoles série et autoroute de données

DH+ / DH485

Data Highway Plus (DH+) et DH485 sont les premiers protocoles réseau propriétaires d'Allen-Bradley, développés à l'origine pour relier les automates et les terminaux de programmation avant l'existence des options basées sur Ethernet-. DH+ fonctionne à des vitesses allant jusqu'à environ 230 kbit/s et prend en charge jusqu'à 64 nœuds, en utilisant un schéma de passage de jeton-pour contrôler l'accès au réseau. DH485 est un protocole connexe mais distinct, conçu pour les applications d'atelier à plus courte portée-avec moins de nœuds pris en charge et un débit inférieur. Ni l'un ni l'autre n'est utilisé aujourd'hui dans la conception de nouveaux systèmes, mais les deux exécutent toujours des terminaux de programmation, des interfaces opérateur plus anciennes et des contrôleurs PLC-5 ou SLC-500 existants dans les ateliers de production qui n'ont pas été entièrement mis à niveau.

RS-232 / RS-485

RS-232 et RS-485 ne sont pas des protocoles en soi. Il s'agit de normes de couche physique qui définissent la manière dont les signaux circulent sur un câble, et des protocoles tels que Modbus RTU ou DF1 s'exécutent généralement par-dessus. RS-232 prend en charge une simple connexion point à point sur de courtes distances, couramment utilisée pour la programmation des câbles et des liaisons IHM de base. Le RS-485 prend en charge plusieurs appareils sur un bus partagé sur des distances beaucoup plus longues, c'est pourquoi il reste courant pour connecter de simples IHM ou des instruments tiers à des équipements AB plus anciens. Reconnaître cette distinction est important car un appareil décrit comme « compatible RS-485 » vous informe sur le câblage, pas nécessairement s'il peut réellement communiquer en utilisant le protocole spécifique attendu par votre automate.

Lorsque le matériel d'origine n'est plus disponible

Les équipements fonctionnant sur DH+, DH485 ou sur des liaisons série de base sont souvent vieux de plusieurs décennies et il n'est pas toujours possible de trouver une pièce de rechange d'origine exacte. Lorsque cela se produit, il existe généralement quelques solutions réalistes : localiser un module d'origine utilisé ou remis à neuf, ajouter une passerelle de conversion de protocole pour relier l'ancien réseau à un réseau plus récent, ou trouver un module de remplacement compatible conçu pour prendre en charge le même protocole existant. Chaque option comporte des compromis en termes de coût, de délai de livraison et de supportabilité à long terme, et le choix entre eux dépend généralement de la manière dont le reste du système devrait évoluer au cours des prochaines années.

Cette décision conduit naturellement à une question plus large qui s’applique à tous ces protocoles : comment décider lequel est réellement adapté à un système donné, plutôt que de choisir par défaut celui qui a été utilisé la dernière fois ?

Choisir le bon protocole pour votre système

Vitesse, nombre de nœuds et environnement

Trois facteurs tendent à déterminer la plupart des décisions protocolaires. Les exigences de vitesse viennent en premier : si votre application nécessite une synchronisation inférieure à -milliseconde, comme un contrôle de mouvement coordonné, EtherNet/IP avec un réseau sensible au temps-ou ControlNet est approprié, tandis que des tâches de surveillance simples peuvent s'exécuter confortablement sur des liaisons série beaucoup plus lentes. Le nombre de nœuds est ensuite important : l'architecture commutée d'EtherNet/IP évolue à mesure que le nombre de périphériques augmente, tandis que les protocoles basés sur le bus-comme DeviceNet partagent la bande passante entre chaque nœud connecté, ce qui devient un facteur limitant dans les systèmes plus grands. L'environnement est le troisième facteur : les longs câbles ou les zones électriquement bruyantes privilégient les protocoles dotés d'une forte immunité au bruit ou prenant en charge la fibre optique, tels que ControlNet, par rapport à l'Ethernet en cuivre standard ou aux liaisons série de base.

Mélanger anciens et nouveaux protocoles

Très peu de systèmes réels fonctionnent de bout en bout sur un seul protocole. Il est courant d'avoir une dorsale EtherNet/IP connectant les contrôleurs au réseau informatique, avec des liaisons DeviceNet ou série gérant toujours les anciens appareils de terrain au niveau de la machine. Les passerelles de conversion de protocole sont généralement celles qui relient ces réseaux, mais la passerelle elle-même nécessite le même examen minutieux que tout autre appareil : vérifiez la version du protocole et la gamme de micrologiciels qu'elle prend en charge de chaque côté, car une passerelle qui semble gérer les deux protocoles peut toujours ne pas interpréter correctement certains types de messages si son micrologiciel est obsolète. Tester une passerelle ou un point de transition dans des conditions de fonctionnement réelles, plutôt que de supposer qu'il fonctionnera parce que la fiche technique répertorie les deux protocoles, vaut le temps supplémentaire avant un déploiement complet.

Choisir le bon protocole résout le problème de conception d'un nouveau système, mais pour la plupart des travaux de maintenance et de mise à niveau, la question la plus difficile survient plus tard : lorsque vous devez réellement remplacer ou ajouter un module spécifique, comment vous assurer qu'il communiquera correctement avec tout ce qui est déjà installé ?

Compatibilité des protocoles de communication lors de l'approvisionnement en modules de remplacement

Pourquoi les spécifications du protocole sont négligées

Lorsque les ingénieurs évaluent un module de remplacement ou compatible, leur attention se porte naturellement sur les éléments faciles à comparer : le numéro de pièce correspond-il, le connecteur est-il adapté et le prix est-il raisonnable ? La compatibilité des protocoles est souvent supposée plutôt que vérifiée, en particulier lorsqu'un module semble physiquement identique à l'original. En pratique, deux modules peuvent partager le même connecteur et le même facteur de forme tout en prenant en charge différentes versions de protocole ou gammes de micrologiciels, et cette différence n'apparaîtra que lorsque le périphérique sera installé et ne parviendra pas à communiquer de manière fiable ou communiquera par intermittence d'une manière bien plus difficile à diagnostiquer qu'une panne complète.

Que vérifier avant d'acheter un module de remplacement ou compatible

Avant de commander, il convient de confirmer les éléments suivants par rapport à votre système existant :

• Version du protocole et plage du firmware.Confirmez que le module de remplacement prend en charge la même version de protocole et la même plage de révision du micrologiciel que le périphérique qu'il remplace, et pas seulement le même nom de protocole.
• Vitesse de communication.Vérifiez que le débit en bauds ou le débit de données pris en charge correspond à celui pour lequel le reste de votre réseau est configuré, car une incompatibilité ici peut empêcher une connexion même lorsque le protocole lui-même est correct.
• Capacité du nœud ou de l’adresse.Pour les réseaux basés sur un bus-comme DeviceNet ou ControlNet, vérifiez que le remplacement prend en charge suffisamment d'adresses de nœuds pour la taille actuelle de votre réseau, en particulier si le système s'est développé depuis sa première installation.
• Type d'interface physique.Confirmez que le connecteur et la norme de câblage correspondent exactement, car certains modules prenant en charge le même protocole utilisent toujours des connecteurs physiques différents en fonction de la génération du modèle.
• Besoin d'un module de conversion.Si le remplacement ne prend pas en charge nativement le protocole utilisé par votre système, déterminez si une passerelle ou un module de conversion supplémentaire sera nécessaire et tenez-en compte dans le coût et le temps d'installation.

Si vous n'êtes pas certain de la manière dont une pièce de rechange spécifique se compare à ces points, notre équipe technique peut vous aider à confirmer les spécifications du protocole par rapport à votre configuration existante avant de passer commande via notrepage de demande de renseignements.

Que se passe-t-il lorsque la compatibilité n'est pas vérifiée

Quelques modèles reviennent à plusieurs reprises lorsque la compatibilité des protocoles n'est pas assurée. Un module de remplacement avec une révision de micrologiciel inférieure à celle requise par le périphérique d'origine peut produire des interruptions de communication intermittentes plutôt qu'une panne propre, ce qui rend le défaut plus difficile à retracer car la connexion semble fonctionner une partie du temps. Un module qui prend en charge le protocole correct mais à une vitesse de communication par défaut différente peut ne pas parvenir à établir une connexion jusqu'à ce que le paramètre de vitesse soit corrigé manuellement, ce qui est facile à ignorer si le module précédent a négocié automatiquement. Et sur les réseaux de bus avec une capacité de nœud fixe, l'ajout d'un périphérique de remplacement sans vérifier l'espace d'adressage restant peut provoquer des conflits avec les périphériques existants plutôt que simplement un échec de connexion. Aucune de ces situations n'est difficile à éviter, mais leur diagnostic après l'installation prend beaucoup plus de temps-que leur vérification préalable.

Si vous évaluez actuellement un module de remplacement ou compatible pour un modèle Allen-Bradley spécifique, notre équipe peut vous aider à confirmer la compatibilité du protocole avec votre système existant avant de vous engager dans une commande. Vous pouvez nous joindre via notrepage de contactavec les détails du modèle.

Conseils courants de dépannage des communications

Types de défauts courants

La plupart des problèmes de communication d'Allen-Bradley se répartissent en quelques catégories reconnaissables. Les délais d'attente se produisent lorsqu'un périphérique ne répond pas dans la fenêtre prévue, indiquant souvent un périphérique défaillant, un câble cassé ou un réseau surchargé. Les erreurs de somme de contrôle ou de CRC indiquent une corruption des données pendant la transmission, généralement causée par un bruit électrique ou un câble endommagé plutôt que par un problème de configuration. Des conflits d'adresses se produisent lorsque deux appareils sur le même réseau se voient attribuer la même adresse de nœud, ce qui peut également se produire après qu'un module de remplacement incompatible avec un protocole -ne parvient pas à s'enregistrer correctement. À noter : une incompatibilité de version de micrologiciel ou de protocole sur un appareil de remplacement peut produire des symptômes identiques à ceux d'un délai d'attente ou d'un défaut intermittent, ce qui est une raison de plus pour exclure les problèmes de compatibilité plus tôt que tard.

Étapes de dépannage de base

Avant des diagnostics plus approfondis, commencez par les principes fondamentaux : vérifiez les connexions physiques et l'état des câbles, confirmez que l'adressage du périphérique n'est pas en conflit avec un autre nœud et vérifiez que les paramètres de vitesse de communication correspondent sur l'ensemble du réseau. Des outils standards tels que RSLinx de Rockwell pour parcourir et tester les communications, ou un analyseur de réseau général pour le trafic Ethernet-, peuvent aider à déterminer où se situe le problème dans le réseau. Si ces vérifications de base ne résolvent pas le problème, l'étape suivante consiste généralement à confirmer les détails du modèle de périphérique et du micrologiciel par rapport à la documentation du fabricant pour cette pièce spécifique.

FAQ

 

 

Quel est le protocole de communication le plus couramment utilisé dans les automates Allen-Bradley ?

EtherNet/IP est le protocole le plus courant pour les installations Allen-Bradley actuelles. Il combine le matériel Ethernet standard avec une communication industrielle basée sur CIP-, et la plupart des plates-formes ControlLogix et CompactLogix actuelles le prennent en charge en tant que port standard intégré-.

EtherNet/IP et DeviceNet peuvent-ils être utilisés sur le même système ?

Oui, c'est une configuration courante. De nombreux systèmes utilisent EtherNet/IP comme épine dorsale principale du réseau, tandis que DeviceNet continue de gérer des appareils de terrain plus simples au niveau de la machine, connectés via un contrôleur prenant en charge les deux ou via une passerelle.

Quel protocole de communication ControlLogix utilise-t-il par défaut ?

Les automates ControlLogix sont généralement livrés avec la prise en charge EtherNet/IP intégrée à leur port de communication standard. Des protocoles supplémentaires, tels que ControlNet ou DeviceNet, sont généralement ajoutés via des modules de communication séparés plutôt que via le contrôleur de base seul.

Comment puis-je savoir quel protocole prend en charge mon automate Allen-Bradley existant ?

La vérification du numéro de modèle et de l'étiquette de la pièce sur le contrôleur ou le module de communication est le point de départ le plus fiable, car les protocoles pris en charge varient selon le modèle et selon lequel les modules de communication sont installés. Si vous ne savez pas comment lire les spécifications, notre équipe peut vous aider à confirmer la prise en charge du protocole pour un modèle spécifique.

Que dois-je vérifier avant d'acheter un module CPL de remplacement ou compatible ?

Au minimum, confirmez la version du protocole et la plage du micrologiciel, la vitesse de communication, la capacité du nœud ou de l'adresse et le type de connecteur physique par rapport à votre appareil existant. Un module qui correspond uniquement au numéro de pièce et au connecteur ne garantit pas la compatibilité du protocole.

Les modules-tiers ou compatibles peuvent-ils communiquer de manière fiable avec le matériel Allen-Bradley d'origine ?

Dans de nombreux cas, oui, à condition que la version du protocole, la gamme du micrologiciel et les paramètres de communication soient correctement adaptés au système existant. La fiabilité dépend de la confirmation de ces détails avant l'installation plutôt que de supposer une compatibilité basée uniquement sur l'ajustement physique. Si vous souhaitez qu'un modèle spécifique soit vérifié par rapport à votre configuration, n'hésitez pas à nous contacter via notrepage de demande de renseignements.

Pensées finales

Aucun des protocoles abordés ici n’est particulièrement compliqué en soi. EtherNet/IP, DeviceNet, ControlNet et les anciennes normes DH+ et série résolvent chacun un problème assez spécifique, et une fois que vous savez à quoi chacun d'eux est conçu, choisir entre eux pour un nouveau système est généralement simple. Là où les choses tournent mal, c'est plus tard, lorsqu'un module spécifique doit être remplacé et que les détails du protocole sont supposés plutôt que vérifiés.

Si votre système exécute du matériel Mitsubishi aux côtés d'équipements Allen-Bradley, notre analyse précédente deProtocoles de communication des automates Mitsubishicouvre CC-Link, le protocole MC et Modbus dans le même format pratique.

Si vous recherchez actuellement un module de remplacement ou compatible et souhaitez confirmer qu'il communiquera correctement avec votre configuration existante, notre équipe peut vérifier les détails du protocole et du micrologiciel par rapport à votre modèle spécifique avant de commander. Vous pouvez nous envoyer les détails via notrepage de contact.

Consultation gratuite