Intégration de l’onduleur avec PLC et HMI – Configuration de la communication industrielle

Intégration de l’onduleur avec l’API et l’IHM – de la sélection du protocole au fonctionnement stable en production

L’intégration du variateur à l’automate et à l’IHM est l’une des étapes clés de la mise en service d’un variateur dans l’automatisation industrielle. En pratique, l’objectif est que le variateur ne soit pas un “monde à part” contrôlé localement, mais qu’il fasse partie du système : il doit accepter les commandes de l’API, mettre les données de processus à la disposition de l’IHM, signaler les erreurs et les états d’une manière lisible pour la maintenance et se comporter de manière prévisible en cas d’anomalie de communication. Une intégration bien réalisée ne consiste pas seulement à “être en ligne” sur le bus, mais aussi à assurer un fonctionnement stable à long terme, à l’abri des interférences CEM et d’une logique d’erreur correctement conçue.

Si vous vous demandez“comment intégrer un onduleur“, considérez-le comme un projet à trois niveaux. La première est la couche de communication (c’est-à-dire le protocole, les adresses, les paramètres, le mappage des données). La deuxième est la couche de commande (séquence d’activation/de préparation/de démarrage, verrouillage, verrouillage, comportement en cas d’erreur). La troisième est la couche d’exploitation et de service (diagnostics, journalisation, effacement des alarmes sur l’IHM, contrôle de la version de la configuration). Seule la combinaison de ces trois éléments permet une intégration qui fonctionne non seulement lors de la mise en service, mais aussi des années plus tard – après le remplacement de l’automate, la mise à niveau de l’IHM, les changements de réseau ou l’entretien de l’onduleur.

Vous souhaitez signaler une réparation d’onduleur? Appelez-nous !

Appeler : +48 717 500 983

Ce qu’il faut déterminer avant de configurer l’onduleur (pour ne pas le corriger après coup)

Avant d’aborder les paramètres du variateur et la conception de l’automate, il convient de définir quelques éléments qui déterminent l’ensemble de l’architecture. Le premier élément est la source de commande et la source de référencement de la valeur. Dans de nombreux variateurs, il s’agit de deux paramètres distincts : vous pouvez avoir des commandes de démarrage/arrêt provenant des communications et une référence de vitesse locale, ou vice versa. Si vous faites une erreur à ce niveau, la communication peut fonctionner parfaitement et le variateur ne démarrera pas de toute façon parce que le variateur “attend” une autre source de commande.

La deuxième chose est l’étendue des données requises. L’intégration peut être minimaliste (démarrage/arrêt + point de consigne + état + erreur), mais elle évolue souvent rapidement : l’opérateur souhaite connaître le courant du moteur, le couple, la charge, la température, le compteur d’heures de fonctionnement, les états des E/S du variateur, des informations sur la limitation du couple ou les verrouillages actifs. Il est utile de noter immédiatement ces exigences, car elles ont une incidence sur la longueur des données de processus dans Profibus, sur le PDO dans EtherCAT ou sur la carte de registre dans Modbus.

La troisième question concerne le comportement d’urgence après une perte de communication. C’est le fondement de la sécurité des processus : après une coupure de bus, l’onduleur doit-il descendre en puissance, passer en mode roue libre, effectuer un arrêt rapide ou maintenir la dernière valeur de la tâche pendant un certain temps ? Il n’y a pas de réponse universelle à cette question, car elle dépend de la machine (par exemple, convoyeur, extrudeuse ou ventilateur). Il est important que la décision soit prise en connaissance de cause et non par défaut.

Données de processus : contrôle, état, valeur de consigne, valeur réelle – et tout le reste

Dans la plupart des protocoles industriels, vous rencontrerez un schéma d’intégration répétitif, quel que soit le fabricant du convertisseur. Il y a le mot de commande (control word), qui contient des bits tels que le déverrouillage, le démarrage, la direction, la réinitialisation, l’arrêt rapide. Il y a le mot d’état, qui vous indique si le variateur est prêt, en cours de fonctionnement, s’il a une erreur, un avertissement ou s’il est verrouillé. Il y a ensuite le point de consigne – fréquence, vitesse ou couple – et la valeur réelle.

