Balises produites et consommées par Engineering Logix

Les tags produits et consommés permettent aux contrôleurs Logix d’échanger des données au niveau du contrôleur sans instructions de message. Le producteur rend un tag disponible ; un ou plusieurs consommateurs configurés le reçoivent selon un intervalle de paquets demandé. Le mécanisme est simple, mais une mise en œuvre stable dépend de la correspondance des définitions de données, des chemins réseau, des budgets de connexions et de la gestion des défaillances.

Choisissez le modèle adapté à la tâche

Utilisez des tags produits et consommés lorsque des contrôleurs homologues ont besoin de données cycliques avec un taux de mise à jour défini. Les exemples courants incluent la coordination de l’état des machines, les autorisations de ligne, les quantités produites et l’état partagé. La connexion est configurée plutôt que déclenchée par la logique Ladder ; cette méthode convient donc aux données qui doivent être actualisées en continu.

Ne considérez pas cette méthode comme un substitut à tous les échanges entre contrôleurs. Les messages explicites peuvent être plus adaptés aux lectures ou écritures occasionnelles. Une IHM, un historien ou un broker peut être préférable pour les données de supervision. Les données de sécurité suivent des règles distinctes concernant le contrôleur, le firmware et la configuration. Commencez par définir les informations nécessaires, la vitesse à laquelle elles doivent parvenir et ce que la machine réceptrice doit faire lorsqu’elles cessent d’arriver.

Définissez un contrat de données stable

Les tags produits et consommés doivent utiliser des types de données correspondants, y compris les dimensions des tableaux. Un type de données défini par l’utilisateur est généralement plus facile à gérer qu’un ensemble disparate de valeurs individuelles. Regroupez les données de processus, une révision du schéma, le mode de fonctionnement et les indicateurs d’état dans une seule structure. Réservez des membres supplémentaires lorsqu’une extension future est probable, mais gardez le paquet ciblé.

Documentez la signification, les unités et la plage valide de chaque membre. Une valeur numérique n’est pas explicite : elle peut représenter des unités d’ingénierie, des comptes bruts ou un pourcentage mis à l’échelle. Définissez quel contrôleur est propriétaire de chaque commande et de chaque état. Deux contrôleurs ne doivent pas écrire indépendamment des versions concurrentes du même état de machine.

Configurez le producteur

Créez le tag source au niveau du contrôleur et définissez son utilisation comme produite. Configurez le nombre de consommateurs prévus avec une marge raisonnable pour la conception. Rockwell Automation indique qu’un tag produit peut servir plusieurs consommateurs, tandis que les limites exactes du contrôleur et du réseau dépendent du matériel et du firmware.

Mettez à jour l’ensemble de la structure de manière cohérente. Si des routines logiques distinctes écrivent les membres individuels à des moments différents, un consommateur peut observer un état incohérent. Construisez la structure sortante dans une seule routine ou copiez une structure de travail terminée dans le tag produit une fois les calculs achevés.

Configurez chaque consommateur

Ajoutez le contrôleur producteur à la configuration d’E/S du consommateur via le chemin réseau effectivement pris en charge. Créez ensuite un tag de contrôleur consommé avec le même type de données. Saisissez exactement le nom du producteur et celui du tag distant. Le chemin configuré, l’identité du contrôleur et l’orthographe du tag font tous partie de la connexion.

Sélectionnez l’intervalle de paquets demandé en fonction des exigences du processus, et non de la valeur la plus rapide autorisée par la boîte de dialogue. Un RPI court consomme des ressources réseau et contrôleur. Un RPI lent peut retarder les interverrouillages ou la coordination de ligne. Prenez en compte le temps de mise à jour du réseau, l’exécution des tâches et le temps de réponse de l’application pour calculer l’ancienneté maximale acceptable des données.

Concevez la gestion des pertes de connexion

Des données qui cessent d’être mises à jour peuvent malgré tout sembler plausibles. Un consommateur doit distinguer les informations actuelles des informations conservées. La documentation de Rockwell prend en charge un membre CONNECTION_STATUS au début d’une structure définie par l’utilisateur pour surveiller les connexions produites et consommées. Un battement de cœur ou un compteur de séquence au niveau de l’application peut fournir une indication supplémentaire que la logique du producteur s’exécute et que la charge utile évolue comme prévu.

Définissez la réaction aux données obsolètes pour chaque cas d’utilisation. Une valeur affichée peut indiquer « communication perdue ». Un compteur de production peut être conservé avec un indicateur de qualité. Une autorisation de mouvement peut devoir être supprimée et nécessiter un redémarrage contrôlé. Ne forcez pas automatiquement une commande partagée à zéro, sauf si zéro constitue la réponse sûre et opérationnellement correcte définie.

Mettez méthodiquement en service la méthode d’échange

Vérifiez le réseau physique et les chemins des contrôleurs avant de dépanner les tags. Confirmez que chaque contrôleur est en ligne, accessible et représenté correctement dans l’arborescence d’E/S. Téléchargez les configurations du producteur et du consommateur selon une séquence contrôlée. Surveillez l’état de la connexion avant de tester le comportement de l’application.

Modifiez une valeur de test sur le producteur et suivez-la dans la structure du consommateur. Testez chaque membre qui influence le fonctionnement, y compris les valeurs signées, les tableaux et les bits de mode. Mesurez le temps de mise à jour observé par rapport à la cible de conception. Déconnectez ensuite le producteur ou le réseau dans une condition de test approuvée et confirmez l’alarme de données obsolètes ainsi que la réaction de la machine.

Dépannez les défauts courants

Une connexion qui ne s’établit jamais indique généralement un chemin, un nom de contrôleur, un nom de tag distant, un type de données ou une limite de capacité incorrect. Une connexion qui s’interrompt par intermittence peut être liée à une charge réseau, à une instabilité de la liaison, à une pression sur les ressources du contrôleur ou à un RPI trop agressif. Une connexion saine avec des valeurs incorrectes indique généralement un problème de contrat de données ou de logique applicative.

Comparez les deux projets côte à côte. Vérifiez la définition de la structure, la taille du tableau et la révision. Examinez les diagnostics du contrôleur et les compteurs du commutateur administrable avant de modifier les RPI au hasard. Si une structure produite change, considérez cela comme une révision d’interface et coordonnez la mise à jour avec chaque consommateur.

Gérez l’interface comme une infrastructure de l’usine

Archivez les deux projets de contrôleur et tenez un registre d’interface indiquant le producteur, les consommateurs, les noms de tags, les types de données, les RPI et les actions en cas de défaillance. Intégrez l’échange aux sauvegardes ainsi qu’aux revues des modifications de firmware et de réseau. Lorsqu’un contrôleur est remplacé, vérifiez le chemin de communication et l’état de la connexion avant d’activer les commandes de la machine.

Le matériel associé est disponible dans les collections Allen-Bradley ControlLogix et Communication et mise en réseau. Les détails de configuration et les limites de la plateforme doivent être vérifiés dans le manuel de programmation des tags produits et consommés de Rockwell Automation. Un contrat de données bien défini et une réponse explicite aux données obsolètes rendent la connexion maintenable longtemps après la mise en service.