Pourquoi RSLogix 500 ralentit pendant la modification en ligne

La modification en ligne lente dans RSLogix 500 est souvent imputée à un processeur SLC vieillissant, mais le délai visible peut provenir de plusieurs endroits : la station de travail d’ingénierie, les communications RSLinx, un réseau routé ou parasité, une incohérence du fichier de projet, la mémoire disponible du contrôleur ou le travail requis par le processeur pour maintenir une modification en ligne. Remplacer le matériel avant d’avoir isolé ces différents niveaux peut laisser le véritable défaut intact.

Mesurez l’origine du délai — mise à jour de l’écran, exploration, chargement, vérification, acceptation, test ou assemblage — avant de modifier le contrôleur ou le réseau.

Définir précisément le symptôme

« En ligne lent » peut désigner des problèmes très différents. Notez si le délai apparaît lors de l’ouverture d’une table de données, du défilement de la logique à relais, de la recherche dans le projet, de la modification d’un échelon, de la vérification de la syntaxe, de l’acceptation d’une modification, du test des modifications, de l’assemblage des modifications ou de l’enregistrement du fichier. Indiquez si le processeur reste réactif et si le temps de scrutation de la production, les erreurs de communication ou les mises à jour de l’IHM changent au même moment.

Chronométrez plusieurs actions répétables au lieu de vous fier à une impression. Comparez la navigation hors ligne et en ligne dans le même projet. Comparez la lecture d’une simple table de données avec un chargement. Si le projet hors ligne est déjà lent, la station de travail ou la base de données du projet mérite d’être examinée avant le contrôleur.

Établir une référence sûre

Chargez et sauvegardez le programme en fonctionnement, puis comparez-le avec le fichier source prévu. Notez la référence du processeur, sa série, son micrologiciel, la taille de sa mémoire, son mode de fonctionnement, la version de RSLogix 500, la version de RSLinx, le pilote de communication, le chemin, le système d’exploitation de la station de travail, ainsi que les ressources libres du disque et de la mémoire. Maintenez la machine dans un état permettant d’annuler une modification en toute sécurité.

Le manuel d’utilisation du matériel modulaire SLC 500 de Rockwell Automation constitue la référence matérielle principale pour les configurations prises en charge des processeurs et des communications. Le manuel de référence du jeu d’instructions SLC 500 décrit le comportement des instructions, les fichiers de données, les informations d’état et les défauts arithmétiques susceptibles de devenir pertinents lorsqu’une modification proposée change l’exécution ou l’utilisation de la mémoire.

Différencier le délai de la station de travail de celui des communications

Fermez les applications sans rapport, désactivez les compléments de projet inutiles et observez le processeur, la pression sur la mémoire, l’activité du disque et la réactivité de l’affichage pendant la reproduction du délai. De grandes bases de données de références croisées, de nombreuses tables de données ouvertes, l’animation de l’état de la logique à relais, l’analyse antivirus, les graphiques d’un bureau à distance et un disque système presque plein peuvent ralentir l’éditeur sans modifier le temps de scrutation du contrôleur.

Appliquez la politique de maintenance approuvée avant de modifier le logiciel de sécurité. Toute exclusion de diagnostic ou tout test temporaire hors ligne doit être contrôlé et annulé ensuite. N’affaiblissez pas durablement la protection du terminal simplement pour rendre un ancien outil plus réactif.

Testez ensuite les communications. Observez les diagnostics du pilote RSLinx et comparez un chemin local direct avec le chemin normalement routé lorsqu’une autre solution sûre et prise en charge est disponible. Vérifiez les nouvelles tentatives répétées, l’instabilité de la visibilité des nœuds, les adresses en double, les erreurs de duplex ou de commutateur sur Ethernet, ainsi que les défauts de couche physique sur les réseaux série, DH-485 ou DH+. Une exploration qui finit par réussir ne prouve pas que le chemin de programmation est sain.

Vérifier la cohérence du projet et de la session

Une session en ligne est plus sûre lorsque le fichier ouvert est connu comme correspondant au contrôleur en fonctionnement. Si le logiciel doit mettre en correspondance un projet obsolète ou structurellement différent avec le contrôleur, la navigation et la vérification peuvent devenir confuses même lorsque la connexion est stable. Chargez le programme dans une copie contrôlée, comparez les fichiers et résolvez les différences inexpliquées avant de modifier la logique de production.

