Une dérive intermittente de la glissière est un événement de sécurité machine

Un axe qui se déplace sans recevoir la commande attendue n’est pas un défaut de mise en service courant. Il s’agit d’un événement de mouvement incontrôlé susceptible d’endommager les outils, les structures de la machine, les pièces, les montages et le personnel. Le risque devient plus difficile à gérer lorsque la glissière fonctionne normalement pendant de nombreuses heures avant de se déplacer soudainement à une vitesse ou dans une direction inattendue.

La machine étudiée dans ce cas utilise un Siemens SIMATIC S7-200 CPU 226, une unité SIMOVERT MASTERDRIVES pour les axes des glissières, un MICROMASTER 440 pour la broche et un pupitre opérateur TP 170A. Les données de commande et d’état transitent par un réseau de communication série USS.

Le problème signalé se produit sur une ou deux glissières. Un incident peut survenir une ou deux fois au cours d’une journée de travail, puis être suivi de deux ou trois jours de fonctionnement normal. Les tentatives précédentes comprenaient la séparation du variateur de fréquence de la broche de l’armoire de commande principale et l’amélioration de la mise à la terre. Ces actions n’ont pas supprimé le défaut.

Ce schéma encourage souvent un dépannage spéculatif. Les ingénieurs peuvent remplacer un codeur, modifier le cheminement d’un câble, régler un paramètre du variateur ou ajouter un autre conducteur de mise à la terre. Une modification peut changer temporairement le symptôme, donnant l’impression que le problème est résolu. L’événement se reproduit ensuite, car le chemin réel de la commande n’a jamais été démontré.

Une investigation fiable doit identifier le premier point où le comportement attendu devient anormal. L’équipe doit savoir ce que l’IHM a demandé, ce que l’automate a accepté, ce qu’il a transmis, ce que le variateur a reçu, ce que le variateur a activé en interne et ce que le moteur a réellement fait.

Commencez par confirmer chaque appareil installé

Les systèmes Siemens anciens restent souvent en service longtemps après le départ de l’équipe qui a procédé à la mise en service initiale. Les schémas peuvent comporter des modifications manuscrites. Les sauvegardes de paramètres peuvent être incomplètes. Des modules de remplacement peuvent avoir été installés sans mise à jour de la documentation. L’identification du matériel doit donc précéder l’interprétation des paramètres.

Relevez le numéro de commande complet sur chaque plaque signalétique. Ne vous fiez pas uniquement à une liste d’équipements saisie au clavier. Le numéro de CPU S7-200 indiqué contient des caractères qui ont peut-être été mal recopiés. Le contrôleur réel pourrait correspondre au Siemens 6ES7216-2BD23-0XB0 SIMATIC S7-200 CPU 226, mais l’alimentation et la variante de sortie doivent être confirmées directement sur l’unité installée.

Un seul caractère incorrect peut conduire au mauvais manuel, au mauvais schéma des bornes ou à la mauvaise pièce de rechange. La lettre O est souvent confondue avec le zéro. Le chiffre 1 peut être confondu avec la lettre I. Un suffixe manquant peut également dissimuler une option matérielle importante.

La même rigueur s’applique à l’unité SIMOVERT MASTERDRIVES. MASTERDRIVES désigne une vaste famille et non une conception d’entraînement unique. Les cartes de commande, les versions logicielles, les options d’encodeur, les cartes technologiques et les configurations Vector Control ou Motion Control peuvent modifier les paramètres disponibles et le routage interne des signaux.

Le numéro de commande du MICROMASTER 440 doit également être vérifié. Bien que le MM440 commande la broche plutôt que les coulisseaux, il partage l’environnement de l’armoire et peut partager la liaison de communication USS. Ses événements de commutation, le cheminement des câbles, la configuration des adresses et la temporisation des communications peuvent influer sur l’ensemble du système.

Consignez le modèle du TP 170A, la version du projet IHM, les paramètres de communication et les adresses des API connectés. Le pupitre peut contenir des événements associés aux boutons, des fonctions de recette, des valeurs de démarrage ou un comportement des variables qui ne peuvent pas être identifiés à partir du seul programme de l’API.

Avant de modifier un paramètre, créez des sauvegardes complètes du programme de l’API, du projet IHM, du jeu de paramètres MASTERDRIVES et du jeu de paramètres MM440. Photographiez les blindages des câbles, les commutateurs des cartes, les raccordements aux bornes et les modules en option. Cette référence permet de comparer et d’annuler toute modification ultérieure.

Définir ce que les opérateurs entendent par emballement

Le mot « emballement » peut désigner plusieurs événements différents. Une accélération à pleine vitesse est différente d’un bref déplacement par à-coups involontaire. Un mouvement au démarrage est différent d’un mouvement pendant une séquence automatique. La démarche de diagnostic varie selon la nature exacte de l’événement.

Interrogez chaque personne ayant été témoin du défaut. Demandez des observations plutôt que des conclusions. « L’encodeur est tombé en panne » est une conclusion. « Le coulisseau s’est déplacé rapidement dans le sens positif tandis que l’IHM affichait une vitesse nulle » est une observation.

Consignez l’axe concerné, le sens, la vitesse estimée, la durée, la position initiale, le mode de la machine, l’état de la broche, l’étape active du programme et la méthode qui a arrêté le mouvement. Déterminez si le mouvement a commencé à l’arrêt ou s’il est apparu pendant un déplacement déjà en cours.

Si le coulisseau accélère jusqu’à sa vitesse maximale, examinez la polarité de la contre-réaction, les sources de consigne actives, la séquence d’activation et la régulation de l’entraînement. S’il ne se déplace que sur une courte distance, examinez les bits de marche par à-coups, les déclenchements sur front dupliqués, les commandes obsolètes et les transitions d’état de la séquence.

Si l’événement apparaît uniquement en mode automatique, la logique de séquence devient plus importante. S’il se produit également en mode manuel, concentrez-vous sur l’arbitrage des commandes partagé par les deux modes. Si l’axe se déplace pendant la mise sous tension, la transition de l’unité centrale, la réinitialisation du variateur ou la reconnexion de l’IHM, l’initialisation au démarrage mérite une attention immédiate.

