IC693CPU367 vs IC693CPU350 : mise à niveau de la mémoire, corrections des temporisateurs TMR et guide de migration d’API
La mise à niveau d’un système de commande Series 90-30 de l’IC693CPU350 à l’IC693CPU367 augmente considérablement la mémoire. Cependant, les ingénieurs signalent souvent un comportement inattendu des temporisateurs TMR après un remplacement direct. Cet article en explique la véritable cause et propose des étapes pratiques de migration aux professionnels de l’automatisation industrielle.
Vitesse du processeur et mémoire : qu’est-ce qui change vraiment ?
Même vitesse d’horloge, classe de mémoire différente
Les IC693CPU350 et IC693CPU367 utilisent tous deux un processeur 80386EX de 25 MHz. Le CPU350 offre 32 Ko de mémoire utilisateur fixe. En revanche, le CPU367 appartient à la classe de mémoire de 240 Ko de la famille GE Fanuc Series 90-30. Le CPU367 offre donc 7,5 fois plus de mémoire pour la logique utilisateur. De plus, les deux unités ont la même vitesse d’exécution booléenne de 0,22 ms/K. Le principal avantage de la mise à niveau réside donc dans la capacité mémoire, et non dans la fréquence d’horloge brute.
Comparaison de la consommation électrique sur le fond de panier
Le CPU367 consomme 940 mA sous 5 VCC, tandis que le CPU350 consomme 670 mA. Cette différence de 270 mA est importante dans les racks d’automatisation industrielle dont le budget électrique est limité. Les ingénieurs doivent vérifier la marge disponible de l’alimentation avant de mettre le système sous tension. Il faut également toujours examiner la charge du fond de panier due à tous les modules installés.
Pourquoi les temporisateurs TMR semblent plus rapides après leur remplacement
Explication de l’anomalie de temporisation TMR
L’instruction TMR des Series 90-30 repose sur une base de temps de 0,01 s, 0,1 s ou 1,0 s. Cette base est stockée dans un bloc de trois mots du registre %R. Le CPU367 exécute les cycles logiques à la même vitesse nominale que le CPU350. Toutefois, la précision apparemment « supérieure » des temporisateurs provient rarement de l’horloge du processeur. Le problème découle généralement d’incompatibilités dans la configuration de la mémoire %R ou de différences de résolution des temporisateurs au niveau du micrologiciel.
Réallocation de la mémoire et mappage des registres de temporisateur
Le CPU350 fournit un espace mémoire fixe de 32 Ko avec une limite de 9 999 mots pour %R. Le CPU367 porte la mémoire des registres à 240 Ko, ce qui nécessite un profil de configuration matérielle différent. Si le programme d’origine a été migré sans mettre à jour le paramètre de taille de %R, les valeurs prédéfinies des temporisateurs peuvent être mal interprétées. Par exemple, une valeur prédéfinie de 1000 prévue pour 10,0 secondes (base de 0,01 s) pourrait s’exécuter en 100 secondes si la base de temps passait silencieusement à 0,1 s. De plus, l’accumulateur TMR continue de compter jusqu’à 32767 sur les CPU 90-30. Ainsi, une base de temps mal configurée entraîne une erreur de temporisation proportionnelle, et non une véritable augmentation de vitesse.
Mesures correctives pratiques en cas de dérive des TMR
Étape 1 : vérifiez l’allocation de mémoire %R
Les ingénieurs devraient d’abord vérifier l’allocation de mémoire %R dans la configuration matérielle. Le CPU367 prend en charge jusqu’à 240 Ko de mémoire utilisateur pour la logique. Toutefois, le nombre de mots %R doit être explicitement défini sur au moins 9 999 afin de correspondre à l’environnement hérité du CPU350. De plus, consignez ce paramètre pour les futurs audits de maintenance.
Étape 2 : vérifiez chaque valeur préréglée et chaque base de temps des TMR
Vérifiez la valeur préréglée de chaque instruction TMR et confirmez la base de temps prévue. Une procédure de migration rigoureuse évite les erreurs silencieuses de mise à l’échelle. En outre, comparez le programme à la logique d’origine du CPU350 afin de repérer toute constante incompatible.
Étape 3 : vérifiez la révision du micrologiciel du CPU367
Vérifiez la révision du micrologiciel du CPU367 avant la mise en service. Les unités livrées avec la version 10.72 ou une version ultérieure présentent un comportement cohérent des temporisateurs. Par conséquent, la vérification du micrologiciel devrait figurer sur chaque liste de contrôle de migration d’API dans le domaine de l’ingénierie des systèmes de commande.
Étape 4 : envisagez de migrer vers les instructions ONDTR
Si l’application exige une temporisation plus précise que ne le permettait la conception d’origine, envisagez de migrer les instances TMR critiques vers l’instruction ONDTR. L’instruction ONDTR offre un comportement rémanent et un contrôle explicite de la réinitialisation. Elle réduit ainsi les ambiguïtés lors des transitions entre CPU et améliore la fiabilité à long terme.
Résumé des données et recommandation de migration
Comparaison des principaux paramètres
Processeur : les deux unités utilisent un 80386EX à 25 MHz. Mémoire utilisateur : 32 Ko fixes contre 240 Ko. Vitesse de scrutation booléenne : 0,22 ms/K pour les deux. Capacité des registres %R : 9 999 mots contre une capacité configurable jusqu’à 240 Ko. Courant du fond de panier : 670 mA contre 940 mA à 5 V CC. De plus, l’extension de mémoire à elle seule justifie la mise à niveau pour les applications dont les besoins en registres augmentent. Néanmoins, l’écart de temporisation du TMR est dû à un artefact de configuration, et non à un défaut matériel.
Point de vue de l’auteur : une approche de migration maîtrisée
D’un point de vue pratique, la mise à niveau vers le CPU367 concerne la mémoire, pas la vitesse. D’après mon expérience, la plupart des plaintes concernant la « dérive des temporisateurs » sont dues à des paramètres %R qui n’ont pas été validés. Une procédure de migration rigoureuse, qui consiste à valider les paramètres mémoire et les préréglages des temporisateurs avant l’exécution, élimine complètement le décalage de précision observé. En outre, les équipes devraient vérifier systématiquement la révision du micrologiciel dans le cadre de toute migration d’API pour des projets d’automatisation industrielle.
Cas d’application et scénario de solution
Augmentation du nombre de registres dans une station de traitement de l’eau
Une station de traitement de l’eau avait besoin de davantage de registres pour l’enregistrement des tendances et l’historique des alarmes. L’équipe a remplacé le CPU350 par le CPU367 et augmenté la capacité %R à 240 Ko. Cependant, les opérateurs ont d’abord signalé un comportement plus rapide des temporisateurs TMR. Un audit de la configuration a révélé que la taille %R n’avait pas été mise à jour. Après avoir défini le nombre de mots %R à 9 999 et confirmé la version 10.72 du micrologiciel, le comportement des temporisateurs a correspondu à la conception d’origine. L’usine a ainsi bénéficié d’une capacité mémoire accrue sans risque de décalage temporel.
Liste de vérification recommandée pour la migration des systèmes de commande
Tout d’abord, vérifiez le budget de l’alimentation pour tenir compte de la consommation supplémentaire de 270 mA. Ensuite, définissez le nombre de mots %R pour qu’il corresponde à l’ancien environnement. Vérifiez ensuite chaque valeur préréglée et chaque base de temps TMR. Confirmez également que le micrologiciel est en version 10.72 ou ultérieure. Enfin, envisagez ONDTR pour les temporisateurs critiques. Cette liste de vérification facilite les transitions fiables des systèmes PLC et DCS dans les projets d’automatisation industrielle.
Foire aux questions
Le IC693CPU367 est-il plus rapide que le IC693CPU350 ?
Non. Les deux processeurs utilisent un processeur 80386EX de 25 MHz et ont un temps de balayage booléen de 0,22 ms/K. La véritable amélioration concerne la capacité mémoire, qui passe de 32 Ko à 240 Ko.
Pourquoi les temporisateurs TMR semblent-ils plus rapides après le remplacement par un CPU367 ?
La cause est généralement une configuration de mémoire %R inadéquate ou un décalage silencieux de la base de temps. Une valeur préréglée de 1000, correspondant à 10,0 secondes, peut entraîner une exécution de 100 secondes si la base passe de 0,01 s à 0,1 s.
Quel nombre de mots %R dois-je définir sur le CPU367 ?
Définissez le nombre de mots %R à au moins 9 999 pour correspondre à l’environnement de l’ancien CPU350. Cette étape évite une mauvaise interprétation des valeurs préréglées des temporisateurs après la migration.
Quelle révision du micrologiciel corrige le comportement des temporisateurs sur le CPU367 ?
Les unités livrées avec le micrologiciel 10.72 ou ultérieur présentent un comportement cohérent des temporisateurs. Vérifiez toujours la révision avant la mise en service d’un rack migré.
Dois-je remplacer les instructions TMR par des instructions ONDTR ?
Pour les temporisateurs critiques nécessitant un comportement rémanent et une commande de réinitialisation explicite, envisagez ONDTR. Cela réduit les ambiguïtés lors des transitions du processeur dans les systèmes Series 90-30.
Coordonnées
Demandes : sales@nex-auto.com | +86 153 9242 9628
Partenaire NexAuto Technology Limited : https://www.nex-auto.com/
Consultez ci-dessous les produits populaires pour en savoir plus sur AutoNex Controls