Dans la pratique, la plupart des problèmes d’intégration ne sont pas dus aux bits eux-mêmes, mais à l’interprétation des nombres. Par conséquent, établissez et décrivez immédiatement dans la conception de l’API : quelle est l’échelle (par exemple, 0-10000 = 0-100,00 Hz), si les données sont signées/non signées, si la vitesse est en tr/min ou en promille, et quel est l’ordre des mots pour les valeurs de 32 bits. Si vous voyez des valeurs telles que -1, 32767 ou des pics irréalistes sur l’IHM, c’est cela qu’il faut vérifier en premier lieu, et non pas si le câble fonctionne.

Couche physique et CEM – la cause la plus fréquente d’instabilité

L’intégration dans un environnement industriel se fait souvent au détriment de la CEM. L’onduleur génère des interférences, le câble onduleur-moteur peut être long, et les installations sont parcourues par un seul chemin de câbles avec des signaux. Par conséquent, même une configuration parfaite du protocole ne sera d’aucune utilité si la couche physique est réalisée “comme au bureau”. En RS-485 (Modbus RTU), une topologie linéaire et une terminaison uniquement aux extrémités du bus sont essentielles. Pour Profibus DP, la terminaison au niveau des prises et la qualité des connecteurs et du blindage sont essentielles. Dans CANopen, sans une terminaison adéquate de 120Ω aux extrémités du bus, le réseau peut fonctionner “parfois”, ce qui est le pire des scénarios car cela rend le diagnostic difficile. En EtherCAT, il est important de maintenir une topologie correcte et des connexions stables, car les dispositifs fonctionnent en mode déterministe et sont sensibles aux erreurs de la couche physique.

Une règle pratique du service : si la communication fonctionne de manière stable sur la table mais se déconnecte de manière aléatoire dans la machine, le problème vient le plus souvent du routage des câbles, du blindage et de la mise à la terre, et non des paramètres de l’automate. Il est également utile de séparer le réseau d’automatisation du réseau de bureau, en particulier avec Ethernet (Modbus TCP), car un trafic excessif et des diffusions peuvent introduire des retards qui déclenchent des chiens de garde.

Comment configurer correctement la communication Modbus, Profibus, EtherCAT ou CANopen ?

Considérez les conseils suivants comme une liste de contrôle pratique. Il ne s’agit pas de théorie de la formation, mais d’éléments qui font une réelle différence pour le succès de l’intégration et la durabilité ultérieure.

• Modbus RTU (RS-485)
  En Modbus RTU, l’automate agit normalement en tant que maître et le variateur en tant qu’esclave. Définissez des paramètres de liaison identiques : vitesse, parité, bits d’arrêt et adresse de l’esclave. Ensuite, vérifiez la carte des registres et la méthode d’adressage – certains fabricants fournissent des registres de type 40001 et d’autres comptent à partir de zéro ; c’est l’une des raisons les plus courantes des “données manquantes”. L’étape suivante consiste à sélectionner les délais d’attente et le nombre de tentatives : des réglages trop agressifs entraîneront une “chute en avalanche” du bus en cas de perturbation momentanée. Il est plus sûr de commencer par un test minimal : lecture de l’état et écriture d’un point de consigne, puis d’ajouter d’autres registres et d’étendre la cartographie.
• Profibus DP
  Dans Profibus, les fichiers GSD, l’adressage DP et la sélection de la longueur des données de processus sont essentiels. Assurez-vous que le fichier GSD est adapté à la version spécifique du variateur et au module de communication. Dans un projet PLC, sélectionnez les modules et les longueurs de PZD pour inclure ce dont vous avez réellement besoin pour le contrôle et les diagnostics. Si l’appareil signale une erreur de configuration, celle-ci est généralement reproductible et due à une incompatibilité entre la conception et le variateur. Si, en revanche, les problèmes sont aléatoires, revenez aux terminaisons, aux connecteurs et au blindage.