Le comportement à l’arrêt fournit des éléments précieux. Si la suppression du signal d’activation du variateur par l’API arrête l’axe, l’étage de puissance peut encore répondre à la voie d’activation attendue. Si le mouvement continue jusqu’à l’isolement de l’alimentation principale, examinez le matériel du variateur, le câblage d’activation externe, le comportement du contacteur et les sources de commande situées en dehors de l’API.

Déterminez également si le variateur a généré un avertissement ou un défaut. L’absence de défaut ne prouve pas que le variateur était en bon état, mais elle suggère qu’il a peut-être considéré la commande et le retour d’information comme valides.

Considérez la machine comme une chaîne de commande complète

La commande de mouvement peut commencer sur le pupitre opérateur TP 170A. Un bouton, une saisie numérique, une recette, un événement d’écran ou une séquence automatique définit une valeur en mémoire de l’API. Le S7-200 valide cette demande et calcule une vitesse ou une consigne de mouvement. Une routine de communication USS construit ensuite un télégramme contenant les données de commande et de processus.

L’unité MASTERDRIVES reçoit le télégramme et transmet le mot de commande et la consigne dans sa structure interne des signaux. La commande active finale peut également inclure des vitesses fixes, des entrées analogiques, des commandes par bornes, des consignes supplémentaires, des entrées de marche par à-coups ou des blocs fonctionnels internes.

La voie de retour est tout aussi importante. Le moteur ou la charge peut utiliser un codeur incrémental, un résolveur, un tachymètre ou un autre dispositif de retour d’information. Le variateur interprète ce signal comme une vitesse ou une position. Certaines valeurs réelles peuvent ensuite être transmises à l’API.

Les fins de course mécaniques, les capteurs de référencement, les interrupteurs de dépassement de course, les contacteurs, les freins et les contacts de variateur prêt créent des voies supplémentaires. Chaque voie peut influer sur le démarrage, la poursuite ou l’arrêt du mouvement.

Chaque étape doit avoir une valeur mesurable. Dans l’API, enregistrez la demande brute de l’IHM, le mode de fonctionnement sélectionné, l’état de la séquence, la consigne finale validée, le sens, la commande d’activation et le résultat de la communication. Dans le variateur, observez le mot de commande reçu, la consigne reçue, la consigne interne active, la vitesse réelle, l’état du retour d’information, le courant, les avertissements et les défauts.

Un zéro affiché sur l’IHM ne prouve pas que l’API a transmis zéro. Un zéro dans un registre de l’API ne prouve pas qu’une autre source de commande était inactive. Un télégramme USS correct ne prouve pas que le variateur a été configuré pour utiliser ce télégramme comme seule source de consigne.

L’investigation doit identifier le premier endroit où la valeur attendue et la valeur enregistrée divergent. Ce point divise le problème entre la logique de l’IHM, l’application de l’API, la communication, la configuration du variateur, le retour d’information, le matériel de puissance ou la mécanique.

La distinction diagnostique la plus importante

La première question technique est simple : le variateur a-t-il reçu une commande légitime de déplacement ?

Comparez quatre valeurs pendant l’événement :

• La consigne finale de mouvement de l’API.
• La consigne reçue par le variateur.
• La consigne interne active du variateur.
• Le mouvement réel mesuré du moteur ou de la glissière.

Si la consigne finale de l’API devient non nulle et que le variateur la suit, le variateur peut fonctionner correctement. Le mouvement indésirable a été généré en amont. Examinez les événements de l’IHM, la logique de séquence, les valeurs conservées, les transitions de mode et les écritures multiples de la commande finale.

Si la consigne finale de l’API reste à zéro, mais que le variateur reçoit une valeur non nulle, examinez la construction du télégramme, le mappage mémoire, la mise à l’échelle, la gestion des tampons et l’exécution du bloc de communication. La valeur inattendue exacte peut identifier le mécanisme. Une valeur fixe répétée indique souvent des données conservées ou obsolètes. Une valeur positive ou négative extrême peut indiquer un problème de nombre signé ou d’ordre des octets.

Si le variateur reçoit zéro, mais que sa consigne interne active devient non nulle, examinez la configuration du variateur. Une vitesse fixe, une référence analogique, une fonction de marche par à-coups, une entrée de borne, une consigne supplémentaire, un potentiomètre motorisé ou une option technologique peut être actif.

Si la consigne de l’API, la consigne reçue et la consigne interne restent toutes à zéro tandis que le moteur accélère, l’événement est plus grave. Examinez le comportement du retour, la régulation du variateur, l’alimentation de la carte de commande, le matériel du variateur, le comportement de l’étage de sortie et l’accouplement mécanique.

Cette méthode à quatre signaux évite le remplacement incontrôlé de pièces. Elle permet également d’établir une conclusion technique défendable. Le défaut est attribué en fonction des éléments enregistrés plutôt que d’hypothèses.

Le retour est un suspect prioritaire, mais pas un verdict automatique

Un défaut intermittent du codeur ou du tachymètre est plausible, en particulier lorsque l’événement varie avec les vibrations, la température, le mouvement du câble ou la position de la glissière. Toutefois, supposer que toute perte de retour entraîne automatiquement la vitesse maximale est trop général.

Un variateur correctement configuré devrait normalement détecter l’absence de retour ou un retour incohérent et réagir conformément à ses paramètres de surveillance et de défaut. La réponse exacte dépend de la version de la commande, de l’option de retour, de la configuration et de l’application.

Un comportement dangereux peut encore se produire lorsque le signal de retour est présent, mais erroné. Une polarité inversée, une séquence de phases incorrecte, une amplitude de signal instable, des voies endommagées, un type de codeur incorrect, une mise à l’échelle erronée, des accouplements desserrés ou une configuration de régulateur inadaptée peuvent amener le variateur à réagir dans le mauvais sens.

