Limites de connexion Modbus TCP de l’IC693CPU374 expliquées

Limites de connexion Modbus TCP de l’IC693CPU374 : ce que signifie réellement le budget de 16 canaux

Les ingénieurs qui intègrent des automates Series 90-30 anciens posent souvent une question simple : combien de connexions Modbus TCP l’IC693CPU374 peut-il gérer ? La réponse honnête tient moins à un chiffre unique qu’à la façon dont le processeur répartit un pool de communication fixe entre plusieurs protocoles. Cette analyse explique la véritable limite de connexions simultanées, les modes de défaillance auxquels vous serez confronté et les moyens pratiques de protéger votre réseau d’automatisation industrielle.

Comprendre le budget fixe de 16 canaux de communication

L’IC693CPU374 n’offre pas une simultanéité illimitée

Le port Ethernet intégré de l’IC693CPU374 PLUS ne publie pas de nombre de connexions Modbus TCP autonome. Le micrologiciel attribue plutôt un pool fixe de 16 canaux de communication. Ces canaux servent simultanément aux sessions client Modbus TCP, aux sessions serveur SRTP et au trafic d’interrogation des IHM/SCADA. Ainsi, un projet exécutant 12 nœuds d’E/S déportées Modbus TCP et une session IHM Cimplicity atteint déjà la limite. En outre, aucun paramètre de configuration ne permet d’agrandir ce pool, car la limite est codée en dur dans le micrologiciel.

Les rôles de client et de serveur partagent le même pool

Le CPU374 prend en charge le fonctionnement client Modbus TCP au moyen d’instructions COMMREQ. Selon la documentation de l’interface Ethernet Series 90, les canaux 1 à 16 sont réservés aux communications client. Toutefois, les maîtres externes qui interrogent le CPU374 utilisent également des canaux pour les sessions côté serveur. Ainsi, la simultanéité effective dépend entièrement de votre combinaison de trafics. De plus, les deux sens de communication puisent dans le même pool de 16 canaux, si bien que chaque nouvelle connexion IHM ou SCADA réduit la marge disponible pour les E/S de terrain.

Que se passe-t-il lorsque le nombre de canaux dépasse la limite

La 17e COMMREQ renvoie un mot d’état non nul

Le dépassement de la limite de 16 canaux n’entraîne pas de dégradation progressive. L’interface Ethernet rejette plutôt la 17e COMMREQ et renvoie un mot d’état non nul. Le canal reste non alloué, et le programme à relais doit détecter cette valeur CSR non nulle et réessayer ultérieurement. Ignorer le mot d’état empêche la lecture de l’appareil distant et bloque la séquence de commande. Par conséquent, surveillez toujours la valeur CSR dans la logique de votre automate.

Un séquencement incorrect des COMMREQ génère du bruit dans la table des défauts

Une seule fonction COMMREQ par canal peut être en attente à la fois. Si l’unité centrale émet une deuxième requête sur un canal avant que la première ne renvoie un CSR non nul, l’interface consigne l’événement d’exception 08 avec l’entrée 0024H. La table des défauts de l’automate enregistre alors « Défaut de communication sur le fond de panier avec l’automate ; requête perdue ». Cet état de défaut persiste jusqu’à l’effacement de la table, créant du bruit de diagnostic qui masque les véritables problèmes réseau. Par conséquent, séquencez soigneusement vos appels COMMREQ pour éviter ce mode de défaillance subtil.

Les mesures sur site révèlent l’impact du temps de scrutation

Les ouvertures et fermetures coûtent environ 10 cycles de scrutation

Des essais empiriques sur un système CPU374 avec un temps de scrutation de 3,5 à 7,8 millisecondes ont fourni des chiffres concrets sur la latence. Une COMMREQ d’ouverture ou de fermeture nécessitait en moyenne 10 cycles de scrutation. Une opération de lecture ou d’écriture en consommait environ 30. Cela correspond à environ 35 à 78 millisecondes pour une ouverture et à 105 à 234 millisecondes pour un transfert de données. Les conséquences sur la réactivité de la commande sont importantes lorsque plusieurs appareils distants nécessitent une interrogation séquentielle.

Les connexions ouvertes en permanence risquent des déconnexions silencieuses

Les ingénieurs laissent souvent les connexions ouvertes en permanence pour préserver l’allocation des canaux. Cette stratégie risque toutefois d’entraîner des déconnexions silencieuses. Les appareils Modbus TCP tiers imposent fréquemment leurs propres limites de connexion. Certains appareils esclaves n’acceptent que trois canaux simultanés et ferment automatiquement le plus ancien lorsqu’une quatrième connexion arrive. Du côté du CPU374, le canal semble valide, alors que le côté distant a déjà fermé le socket. Les défaillances de communication semblent donc intermittentes plutôt que déterministes.

Les solutions architecturales préservent la marge de canaux

Ethernet Global Data offre une voie producteur-consommateur

Ethernet Global Data (EGD) offre une voie plus efficace pour l’échange déterministe des E/S. EGD fonctionne selon un modèle producteur-consommateur sans utiliser de canaux Modbus TCP. Les praticiens des forums recommandent EGD avec les E/S VersaMax pour les scénarios de commande distribuée nécessitant des données synchronisées sur le cycle de scrutation. Le compromis concerne la compatibilité : EGD nécessite des appareils de l’écosystème GE, tandis que Modbus TCP prend en charge les instruments tiers. De plus, EGD réduit la pression sur les canaux du CPU374 et améliore le déterminisme de l’automatisation en usine.

La ségrégation matérielle ajoute un pool de canaux indépendant

