Restrictions
CODESYS version
Le projet de démarrage doit pouvoir être chargé sur les deux contrôleurs. La mise à jour fluide du système d'exécution pour les différentes versions d'exécution des contrôleurs est rendue possible au moyen d'un CODESYS Redundancy fonctionnalité.
Tâche et communication en temps réel
Seules les tâches cycliques sont autorisées. Tâches de type Événement, État, ou Roue libre ne peut pas être synchronisé.
Le CODESYS Redundancy la fonctionnalité synchronise exactement une tâche (Tâche de redondance). D'autres tâches et applications sont possibles, mais elles s'exécutent de manière non synchronisée sur les deux automates.
De plus, le système de redondance qui affecte l'exécution des tâches et la communication doit répondre à certaines exigences en temps réel : l'exécution des messages (demande et réponse) de la communication de redondance doit exister dans un intervalle de temps préalablement défini et la gigue de la tâche doit être prise en compte. Le lien utilisé à cette fin doit être utilisé exclusivement pour les communications redondantes.
L'exécution de tâche en temps réel signifie que la tâche d'application qui est contrôlée par la redondance a une gigue limitée. La communication en temps réel signifie qu'un message envoyé au moyen de la liaison de redondance doit être reçu par l'autre automate dans un délai spécifique.
Temps d'exécution de la tâche
La durée de la messagerie (temps de requête et de réponse) augmente le temps d'exécution de la tâche : le temps total d'exécution de la tâche est plus long lorsque la redondance est utilisée.
Modification des noms de l'application et de la tâche
La modification des noms de l'application redondante ou de la tâche redondante est une modification importante et n'est pas possible pendant le fonctionnement redondant. En effet, après une modification, vous devez reconfigurer les deux automates comme décrit dans "Mise en route" sous "Configuration du système de redondance".
Valeur du délai d'attente
La valeur que vous spécifiez pour le délai d'attente doit être supérieure à la somme du temps d'instabilité de la tâche et du temps d'instabilité maximal des communications.
Les deux horaires sont spécifiques au système. Les deux fonctionnalités (tâches en temps réel et communication en temps réel) sont nécessaires pour spécifier un délai maximum spécifique. Lors de l'exécution, lorsque l'instabilité de la tâche est élevée et que le transfert des messages est retardé, un délai d'attente se produit. En attendant un message de l'autre automate, le système suppose que l'autre automate ne fonctionne plus. Par conséquent, l'automate en attente et l'automate émetteur passent en mode autonome. Cela entraîne des pertes de synchronisation et des problèmes de communication sur le bus de terrain
Astuce
Vous définissez le délai d'attente lorsque l'automate actif passe en mode autonome dans Configuration de redondance éditeur, sur le Général onglet du Paramètres de redondance onglet. De plus, la valeur est stockée dans le fichier de configuration d'exécution (exemple : CODESYSControl.cfg) avec l'entrée StandbyWaitTime.
Important
Dans certains cas, il peut arriver que les deux contrôleurs redondants passent inopinément en mode simulation.
Cause : Lorsque l'exécution de la tâche de redondance sur le contrôleur actif est interrompue ou significativement retardée, le message de synchronisation peut ne pas arriver sur le contrôleur de secours avant l'expiration du délai.
Le comportement qui en résulte dépend de AutoSyncEnable drapeau :
Si
AutoSyncEnable = 0, puis le second contrôleur passe en mode autonome.Si
AutoSyncEnabled = 1, puis le second contrôleur passe initialement en mode autonome. Une fois que ce contrôleur a reçu le message différé, il passe en mode simulation, suivi d'une nouvelle tentative de connexion.
Solution :
Pour éviter ce problème, une priorité élevée doit être attribuée à la tâche de redondance afin de minimiser le risque d'interruptions ou de retards.
Alternative : activez la tâche de surveillance avec une valeur de délai inférieure au délai de redondance.
Alternative : Synchronisez les contrôleurs manuellement.
Minuterie CEI
Des temps d'exécution différents sur les deux automates peuvent provoquer des "bosses" (valeurs de sortie divergentes) lors du changement d'automate. Pour éviter cela, les valeurs des temporisateurs CEI sont gelées pendant l'exécution d'une tâche CEI. Appels des temporisateurs IEC (exemple : la fonction TON) lors de l'exécution d'une tâche CEI conduisent donc toujours aux mêmes valeurs de temporisation, même si le temps physique continue de s'écouler. Par conséquent, les implémentations doivent attendre de manière inactive (éventuellement dans une boucle). Cela est dû au fait que les valeurs de minuterie CEI ne changent pas dans l'analyse de tâche en cours.
Pointeurs, références et interfaces
Le POINTER TO, REFERENCE TO, et INTERFACE les instructions (et les instances d'interface) permettant d'exprimer les relations entre les unités d'application ne fonctionnent pas avec les applications redondantes synchronisées.
POINTER les variables ne doivent pas être déclarées dans des zones de données contrôlées par redondance. En effet, des données contrôlées de manière redondante sont transmises à l'autre API lors de la synchronisation. Cependant, les pointeurs ne sont pas valides sur l'autre automate car une autre configuration mémoire peut s'y trouver.
Lors de la compilation, la fonctionnalité de redondance vérifie qu'un pointeur se trouve dans une zone contrôlée de manière redondante. Un avertissement s'affiche pour chaque pointeur qui s'y trouve. Le contrôle peut être désactivé dans le fichier de description de l'appareil avec l'entrée suivante :
<Device>
<Custom>
<Redundancy DisablePointerChecks="true">EtherCAT DC
Cette extension de redondance est davantage destinée à l'industrie de process qu'à l'automatisation industrielle. Pour cette raison, les variateurs EtherCAT avec horloges distribuées ne sont pas pris en charge. Cependant, les E/S EtherCAT sont prises en charge.
Voir également la section "Tâche et communication en temps réel" ci-dessus.
"Mapper sur existant": mappage sur des variables existantes
Il n'est pas recommandé d'utiliser la méthode de mappage d'E/S « Map on Existing » (mappage d'E/S avec des variables existantes) avec CODESYS Redundancy. Ces types de variables ne sont pas stockés dans les zones de données d'entrée ou de sortie, mais là où ils sont déclarés. Par conséquent, ils ne sont pas synchronisés pendant le fonctionnement.
Variables réseau
Les variables réseau avec accès en écriture ne doivent pas être utilisées car plusieurs télégrammes d'écriture sont envoyés en même temps. Les variables réseau avec accès en lecture sont autorisées.
Accès aux fichiers
L'accès aux fichiers ne doit pas être utilisé car des données de fichier différentes peuvent provoquer des "chocs" sur les différents automates lors de leur commutation.
Si vous utilisez des fichiers, vous devez déclarer les descripteurs de fichiers dans les zones de données qui ne sont pas soumises au contrôle de redondance. Les fichiers doivent être ouverts séparément sur les deux automates. Le descripteur de fichier d'un autre automate ne doit pas être utilisé pour accéder aux fichiers sur le PC local.
Lors de la compilation, CODESYS Redundancy vérifications qui gèrent des variables (RTS_IEC_HANDLE, CAA.HANDLE) sont situés dans une zone contrôlée de manière redondante. Un avertissement est émis pour chaque variable de descripteur détecté dans une telle zone.
Gestion des utilisateurs de la sécurité en ligne
Si une gestion des utilisateurs de sécurité en ligne est utilisée, vous devez configurer les deux automates avec le même nom d'utilisateur et le même mot de passe. Sinon, les services en ligne tels que write variable ou online change ne sont pas transmis à l'automate de secours.
SoftMotion
CODESYS SoftMotion et CODESYS Redundancy ne peuvent pas être combinés. Les exigences de temps de SoftMotion ne peut pas être remplie lors de l'utilisation de la redondance.