Un câble intermittent tombe rarement en panne sous la forme d’un circuit parfaitement ouvert. Un conducteur peut se séparer uniquement lorsque le câble se plie. Une broche de connecteur peut perdre le contact uniquement en cas de fortes vibrations. L’alimentation de l’encodeur peut chuter lorsqu’un contacteur fonctionne. Le courant de blindage peut déformer une voie différentielle sans supprimer complètement le signal.

Comparez la vitesse réelle indiquée par le variateur à une mesure indépendante. Un tachymètre portatif, un capteur temporaire vérifié ou une mesure appropriée à l’oscilloscope peut établir si la valeur réelle interne correspond au mouvement physique.

Si le variateur indique une vitesse nulle alors que l’arbre tourne, le circuit de retour est suspect. Si le variateur indique la vitesse correcte alors que la consigne devient incorrecte, le retour peut fonctionner normalement.

N’effectuez jamais un test de retour en exposant du personnel à un chariot en mouvement. Utilisez des barrières, une vitesse réduite, des conditions de test contrôlées et une méthode d’arrêt indépendante.

Inspectez l’ensemble du circuit de retour

Un système de retour comprend davantage que l’encodeur. Le capteur, l’accouplement mécanique, le câble, le connecteur, l’alimentation, le blindage, la mise à la terre, la carte d’entrée et la configuration du variateur contribuent tous à la valeur mesurée.

Commencez par la liaison mécanique. Vérifiez que l’arbre de l’encodeur, la courroie, l’engrenage ou l’accouplement flexible ne peut pas patiner. Inspectez les moyeux d’accouplement, les clavettes, les vis de fixation, les fissures, la contamination et le désalignement. Un encodeur mécaniquement déconnecté peut continuer à produire un signal qui ne représente plus le mouvement réel de la charge.

Inspectez chaque connecteur sous un bon éclairage et avec un grossissement suffisant. Recherchez les contacts repoussés, les sertissages faibles, les broches tordues, la corrosion, la contamination par l’huile, les dispositifs anti-traction endommagés et la tension du câble. Vérifiez que les connecteurs de remplacement utilisent le type de contact approprié.

Testez la continuité lorsque la machine est isolée, mais ne vous fiez pas uniquement à un test de résistance statique. Un conducteur fracturé peut conduire lorsqu’il est droit et être coupé lorsqu’il est plié. Dans le cadre d’un test approuvé à faible risque, surveillez le signal de retour pendant que la chaîne porte-câbles se déplace sur sa course normale.

Mesurez l’alimentation de l’encodeur au niveau de l’encodeur pendant son fonctionnement en charge. Une tension stable dans l’armoire ne prouve pas que la tension reste stable au niveau du capteur. Relevez la valeur minimale pendant l’accélération de la broche, l’inversion de l’axe, le freinage et le fonctionnement des contacteurs.

Pour un encodeur incrémental, examinez l’amplitude des voies, leur symétrie, leur relation de phase et l’impulsion d’index, le cas échéant. Les paires différentielles doivent rester équilibrées. Des salves de bruit, des impulsions manquantes ou une amplitude qui s’effondre peuvent indiquer des problèmes de câble, de blindage, d’alimentation ou de capteur.

Vérifiez le type d’encodeur, le nombre d’impulsions, la polarité, la mise à l’échelle et la source de retour dans le jeu de paramètres du variateur installé. Ne supposez pas qu’un numéro de paramètre provenant d’un autre manuel MASTERDRIVES s’applique à cette carte de commande.

Les erreurs USS ne doivent pas être réduites à de simples changements de bits aléatoires

La communication USS fonctionne au moyen d’un télégramme structuré. Le protocole inclut une vérification des erreurs ; un télégramme endommagé devrait donc normalement être rejeté plutôt qu’accepté comme une consigne de vitesse valide sans rapport.

Cela ne signifie pas que l’USS peut être ignoré. Les problèmes de communication peuvent toujours contribuer à un emballement par le comportement de l’application. L’API peut construire un mot de données de processus incorrect. Une valeur signée peut être interprétée incorrectement. Les octets de poids fort et de poids faible peuvent être inversés. D’anciennes données peuvent rester dans un tampon de transmission. L’absence de réponse peut laisser la consigne précédente active.

Des adresses d’esclave en double peuvent également provoquer un comportement déroutant. Chaque variateur du réseau doit utiliser une adresse unique. La séquence d’interrogation de l’API doit associer chaque réponse au bon esclave et à la bonne zone mémoire.

Le mot de commande mérite la même attention que la consigne de vitesse. Un variateur peut rester activé alors que le programme de l’API suppose qu’il a été arrêté. L’acquittement des défauts, les commandes MARCHE/ARRÊT, les bits de direction et la logique de redémarrage peuvent être traités incorrectement pendant la récupération de la communication.

Comptez les transactions réussies, les expirations de délai, les trames rejetées, les échecs consécutifs et les événements de récupération. Un seul bit de « défaut de communication » fournit trop peu d’informations. Les données de diagnostic doivent identifier l’esclave interrogé et la transaction qui a échoué.

Sur le MICROMASTER 440, P2010 concerne la configuration du débit en bauds USS. Ce paramètre ne doit pas être considéré comme un réglage général du délai d’expiration des télégrammes. P2011 est généralement associé à l’adresse USS. La signification de tous les paramètres doit néanmoins être vérifiée dans le manuel MM440 approprié et avec la configuration de l’interface.

Un délai d’attente plus long n’est pas automatiquement plus sûr. Si le variateur continue d’utiliser une consigne non nulle précédente pendant l’attente de l’expiration du délai, l’augmentation de ce délai peut prolonger un mouvement indésirable. Définissez d’abord la réponse requise en cas de perte de communication.

La couche physique RS-485 reste importante

Même lorsque les trames corrompues sont rejetées, un réseau RS-485 instable peut provoquer des retransmissions répétées, des données obsolètes, des mises à jour d’état manquées et une temporisation irrégulière de l’application. Le réseau physique nécessite donc un audit complet.

