Exigences et topologie du commutateur réseau EtherNet/IP Kinetix 5500
Configurez les variateurs servo Allen-Bradley Kinetix 5500 sur EtherNet/IP. Couvre CIP Sync, la synchronisation IEEE 1588 V2, la sélection des commutateurs S...
Les axes servo révèlent rapidement les faiblesses du réseau. L’intégration d’un Kinetix 5500 (2198-xxxx-ERS3) sur un sous-réseau qui transporte déjà les E/S ControlLogix, les adaptateurs de sécurité, le trafic PanelView et les VFD soulève une question pratique : un Stratix administrable est-il indispensable, et quelle topologie permet de maintenir le CIP Sync dans les limites du budget ? La réponse dépend de l’intervalle entre paquets demandé, de la synchronisation temporelle IEEE 1588 V2 et de la gigue — et non du fait que le variateur « réponde au ping ».
Le CIP Motion ne tolère pas la gigue du temps de séjour produite par des équipements non administrables, même lorsque les connexions en unicast semblent fonctionner correctement dans Studio 5000.
Exigences CIP Motion / CIP Sync
| Paramètre | Besoin typique du Kinetix 5500 |
|---|---|
| Période de mise à jour | 1 ms (micrologiciel ERS3 6.xxx+) ; les anciennes familles peuvent nécessiter 2 ms |
| Synchronisation temporelle | CIP Sync (IEEE 1588 V2), maître de temps + horloges transparentes |
| Budget de gigue | Classe inférieure à la microseconde de bout en bout à travers la chaîne de TC |
| Classe de connexion | Classe 1 ; Studio 5000 v28+ utilise souvent par défaut l’unicast pour le 5500 |
| Topologie | Étoile, linéaire ou DLR — pas de cascade improvisée de commutateurs grand public |
Si un commutateur sur le chemin ne fonctionne pas comme horloge transparente (ou ne limite au moins pas le temps de séjour PTP), le variateur refuse la synchronisation et le défaut ressemble à un problème de servomoteur.
Liste de contrôle des fonctionnalités du commutateur
- Horloge transparente IEEE 1588 V2 avec des spécifications strictes concernant le temps de séjour
- QoS matérielle avec priorité stricte pour le DSCP critique en matière de temps (marquages EtherNet/IP et PTP)
- Snooping IGMPv2/v3 lorsque la multidiffusion reste utilisée
- Comportement CIP validé par l’ODVA / Rockwell lorsque possible (familles Stratix 5700/5400/5410)
Les commutateurs non administrables transmettent les trames PTP sans corriger le temps de séjour ; la gigue sur plusieurs sauts peut atteindre plusieurs centaines de microsecondes, ce qui dépasse le budget de mouvement de 1 ms. Des commutateurs administrables tiers peuvent convenir si le PTP TC et la QoS sont correctement configurés, mais vous assumez le risque et perdez les diagnostics Stratix natifs dans l’arborescence des E/S.
Topologie avec peu d’axes : DLR direct depuis l’EN2TR
Pour un ou deux axes, une solution éprouvée consiste à séparer physiquement les réseaux plutôt qu’à acheter dès le départ un commutateur dédié au mouvement :
Port 1 de l’EN2TR -> commutateur de l’usine (IHM, E/S, VFD) Port 2 de l’EN2TR -> Port 1 du Kinetix 5500 (DLR à 2 nœuds) Variateur : Topologie réseau = DLR, nœud (pas superviseur) Période de mise à jour de l’axe = 1 ms (correspond à la RPI)
Le CIP Motion en unicast sur ce segment à deux nœuds évite de solliciter IGMP sur le chemin du mouvement. La longueur du câble doit tout de même respecter les limites du cuivre ; la circonférence de l’anneau correspond à la somme des deux segments lorsque vous étendez ultérieurement la chaîne DLR.
Les domaines de diffusion de l’IHM sont l’ennemi discret des flux Motion à 1 ms sur des sous-réseaux partagés.
Options de segmentation de l’IHM
| Option | Cas d’utilisation |
|---|---|
| Variateur directement connecté au port 2 de l’EN2TR | 1 à 2 axes ; aucun coût supplémentaire de commutation |
| Deuxième module ENxT | Forte charge IHM ou croissance prévue du nombre d’axes |
| Remplacement de l’infrastructure non administrable par un Stratix | Nombreux axes ; sécurité/E/S/IHM mixtes sur un même domaine L2 |
Période de mise à jour par rapport au RPI
Sur un axe Kinetix 5500, la période de mise à jour (propriétés Motion) et le RPI (propriétés de connexion) sont des paramètres liés, mais non identiques. Réglez-les tous deux sur 1 ms pour les micrologiciels ERS3 qui le prennent en charge, et maintenez-les synchronisés. Une incompatibilité est une cause fréquente du message « Connection Not Established » lors de la mise en service. Les fréquences d’annonce PTP sur l’ENxT doivent rester aux valeurs recommandées par Rockwell, sauf indication contraire dans un document d’architecture validé.
Lorsque le nombre d’axes dépasse environ huit à dix variateurs sur une infrastructure partagée non administrable, la gigue cumulée impose généralement une mise à niveau vers un Stratix, même si les connexions unicast semblaient acceptables avec un ou deux axes. Prévoyez ce changement lors de la première modernisation plutôt qu’après le troisième défaut de synchronisation inexpliqué.
Contrôles de mise en service
- Confirmez que le grand maître est bien l’ENxT prévu ; consultez l’état PTP sur le Stratix s’il est présent
- Faites correspondre la période de mise à jour et le RPI ; les incompatibilités provoquent des défauts de connexion
- Vérifiez les listes NS/connexions par rapport aux compteurs du commutateur lorsqu’elles ne concordent pas
- Testez intensivement la navigation de l’IHM pendant que les axes fonctionnent — surveillez les défauts de synchronisation
- Documentez les schémas de topologie ; les commutateurs de bureau « temporaires » deviennent une dette technique permanente
- Relevez une valeur de référence de l’erreur de poursuite de l’axe avant et après un test de sollicitation de l’IHM
La gestion des pièces de rechange pour les équipements Motion et Logix doit suivre les mêmes règles que celles appliquées aux API/PAC et aux contrôleurs discrets, afin qu’une défaillance d’un EN2TR n’immobilise pas une cellule de production.
À propos de l’auteur
Mark Townsend | Ingénieur principal en automatisation – Systèmes Allen-Bradley
Mark Townsend est un ingénieur principal en automatisation qui possède plus de 18 ans d’expérience sur les plateformes Allen-Bradley, notamment ControlLogix, CompactLogix et les anciens systèmes SLC-500. Son travail quotidien porte sur la logique RSLogix / Studio 5000 et la mise en service des IHM FactoryTalk View sur des parcs vieillissants et hétérogènes.