Annulez les zones de modification abandonnées et vérifiez qu’aucune autre station de travail ne possède une session de modification. Notez les forçages, les modifications en ligne et la logique de maintenance temporaire déjà présents. Plusieurs changements non résolus augmentent le risque et rendent plus difficile de déterminer si un délai appartient à la nouvelle modification ou à l’état existant.

Comprendre le coût côté contrôleur

La modification en ligne n’est pas identique au remplacement hors ligne d’un fichier. Le contrôleur et le logiciel doivent conserver la logique d’origine et la logique modifiée pendant la séquence de modification, jusqu’à l’assemblage ou l’annulation du changement. La mémoire disponible et les capacités du processeur sont donc importantes. Un contrôleur proche de sa limite mémoire peut disposer de moins d’espace pour les structures temporaires nécessaires à une modification substantielle.

Commencez par une modification de diagnostic de petite taille. Ne combinez pas une modification de logique avec de nouveaux fichiers de données, des tables de données agrandies, des changements de communication et un nettoyage de la documentation. Certaines modifications structurelles nécessitent une modification hors ligne et un téléchargement plutôt qu’une solution en ligne. Si un changement ne peut pas être exprimé dans les limites prises en charge par la plateforme pour les modifications en ligne, planifiez l’arrêt approprié.

Surveillez le temps de scrutation du processeur et le temps de scrutation maximal, l’état des communications, les indicateurs de défauts majeurs et mineurs, ainsi que la temporisation du processus avant, pendant et après la modification. Une réponse rapide de l’éditeur ne justifie pas une modification qui introduit une variation excessive du temps de scrutation ou qui modifie une séquence critique en matière de temps.

Utiliser une séquence de modification contrôlée

Commencez par créer le plus petit changement permettant de valider le chemin de modification sans affecter l’équipement. Vérifiez-le, acceptez-le et observez le contrôleur et l’application conformément à la procédure du site. Ne testez la modification que lorsque le processus se trouve dans l’état sûr défini. Confirmez la logique prévue et toutes les sorties affectées avant de l’assembler.

Après l’assemblage, comparez ou chargez de nouveau le programme, puis enregistrez le fichier source résultant avec un horodatage, le motif du changement, son approbateur et une référence de restauration. Si les performances se dégradent à une étape précise, arrêtez-vous et préservez ces éléments probants. Accepter à répétition des modifications de plus en plus importantes n’est pas une méthode valable pour diagnostiquer un délai inconnu.

Interpréter les schémas courants

Si le défilement et les recherches hors ligne sont lents alors que les mises à jour des données du contrôleur sont normales, concentrez-vous sur la station de travail et la base de données du projet. Si toutes les lectures en ligne s’interrompent et que les nouvelles tentatives du pilote augmentent, concentrez-vous sur le chemin de communication. Si les petites modifications fonctionnent mais que les modifications plus importantes échouent ou restent bloquées, examinez la mémoire, la structure du projet et les limites des modifications prises en charge. Si l’éditeur reste réactif mais que le temps de scrutation du processus augmente, étudiez la modification de logique elle-même.

Si le ralentissement n’apparaît qu’après plusieurs heures, redémarrez la session d’ingénierie de manière contrôlée et vérifiez l’augmentation de la consommation des ressources au lieu de redémarrer le contrôleur. Si une autre station de travail fonctionne normalement sur le même chemin réseau, comparez les versions logicielles, les pilotes, les contrôles de sécurité et les fichiers de projet avant de déclarer l’automate programmable défectueux.

Décider quand cesser les modifications en ligne

Arrêtez-vous lorsque le projet en fonctionnement ne peut pas être identifié avec certitude, que les communications sont instables, que le contrôleur est proche d’une limite de ressources, que la modification nécessite des changements structurels ou que le processus ne peut pas tolérer le test. Planifiez une vérification hors ligne et un téléchargement contrôlé avec des sauvegardes et une procédure de restauration plutôt que de forcer une réparation en fonctionnement.

Les plateformes existantes et les options de migration peuvent être examinées dans la collection Allen-Bradley et la collection des systèmes PLC et PAC. La migration doit s’appuyer sur des éléments probants concernant les risques liés au cycle de vie, les performances, les pièces de rechange et la récupération — et non sur une seule session de modification lente.

Point de vue de l’ingénierie

La question utile n’est pas « Pourquoi RSLogix est-il lent ? », mais « Quelle limite devient lente, lors de quelle action répétable, et quelles données probantes évoluent avec elle ? » Une fois les effets de la station de travail, des communications, du projet, du contrôleur et du processus mesurés séparément, l’équipe peut corriger la véritable contrainte tout en protégeant la machine en fonctionnement.