Documentez le bus depuis le port de communication du S7-200 jusqu’à chaque variateur. Vérifiez que le câblage utilise une topologie linéaire appropriée. Les longues dérivations en étoile peuvent créer des réflexions et doivent être évitées, sauf si la documentation de l’interface installée les autorise explicitement.

Vérifiez que tous les appareils utilisent des paramètres de communication correspondants. Ceux-ci comprennent le débit en bauds, la parité, la structure des télégrammes, la longueur des données de processus et l’adresse de l’esclave. Consignez les paramètres au lieu de les modifier de mémoire.

La terminaison doit respecter les exigences des interfaces et connecteurs Siemens concernés. Une résistance générique de 120 ohms ne doit pas être ajoutée automatiquement. Une terminaison ou une polarisation incorrecte peut dégrader le signal.

Inspectez le type de câble de communication, la continuité du blindage, la liaison des connecteurs et le cheminement. Le câble RS-485 ne doit pas courir sur de longues distances à côté des câbles de sortie moteur, des conducteurs de résistances de freinage, du câblage des contacteurs ou d’autres circuits de puissance à haute fréquence.

Lorsque la séparation est limitée, croisez les câbles de puissance et de signal à environ angle droit. Maintenez une liaison équipotentielle intentionnelle entre les armoires et les différentes parties de la machine. Évitez les longues tresses de raccordement de blindage, qui réduisent l’efficacité aux hautes fréquences.

Si nécessaire, utilisez une sonde différentielle d’oscilloscope appropriée pour examiner la forme d’onde. Recherchez les réflexions, une tension en mode commun excessive, les oscillations amorties, les fronts lents, les salves de bruit et les variations d’amplitude lors de l’accélération de la broche ou du freinage de l’axe.

Un ordinateur portable connecté ou un convertisseur USB peut modifier la mise à la terre et la charge du bus. Notez si le défaut change lorsque l’équipement de diagnostic est connecté.

Les composants utilisés dans la communication et la mise en réseau industrielles doivent être évalués conjointement avec la topologie, le blindage, la terminaison, l’adressage et la gestion des transactions par l’automate. Le remplacement d’un seul connecteur ne corrigera pas une machine à états de communication défaillante.

Examinez le programme S7-200 comme une machine à états

Les défauts intermittents de mise en service apparaissent souvent lors des transitions plutôt qu’en régime stable. La machine peut fonctionner correctement en continu, mais tomber en défaut lors du passage du mode manuel au mode automatique, à la fin de la prise d’origine, après la récupération d’une alarme, lors d’un changement de recette ou après le rétablissement de la communication.

Recherchez dans les références croisées du programme chaque instruction qui écrit dans les variables finales de vitesse, de direction et d’activation. Les anciens programmes écrivent souvent dans le même mot de mémoire V depuis plusieurs réseaux. La dernière écriture exécutée contrôle le résultat, ce qui peut produire un comportement apparemment aléatoire.

Créez une seule étape claire d’arbitrage des commandes. La marche par à-coups manuelle, les déplacements automatiques, la prise d’origine, les fonctions de configuration et les commandes de maintenance doivent entrer dans cette étape sous forme de requêtes distinctes. La consigne finale ne doit être générée qu’après validation du mode, des limites, des retours d’information, de la communication et des conditions permissives de sécurité.

Examinez la logique des impulsions uniques et de la détection de fronts. Une commande prévue pour un seul cycle peut rester active parce que sa mémoire de front a été réutilisée, conservée ou écrasée. Une commande peut également se redéclencher lorsqu’un bit de mode change.

Examinez chaque verrou. Identifiez la condition qui l’active et chacune des conditions qui le réinitialisent. Un verrou de mouvement qui dépend uniquement d’une étape ultérieure de la séquence peut rester actif lorsque la séquence est interrompue par un défaut.

Vérifiez le traitement des données signées. Un entier négatif interprété comme un mot non signé peut devenir une valeur positive élevée. Une multiplication peut provoquer un dépassement de capacité. Un mot copié dans le mauvais ordre des octets peut créer une consigne extrême.

Vérifiez la mise à l’échelle des unités d’ingénierie vers la valeur de processus USS. Appliquez les limites positive et négative après le calcul final, et pas uniquement à l’entrée de l’IHM.

Les systèmes de commande Siemens SIMATIC S7 hérités peuvent fonctionner de manière fiable pendant des décennies, mais leurs applications contiennent souvent des modifications issues de plusieurs étapes de mise en service. Une revue structurée des références croisées est plus utile que de supposer que le matériel de l’UC est devenu instable.

Les états de démarrage et de récupération nécessitent des tests distincts

Des données non initialisées ou rémanentes peuvent provoquer un mouvement rare après des interruptions d’alimentation, des téléchargements de logiciel, des passages de l’UC de STOP à RUN, des réinitialisations du variateur ou une reconnexion de l’IHM.

Identifiez chaque zone de mémoire rémanente utilisée par le programme de mouvement. Déterminez la valeur initiale de la consigne de vitesse, du sens, de l’activation, du mode, de l’étape de séquence, des bits de marche impulsionnelle et de l’état de la communication après chaque type de redémarrage.

La routine de démarrage doit forcer toutes les demandes de mouvement à zéro. Elle doit effacer les commandes de marche impulsionnelle et automatiques en attente, valider les retours d’information, confirmer l’état des fins de course, établir la communication et exiger une nouvelle séquence d’activation délibérée.

Une consigne non nulle conservée ne doit jamais devenir active simplement parce que le variateur devient prêt avant la fin de l’initialisation de l’API.

Testez le démarrage à froid, le redémarrage à chaud, le passage de l’UC de STOP à RUN, la réinitialisation du variateur, la reconnexion de l’IHM et le rétablissement d’un esclave USS défaillant. Effectuez ces tests avec la machine mécaniquement maîtrisée et la vitesse disponible réduite.

