cRIO et WAGO en EtherCAT : les voies dans un fichier, pas dans le code

Sur plusieurs bancs de test, j'ai utilisé un contrôleur CompactRIO (cRIO) comme maître EtherCAT pour piloter des entrées-sorties déportées WAGO, avec une application LabVIEW Real-Time. Le sujet : l'architecture que j'ai retenue, ce qu'il faut savoir d'EtherCAT côté NI, et la règle de conception qui a le plus simplifié la vie des projets.

Pourquoi cette architecture

• Le cRIO fait tourner l'application temps réel et joue le rôle de maître EtherCAT. Son second port Ethernet, basculé en mode EtherCAT, est réservé au réseau terrain ; le premier reste dédié au poste de développement.
• Les coupleurs WAGO 750-354 reçoivent les modules d'E/S du rail et les exposent sur EtherCAT. Ils se chaînent de port à port, sans switch : la trame fait demi-tour au dernier coupleur et revient au maître.
• Le système WAGO 750/753 offre un très large choix de modules (TOR, analogiques, spéciaux) pour un coût modéré, au plus près du câblage.

EtherCAT côté NI : le Scan Engine commande

• Une seule trame par cycle : chaque esclave lit et écrit sa part de la trame au vol. Un compteur (Working Counter) signale dans le cycle même qu'un esclave n'a pas traité ses données.
• Le NI Scan Engine publie chaque donnée sous forme d'I/O variable et rafraîchit toutes les voies ensemble, à une période unique. Il ne met pas les valeurs en mémoire tampon : une valeur non lue avant le scan suivant est perdue.
• Le mode du Scan Engine fixe l'état des esclaves : en mode Active, ils passent en Operational ; en mode Configuration, ils repassent en Pre-Operational. Tout déploiement qui modifie le projet force le mode Configuration.
• Un esclave tiers comme le 750-354 n'apparaît dans le projet qu'après import de son fichier de description (ESI) et un redémarrage de LabVIEW. Sans cela, il reste un « Unknown Device ».

La règle centrale : aucune voie codée en dur

Glisser des I/O variables sur le diagramme convient pour un prototype. Sur un banc qui évolue, le nom de chaque voie se retrouve figé dans le code. J'ai donc séparé deux niveaux de configuration :

• La configuration réseau, gérée par NI : le fichier ESI importé, puis la topologie (maître, coupleurs, modules, période de scan) enregistrée dans le projet LabVIEW et déployée sur le cRIO.
• La configuration des voies, gérée par l'application : un fichier qui associe chaque I/O variable à un alias métier, un type, un sens, une mise à l'échelle et une valeur de repli.

• Un gestionnaire de voies lit le fichier au démarrage et refuse de lancer la boucle de contrôle si une voie n'existe pas, si un type ne correspond pas ou si un alias est en double.
• L'application ne connaît que les alias, jamais les chemins matériels.
• Lire un module entier coûte bien moins cher que lire voie par voie : le gestionnaire lit par module, puis répartit les valeurs par alias.

Résultat : un changement de câblage ou de capteur se traite sans recompiler, et une même application sert plusieurs bancs qui ne diffèrent que par leur fichier de voies.

Les points de vigilance

• L'ordre des modules dans le projet doit refléter l'ordre physique sur le rail : il fixe l'image process du coupleur. Un écart décale toutes les voies.
• Les versions du driver EtherCAT et de LabVIEW doivent être compatibles : je les fige par projet et je les consigne.
• L'état sûr : sur perte de communication, le coupleur WAGO force toutes ses sorties à 0. Je câble donc chaque sortie pour que 0 soit l'état sûr, et j'inclus un test de coupure du câble dans la recette.
• La reprise : après une coupure, le coupleur attend un acquittement du maître. Mon application surveille l'état de chaque esclave et prévoit la séquence de reprise.
• L'alimentation d'un nœud : un module d'alimentation après le coupleur, un module de fin en bout de rail, et un bilan vérifié avec WAGO Smart Designer avant la commande.
• En exploitation, l'application démarre en exécutable sur le cRIO, jamais depuis l'environnement de développement : lancer un VI déclenche un déploiement et peut changer le mode du Scan Engine.

À retenir

• La plupart des difficultés viennent de la configuration (import ESI, ordre des modules, versions), pas du protocole EtherCAT lui-même.
• Déclarer les voies dans un fichier, et non dans le code, rend le banc modifiable sans recompilation.
• La sécurité se conçoit au câblage : 0 doit être l'état sûr de chaque sortie, et la coupure se teste en recette.

Pour aller plus loin

NI, NI-Industrial Communications for EtherCAT and the NI Scan Engine, ni.com ; NI, EtherCAT on CompactRIO, ni.com ; WAGO, 750-354 Fieldbus Coupler EtherCAT, wago.com