Le CPU374 est doté de deux ports Ethernet commutés 10/100baseT/TX qui partagent une seule adresse IP. L’ajout d’un module Ethernet IC693CMM321 distinct fournit un pool de voies indépendant. Une interface peut gérer le trafic de l’IHM et de la programmation, tandis que la seconde est exclusivement réservée aux équipements Modbus TCP de terrain. Cette séparation empêche un flot d’interrogations de l’IHM de saturer les communications critiques des E/S. De plus, la séparation matérielle est l’une des stratégies d’atténuation les plus fiables pour les infrastructures existantes de la série 90-30.

Les dépendances de configuration et de micrologiciel sont importantes

Machine Edition version 2.60 ou ultérieure est requise

La fonctionnalité Modbus TCP du CPU374 nécessite des versions spécifiques du logiciel de programmation. Machine Edition Logic Developer version 2.60 ou ultérieure est requis pour la configuration. Il se peut que les anciennes versions de VersaPro ne prennent pas en charge l’instruction COMMREQ nécessaire au fonctionnement du client Modbus TCP. La vérification de la compatibilité de la chaîne d’outils avant la mise en service permet d’éviter des heures de dépannage infructueux. Vérifiez donc la version de votre logiciel avant de commencer l’intégration.

La marge de puissance influe sur la stabilité de l’interface Ethernet

Le CPU374 PLUS consomme 1,48 ampère sous 5 volts CC, soit 7,4 watts sur le fond de panier. Cette charge représente environ 60 % de la capacité d’une alimentation standard de la série 90-30. Il est donc recommandé d’utiliser des alimentations haute capacité lorsque le CPU374 partage le fond de panier avec plusieurs modules d’E/S. La marge de puissance influe directement sur la stabilité de l’interface Ethernet sous une charge de communication soutenue. En outre, une tension stable sur le fond de panier réduit le risque d’échecs intermittents de COMMREQ dans les systèmes de commande industrielle.

Point de vue de l’auteur : pourquoi la limite de 16 voies reste importante

Les API existants exigent une conception réseau rigoureuse

En pratique, l’IC693CPU374 reste un outil de travail fiable pour l’automatisation des usines existantes. Cependant, son nombre de voies fixe impose une architecture réseau rigoureuse. Les plateformes API et DCS modernes virtualisent souvent les pools de connexions, mais ce processeur de la série 90-30 ne le peut pas. Je recommande de répertorier chaque client Modbus TCP, chaque session SRTP et chaque interrogation de l’IHM avant la mise en service. En outre, réservez au moins deux voies aux diagnostics et à l’accès de programmation. Cette simple précaution permet d’éviter la plupart des pannes sur site que j’ai observées sur des installations équipées du CPU374.

Cas d’application : coexistence des E/S déportées et de l’IHM

Scénario de déploiement type de la série 90-30

Prenons l’exemple d’une usine de traitement de l’eau équipée d’un CPU374, de 10 îlots d’E/S déportées Modbus TCP et de deux sessions d’interrogation SCADA. Le budget de 16 canaux est presque épuisé avant même qu’un ordinateur portable de maintenance ne se connecte. Lors d’une récente mise à niveau, l’équipe a ajouté un module CMM321 afin d’isoler le trafic IHM des E/S de terrain. Résultat : les erreurs de rejet COMMREQ ont disparu et les variations du temps de cycle ont nettement diminué. Cet exemple montre pourquoi la séparation matérielle reste une solution pratique pour les systèmes de commande qui ne peuvent pas migrer vers un DCS moderne.

Foire aux questions

Combien de connexions Modbus TCP l’IC693CPU374 prend-il en charge ?

Le CPU374 prend en charge un pool fixe de 16 canaux de communication. Ces canaux sont partagés entre les connexions client Modbus TCP, les sessions serveur SRTP et le trafic d’interrogation IHM/SCADA. Par conséquent, le nombre réel de connexions Modbus TCP dépend de la répartition du trafic.

Que se passe-t-il lorsque je dépasse la limite de 16 canaux ?

L’interface Ethernet rejette la 17e COMMREQ avec un mot d’état non nul. Le canal n’est pas alloué et votre programme à relais doit détecter la valeur CSR non nulle et réessayer ultérieurement. Si vous ignorez le mot d’état, la séquence de commande se bloque.

Puis-je augmenter le nombre de canaux à l’aide de la configuration ?

Non. Le nombre de canaux est codé en dur dans le micrologiciel et aucun paramètre de configuration ne permet de l’augmenter. Cependant, vous pouvez ajouter un module Ethernet IC693CMM321 afin de créer un pool de canaux indépendant pour des appareils Modbus TCP supplémentaires.

Pourquoi mes connexions Modbus TCP sont-elles interrompues de façon intermittente ?

Les équipements esclaves tiers imposent souvent leurs propres limites de connexion. Certains n’acceptent que trois canaux simultanés et ferment le plus ancien lorsqu’un quatrième est ouvert. Le CPU374 détecte un canal valide, mais le socket distant est déjà fermé ; les défaillances semblent donc intermittentes plutôt que déterministes.

EGD est-il préférable à Modbus TCP sur le CPU374 ?

EGD est plus efficace pour les échanges d’E/S déterministes, car il utilise un modèle producteur-consommateur et ne mobilise pas de canaux Modbus TCP. Cependant, EGD nécessite des appareils de l’écosystème GE, tandis que Modbus TCP prend en charge les équipements tiers.

Coordonnées

Demandes de renseignements : sales@nex-auto.com
Téléphone / WhatsApp : +86 153 9242 9628

Partenaire NexAuto Technology Limited : https://www.nex-auto.com/

Consultez ci-dessous les articles populaires pour en savoir plus sur AutoNex Controls