Surveillez l’alimentation de commande 24 V lors des événements de mise sous tension. L’API, l’encodeur, l’IHM, l’interface de communication, les contacteurs et l’électronique de commande du variateur peuvent se réinitialiser à des seuils de tension différents. Une brève chute de tension peut laisser un appareil en fonctionnement tandis qu’un autre redémarre.

Enregistrez la séquence entre l’alimentation de commande, le passage de l’API à l’état RUN, le rétablissement de la communication, la disponibilité du variateur, le desserrage du frein et l’autorisation de mouvement. Cet ordre doit être explicite et reproductible.

L’IHM peut générer des commandes qui ne sont plus visibles

Le projet TP 170A doit être examiné avec le programme de l’API. Une commande de l’IHM peut être écrite lors de l’appui ou du relâchement d’un bouton, de l’ouverture ou de la fermeture d’un écran, du téléchargement d’une recette, de la mise à jour d’une variable ou du rétablissement de la communication.

Un bouton de marche impulsionnelle peut créer une situation dangereuse lorsque l’action d’appui active un bit et que l’action de relâchement le désactive. Si la communication échoue pendant que le bouton est enfoncé, la commande de désactivation peut ne jamais parvenir à l’API.

L’opérateur voit ensuite un bouton relâché, mais le bit de l’API reste actif. Une autre transition de mode ou une condition d’autorisation peut alors permettre à la demande de marche par à-coups persistante d’atteindre la commande de mouvement finale.

Une fonction de marche par à-coups robuste ne doit pas reposer uniquement sur un appui suivi d’un relâchement. L’API doit exiger une actualisation continue de la commande, appliquer un délai d’expiration court, valider le mode de fonctionnement et supprimer la commande lorsque les communications deviennent invalides.

Vérifiez chaque événement IHM associé à la marche par à-coups, à la saisie de vitesse, au sens de rotation, à la réinitialisation, à la sélection du mode, à la prise d’origine et à la commande du cycle automatique. Recherchez les balises en double pointant vers la même adresse d’API.

Les entrées numériques nécessitent une vérification de plage à la fois sur le pupitre et dans l’API. L’API doit rejeter les valeurs situées en dehors de la plage d’ingénierie autorisée, même lorsque le champ IHM semble correctement configuré.

Les systèmes IHM Siemens SIMATIC anciens peuvent comporter des comportements au niveau des écrans qui ne sont pas visibles dans la logique de l’API. La journalisation distincte de la balise IHM brute et de la commande API validée aide à identifier la véritable source de la commande.

Le MM440 peut influencer l’événement sans commander la glissière

Le MICROMASTER 440 commande la broche, mais il peut tout de même influencer l’environnement de commande de la glissière. Son redresseur d’entrée, son circuit continu, sa sortie moteur, son circuit de freinage et sa fréquence de commutation peuvent générer des interférences conduites ou rayonnées.

La perturbation la plus forte peut se produire pendant l’accélération ou la décélération de la broche, les pointes de courant ou le freinage, plutôt qu’en fonctionnement stable. Comparez les horodatages des emballements avec l’état de la broche.

Consignez le démarrage et l’arrêt de la broche, les changements de vitesse, le courant, l’état du bus continu, l’historique des défauts et l’activité de freinage. Déterminez si chaque événement se produit pendant une transition similaire de la broche.

Si les unités MM440 et MASTERDRIVES partagent le bus USS, la broche influence également la temporisation des communications. L’API doit interroger chaque esclave de manière prévisible et traiter chaque réponse dans la structure mémoire appropriée.

Vérifiez que les zones de données USS de la broche et de la glissière ne se chevauchent pas. Dans les applications compactes S7-200, la mémoire V est parfois réutilisée sans séparation claire. Un bloc écrit pour la broche peut écraser une partie de la commande de la glissière.

Le fait de déplacer le MM440 à l’extérieur de l’armoire n’élimine pas entièrement son influence. Les câbles moteur, les chemins de mise à la terre, le routage des communications et les alimentations communes peuvent rester connectés.

Utilisez des mesures plutôt que des déplacements répétés. Examinez la séparation des câbles, la mise à la masse des blindages, les selfs réseau ou filtres spécifiés pour le variateur, la mise à la masse de l’armoire, la terminaison du câble moteur et la relation temporelle entre les événements de commutation et les erreurs de communication.

Auditer MASTERDRIVES par fonction du signal

Un audit des paramètres MASTERDRIVES doit suivre l’intégralité du chemin du signal. Ne commencez pas par une liste de numéros de paramètres copiée d’une autre installation.

Vérifiez d’abord la version de commande installée, la version logicielle, la carte de commande et l’option de retour. Examinez ensuite le mode de commande, les données moteur, le type de retour, la mise à l’échelle du retour et la source du retour.

Identifiez chaque source pouvant commander les ordres de MARCHE/ARRÊT du variateur. Il peut s’agir de mots de commande USS, d’entrées sur bornes, de commandes fixes, de connexions de binecteurs internes ou de fonctions technologiques.

Identifiez chaque source pouvant contribuer à la consigne finale de vitesse ou de position. Vérifiez la consigne principale, les consignes supplémentaires, les vitesses fixes, les fonctions de marche par à-coups, les entrées analogiques, les fonctions de potentiomètre motorisé et les blocs fonctionnels internes.

Vérifiez les limites de vitesse positive et négative, les rampes d’accélération, les rampes de décélération, les limites de courant, les limites de couple et les restrictions de sens. Des réglages temporaires prudents peuvent réduire le risque lors du diagnostic, mais ils ne constituent pas une protection de sécurité indépendante.

Examinez la surveillance du retour et la réponse aux défauts. Déterminez ce que le variateur est configuré pour faire lorsque le retour devient absent, instable, inversé ou invraisemblable.

Lisez l’historique des avertissements et des défauts du variateur avant de l’effacer. Un avertissement qui semble sans rapport peut enregistrer le moment où la condition de commande a changé.