• EtherCAT
  Dans le système EtherCAT, l’ajout correct de dispositifs (ESI), la compatibilité topologique et le mappage des PDO constituent la base. Vérifiez les transitions d’état PRE-OP, SAFE-OP et OP, car si le variateur n’entre pas dans l’OP, le problème vient généralement d’un manque de données de processus ou d’un chien de garde. Dans la commande du variateur, la séquence est importante : déverrouillage, conditions de disponibilité, tâche de point de consigne, démarrage. Une erreur fréquente se produit lorsque les données de processus sont échangées mais que le variateur ne démarre pas parce que le mot de commande ne correspond pas au “modèle” de bits attendu.
• CANopen
  Dans CANopen, vous configurez l’ID du nœud, le débit, la transition d’état NMT et le mappage PDO. Du côté de l’automate, chargez l’EDS pour que l’outil comprenne correctement les objets. Ensuite, mappez ce que vous voulez être cyclique au PDO : contrôle/état et point de consigne/réel. Pour la stabilité, définissez le battement de cœur ou la surveillance des nœuds afin que l’automate détecte la perte d’un nœud de manière déterministe et pas seulement “après des symptômes sur le processus”.

Intégration à l’IHM : lisibilité, autorisations et diagnostics

L’IHM est souvent le premier endroit où l’opérateur constate des problèmes avec le variateur. Si l’intégration est réussie, l’IHM n’indique pas seulement une “défaillance”, mais un code d’erreur spécifique et l’état du variateur : si le manque de disponibilité est dû à un verrouillage actif, à une perte de communication, à un manque de validation ou à une erreur d’alimentation. Il est également utile de séparer le contrôle et la visualisation. Le modèle le plus sûr est celui où l’IHM envoie des demandes (par exemple, “démarrage demandé”) et où l’automate ne décide que d’exécuter ou non la commande. Cela réduit le risque que quelqu’un démarre le variateur dans le mauvais état de la machine.

Le journal des événements est très utile au service : erreurs récentes, avertissements, nombre de déconnexions de la communication, températures, courants. Cela permet de déterminer plus rapidement, au moment du rapport, si le problème est strictement lié à la communication ou s’il est d’ordre mécanique (par exemple, surcharge, grippage, court-circuit temporaire dans le moteur).

Logique dans l’automate : séquence de démarrage et robustesse contre la perte de communication

Dans un automate, il est utile de mettre en œuvre une séquence prévisible : d’abord activer, puis vérifier l’état de préparation (mot d’état), puis la tâche du point de consigne et seulement le démarrage. En outre, des mécanismes sont essentiels pour éviter un comportement incontrôlé après le retour de la communication. Une erreur typique est le démarrage automatique après reconnexion, lorsque le bit de démarrage est encore “suspendu” dans les registres et que l’automate ne force pas l’opérateur à acquitter à nouveau. C’est pourquoi il est recommandé de contrôler le démarrage par le bord (edge) et de bloquer le redémarrage après la remise en ligne de l’appareil jusqu’à ce que l’opérateur effectue une action consciente.

Le deuxième élément consiste à contrôler la qualité de la communication. L’indicateur “appareil en ligne” n’est pas suffisant. Un compteur de temps d’attente et un état distinct de “communication instable” pouvant déclencher des procédures de protection sont de bonnes pratiques. Du point de vue de la maintenance, cela permet souvent de détecter un problème (par exemple, un connecteur desserré, un écran frotté) plus rapidement qu’en analysant les codes d’erreur de l’onduleur.

Signalez le problème au service après-vente de RGB pour réparation onduleur en utilisant le formulaire -> signaler une réparation

Appeler : +48 717 500 983