Utilisez la méthode d’ingénierie installée, telle que DriveMonitor, la PMU, l’OP1S ou une autre interface approuvée, pour observer les connecteurs internes et les valeurs réelles. Sélectionnez les valeurs en fonction de la version de commande concernée.

Cette approche fonctionnelle s’applique aux systèmes Siemens de variateurs et de contrôle de mouvement anciens comme actuels. Le logiciel de commande, les options de retour et le routage interne peuvent différer même lorsque deux variateurs semblent physiquement similaires.

Créez un enregistreur d’événements déclenchés

Un événement qui se produit une fois par jour ne peut pas être résolu en surveillant l’IHM en continu. Le système a besoin d’un enregistreur de diagnostic qui capture la période précédant et suivant le mouvement anormal.

Créez un tampon circulaire dans l’API contenant la commande brute de l’IHM, la commande validée, la consigne de vitesse finale, le sens, l’autorisation, le mode, l’état de la séquence, les entrées des fins de course, l’état prêt du variateur, le résultat de la transaction USS et un compteur d’échantillons.

Sur le variateur, capturez le mot de commande reçu, la consigne reçue, la consigne interne active, la vitesse réelle, l’état du retour, le courant de sortie, le courant producteur de couple lorsqu’il est disponible, les avertissements et les défauts.

Le déclenchement peut être fondé sur une vitesse réelle supérieure à un faible seuil alors que la commande finale de l’API est nulle. Un autre déclencheur peut détecter un déplacement en dehors de l’état approuvé de la séquence. Une discordance entre le sens commandé et le sens mesuré peut également déclencher l’enregistrement.

Conservez les données antérieures au déclenchement. Si l’enregistrement ne commence qu’après le déplacement de la glissière, la condition initiale peut déjà avoir disparu.

Les diagnostics de communication doivent distinguer les transactions réussies, les réponses manquantes, les messages rejetés, les défaillances consécutives et les événements de récupération. Enregistrez quel esclave était actif au moment de l’erreur.

Gardez la logique de diagnostic compacte. Le S7-200 dispose d’une mémoire et d’une capacité de scrutation limitées. Vérifiez que la journalisation ne perturbe pas la temporisation des routines USS existantes.

Exportez les données après chaque événement. Enregistrez-les avec la date, l’état de la machine, le rapport du témoin et toutes les observations physiques. Une succession de plusieurs événements peut révéler une tendance qu’un seul événement ne permet pas de déceler.

Utilisez des compteurs de diagnostic qui répondent à des questions précises

Les compteurs ne sont utiles que si leur signification est claire. Un compteur général de commandes et un compteur général de retours peuvent diverger pour de nombreuses raisons normales.

Comptez chaque demande de mouvement de l’IHM acceptée. Comptez chaque commande de mouvement acceptée par l’arbitrage final de l’API. Comptez chaque transmission USS menée à bien. Comptez chaque réponse valide reçue du variateur d’axe.

Comptez également les dépassements de délai de communication, les événements indiquant que le variateur n’est pas prêt, les activations de fin de course, les changements de mode et les expirations de commande.

Enregistrez la dernière valeur de vitesse transmise et le dernier mot de commande. Enregistrez la dernière valeur réelle valide reçue et le dernier mot d’état. Ajoutez, lorsque cela est possible, un numéro de séquence à la structure de commande.

Lorsqu’un événement se produit, les compteurs peuvent répondre à plusieurs questions :

• L’IHM a-t-elle généré une demande ?
• L’API a-t-elle approuvé cette demande ?
• L’API a-t-elle transmis un nouveau télégramme ?
• Le variateur a-t-il renvoyé une réponse valide ?
• Le mouvement réel a-t-il commencé sans nouvelle commande approuvée ?

Un compteur ne devrait pas être réinitialisé automatiquement à chaque démarrage, sauf si sa valeur historique est inutile. Envisagez d’enregistrer un compteur d’événements dans une mémoire rémanente tout en forçant toutes les commandes de mouvement elles-mêmes à prendre une valeur de démarrage sûre.

La protection indépendante contre le dépassement de course ne peut pas dépendre de la logique normale

Les limites de position logicielles sont utiles, mais elles ne peuvent pas constituer l’unique protection contre un défaut pouvant provenir du programme de l’API, de la voie de communication ou du contrôleur normal du variateur.

Chaque axe doit disposer d’une protection de fin de course correctement conçue. Selon l’évaluation des risques de la machine, celle-ci peut comprendre des interrupteurs de fin de course câblés, des capteurs de position de sécurité, des relais de sécurité, des circuits d’inhibition du variateur, des contacteurs, des freins ou une autre architecture validée.

Une entrée d’API standard qui écrit une commande de vitesse nulle n’est pas automatiquement une fonction de sécurité. Le même défaut logique à l’origine du mouvement peut empêcher le traitement de cette commande d’arrêt.

La suppression de la consigne de vitesse ne garantit pas non plus la suppression du couple. Le variateur peut rester activé, une consigne secondaire peut rester active ou l’énergie mécanique emmagasinée peut continuer à déplacer la charge.

Testez indépendamment l’arrêt d’urgence, les interverrouillages des protecteurs, les interrupteurs de dépassement de course, les contacts de défaut du variateur, les freins et les contacteurs. Vérifiez qu’un redémarrage nécessite une action délibérée après le déclenchement de la protection.

Pendant les essais de diagnostic, réduisez autant que possible la vitesse maximale, l’accélération, le couple et la course disponible sur le plan technique. Des butées mécaniques temporaires ne doivent être utilisées que si elles sont conçues pour l’énergie d’impact possible.

Aucun objectif de diagnostic ne justifie d’exposer une personne à un axe ayant déjà démontré un mouvement incontrôlé.

Exemple de cas : un câble qui tombe en panne uniquement lors d’une inversion

Considérons une glissière qui se comporte normalement lors d’un test statique lent, mais qui se déplace violemment lors d’une inversion rapide du sens. Le journal de l’API montre une commande stable. La trace du variateur montre une perturbation soudaine de la vitesse mesurée, suivie d’une forte sortie corrective.

Un test de continuité du câble de l’encodeur est concluant lorsque la machine est à l’arrêt. Le câble passe toutefois dans une chaîne porte-câbles mobile. Un conducteur est fracturé près du rayon de courbure minimal et ne s’interrompt que lorsque la chaîne atteint une position particulière.

Une mesure à l’oscilloscope à l’entrée du variateur montre qu’un canal de l’encodeur s’effondre pendant l’inversion. La commande reste correcte et aucun défaut USS n’est enregistré.

Le câble est remplacé par le modèle approprié à flexion continue. La protection contre la traction et la terminaison du blindage sont rétablies. L’alimentation de l’encodeur et la qualité de la forme d’onde sont testées sur toute la course de la glissière.

La vérification finale comprend des inversions répétées à vitesse réduite, suivies d’un fonctionnement contrôlé à la vitesse normale de production. Une nouvelle forme d’onde saine est enregistrée comme référence.

Ce cas montre pourquoi un défaut de retour d’information doit être démontré dynamiquement. Un test statique de résistance peut être concluant même lorsque le câble tombe en panne en service.

Exemple de cas : une commande de marche par à-coups subsiste après une perte de communication avec l’IHM

Sur une autre machine, l’appui sur un bouton de marche par à-coups active un bit de l’API. Le relâchement du bouton le désactive. L’IHM perd la communication alors que le bouton est maintenu enfoncé ; la commande de relâchement n’atteint donc jamais l’API.

À ce moment-là, un autre interverrouillage empêche le mouvement. Le bit de marche par à-coups obsolète reste masqué. Plus tard, l’opérateur change le mode de la machine. La logique finale de l’API accepte alors l’ancienne demande de marche par à-coups, et la glissière se déplace de manière inattendue.

Le variateur suit une consigne légitime de l’API. La communication USS est opérationnelle lorsque le mouvement commence. Remplacer l’encodeur ou ajouter une autre connexion de blindage ne corrigera pas le problème.

La logique révisée de l’API exige une demande de marche par à-coups actualisée en continu. La commande expire après un court intervalle. Elle n’est acceptée que dans le mode approprié, avec une communication valide et la condition d’activation requise.

La logique de démarrage efface toutes les demandes de mouvement. L’action de relâchement de l’IHM reste présente, mais ce n’est plus le seul mécanisme qui supprime la commande.

L’enregistreur d’événements confirme que le bit brut de l’IHM est resté actif après la défaillance de communication précédente. La cause fondamentale n’était pas une corruption des communications, mais la gestion dangereuse d’une commande valide, mais obsolète.

Exemple de cas : le bruit révèle une mauvaise gestion du tampon USS

Une troisième machine subit des délais d’attente USS lorsque la broche accélère. Les télégrammes endommagés sont rejetés ; le réseau ne transforme donc pas directement une commande de vitesse en une autre.

L’application de l’API, cependant, n’invalide pas l’ancienne commande d’axe après une transaction manquée. La routine USS s’exécute également de manière conditionnelle, ce qui crée des intervalles d’interrogation irréguliers.

Lors d’une transition de séquence, la nouvelle commande nulle est écrite à un emplacement mémoire tandis que le tampon de transmission contient encore une ancienne valeur non nulle. Le télégramme suivant envoyé avec succès transmet des données valides, mais obsolètes.

Le variateur reçoit une commande correctement structurée et réagit normalement. La perturbation de la couche physique a révélé une faiblesse logicielle au lieu de générer directement la consigne.

L’action corrective améliore le cheminement des câbles et la mise à la masse du blindage. La routine de communication de l’API est ensuite reconçue afin que chaque variateur utilise une mémoire dédiée. La consigne finale validée est copiée dans le tampon de transmission immédiatement avant la transaction.

Une réponse manquée marque les données comme non valides. La réponse programmée à une perte de communication est vérifiée par des essais contrôlés.

Ce cas montre pourquoi le dépannage des communications doit couvrir à la fois la forme d’onde électrique et le cycle de vie des données applicatives.

Séquence pratique d’investigation sur site

Étape 1 : Sécurisez la machine. Mettez en place une protection indépendante contre la survitesse, réduisez l’énergie d’essai et limitez l’accès du personnel.

Étape 2 : Confirmez le matériel. Notez les références complètes, les versions logicielles, les cartes optionnelles, les dispositifs de retour et les modules d’interface.

Étape 3 : Créez des sauvegardes. Enregistrez le programme S7-200, le projet TP 170A, le jeu de paramètres MASTERDRIVES et les paramètres du MM440.

Étape 4 : Définissez l’événement. Notez la direction, la vitesse, la durée, le mode de fonctionnement, la position, l’état de la broche et le comportement à l’arrêt.

Étape 5 : Cartographiez la chaîne de commande. Identifiez chaque source de consigne, d’activation, de direction, de vitesse fixe, de marche par à-coups et de référence supplémentaire.

Étape 6 : Ajoutez une journalisation synchronisée. Enregistrez les commandes de l’API, les données USS, les valeurs internes du variateur, les retours, le courant, les limites, les avertissements et les défauts.

Étape 7 : Testez les états de démarrage. Examinez le démarrage à froid, le redémarrage à chaud, les transitions de l’état RUN du processeur, la reconnexion de l’IHM et le rétablissement des communications.

Étape 8 : Inspectez dynamiquement les retours. Testez la tension d’alimentation, la qualité de la forme d’onde, le couplage, les connecteurs, le blindage et la flexion des câbles.

Étape 9 : Auditez USS et RS-485. Vérifiez l’adressage, la topologie, la terminaison, les zones de données, la temporisation et la gestion des erreurs.

Étape 10 : Examinez les références croisées de l’automate. Trouvez chaque écriture vers la consigne finale, le sens de rotation et l’activation du variateur.

Étape 11 : Auditez le routage des signaux du variateur. Vérifiez chaque source de commande et chaque élément contribuant à la consigne active.

Étape 12 : Modifiez un seul élément à la fois. Consignez l’état initial, le nouvel état, la raison, le résultat du test et la méthode de retour en arrière.

Le renforcement à long terme doit s’attaquer à l’architecture

Après avoir trouvé la cause immédiate, demandez-vous pourquoi un seul défaut pouvait provoquer un mouvement dommageable. Un seul dépassement de délai de communication, une rupture de câble ou une erreur de l’IHM ne devrait pas contourner toutes les couches de protection.

Séparez la génération des commandes, leur validation, le transport des communications, la commande du variateur et la protection de sécurité. Chaque couche doit avoir une responsabilité définie.

L’automate doit générer une commande bornée et validée par l’état. La routine de communication doit transmettre des données actuelles avec une validité et une fraîcheur clairement définies. Le variateur doit appliquer les limites de fonctionnement configurées et la surveillance du retour d’information. Des fonctions de sécurité indépendantes doivent contrôler les mouvements dangereux.

Déterminez si l’architecture S7-200 et USS reste compatible avec les besoins de maintenance. La migration vers une plateforme d’automate et de variateur plus récente peut améliorer les diagnostics, l’horodatage, la disponibilité des composants, la visibilité du réseau et la gestion des sauvegardes.

Un réseau plus récent ne rend pas automatiquement une machine sûre. PROFINET à lui seul ne corrige ni une mauvaise arbitrage des commandes, ni une logique de démarrage défaillante, ni une protection insuffisante contre les dépassements de course.

La modernisation doit inclure l’IHM, les schémas, le contrôle des versions logicielles, l’architecture de sécurité, la stratégie de pièces de rechange et la formation du personnel. Remplacer uniquement l’automate programmable peut déplacer le problème vers une autre plateforme.

Pour les applications de positionnement exigeantes, évaluez si le profil de mouvement devrait être exécuté dans un variateur ou un contrôleur de mouvement dédié plutôt qu’au moyen de commandes de vitesse série répétées. La décision appropriée dépend de la précision de positionnement, de la synchronisation, du temps de cycle, de l’architecture de retour d’information et du risque machine.

La vérification ne consiste pas seulement à attendre le retour du défaut

Sept jours sans incident sont encourageants, mais cela ne prouve pas que la cause racine a été éliminée. La vérification doit reproduire délibérément les conditions qui avaient précédemment accru le risque.

Effectuez des cycles répétés sur toute la course à vitesse contrôlée. Incluez des inversions rapides, l’accélération de la broche, le freinage de la broche, des conditions d’armoire chaude, la charge normale maximale et le déplacement de la chaîne porte-câbles.

Répétez les tests de démarrage et de récupération. Cyclez l’alimentation de commande conformément à une procédure approuvée. Testez le passage ARRÊT-EXÉCUTION du CPU, la réinitialisation du variateur, la reconnexion de l’IHM, la perte d’un esclave USS et le rétablissement de la communication.

Vérifiez la réaction à une défaillance du retour d’information au moyen d’une méthode d’essai approuvée. Ne déconnectez pas un encodeur de production lorsque du personnel est exposé au mouvement.

Testez chaque fin de course matérielle, limite logicielle, entrée de défaut du variateur, arrêt d’urgence, frein et dispositif indépendant de dépassement de course. Confirmez la réponse d’arrêt requise et le comportement au redémarrage.

Comparez la commande finale de l’automate, la commande reçue par le variateur, la consigne interne active et le mouvement réel pendant chaque essai.

Définissez les critères d’acceptation avant les essais. Ces critères peuvent notamment inclure :

• Aucun mouvement intempestif lors d’une condition quelconque de démarrage ou de récupération.
• Aucune défaillance de communication USS non traitée.
• Aucune commande de mouvement conservée après une perte de communication avec l’IHM.
• Alimentation et forme d’onde du retour d’information stables sur toute la course.
• Fonctionnement correct de chaque dispositif indépendant de dépassement de course.
• Concordance enregistrée entre la commande, la consigne reçue, la consigne active et le mouvement réel.

Maintenez l’enregistreur d’événements en fonctionnement pendant les premières phases de production. Une action corrective réussie doit éliminer à la fois le symptôme physique et le schéma diagnostique anormal qui l’a provoqué.

La cause racine apparaîtra là où les signaux divergent pour la première fois

Une dérive intermittente du coulisseau dans un système Siemens S7-200 et MASTERDRIVES ne doit pas être attribuée au « bruit », à « l’encodeur » ou à « USS » sans preuves.

La méthode décisive consiste à corréler la commande finale de l’automate, la commande reçue par le variateur, la consigne interne active et la réaction mécanique réelle.

Si la commande de l’automate devient incorrecte, examinez l’IHM et la logique applicative. Si la valeur transmise ou reçue devient incorrecte, examinez la gestion de la mémoire, la mise à l’échelle, la construction des télégrammes et le réseau RS-485.

Si le variateur active une source de commande que l’automate n’avait pas prévue, vérifiez la configuration interne du variateur. Si toutes les commandes restent sûres alors que le moteur accélère, examinez le retour d’information, l’alimentation de la carte de commande, le matériel du variateur et la mécanique.

Les défauts de retour d’information restent plausibles, mais ils doivent être testés comme des circuits complets. Les problèmes USS restent plausibles, mais des données valides obsolètes et une logique de récupération défaillante sont souvent plus probables qu’un télégramme aléatoire endommagé devenant une commande de vitesse maximale valide.

La machine ne doit reprendre son service normal qu’après la mise en place effective d’une protection indépendante, l’étayage du mécanisme déclencheur par des preuves enregistrées et la vérification, au moyen d’essais contrôlés, de l’action corrective ainsi que de la réaction aux futurs défauts.

Cette approche disciplinée exige davantage de préparation qu’un remplacement spéculatif de composants. Elle produit également un résultat plus précieux : une machine dont la trajectoire de mouvement est comprise, enregistrée, documentée et protégée contre la prochaine défaillance unique.