Restrictions

Le projet de démarrage doit être chargeable et exécutable sur les deux contrôleurs. Une mise à jour fluide du système d'exécution avec différentes versions de ces systèmes d'exécution est rendue possible grâce à une fonctionnalité du CODESYS Redundancy Configuration module complémentaire.

Seules les tâches cycliques sont autorisées. Tâches de type Événement, État, ou Roue libre ne peut pas être synchronisé.

Exactement une tâche (la tâche de redondance) est synchronisée avec les fonctionnalités du CODESYS Redundancy Configuration module complémentaire. D'autres tâches et applications sont possibles, mais elles s'exécutent de manière non synchronisée sur les 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. La liaison de communication utilisée à cette fin doit être utilisée 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.

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.

La modification du nom de l'application redondante ou de la tâche redondante constitue une modification importante et n'est pas possible pendant mode redondant. Après une telle modification, les deux automates doivent être reconfigurés. Comme décrit dans Pour commencer section (sous « Configuration du système de redondance »).

La valeur du délai d'attente que vous spécifiez 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.

Dans le Configuration de redondance éditeur, sur le Paramètres de redondance onglet, sur le Général onglet, vous définissez le délai d'attente qui fait passer l'automate actif en mode autonome.

De plus, la valeur est stockée dans le fichier de configuration d'exécution (exemple : CODESYSControl.cfg) avec l'entrée StandbyWaitTime.

Des durées d'exécution différentes sur les deux API peuvent entraîner des « à-coups » (des valeurs de sortie qui s'écartent) lors du passage d'un API à l'autre. Pour éviter cela, les valeurs des temporisateurs IEC sont gelées pendant l'exécution d'une tâche IEC. Les appels provenant des temporisateurs IEC (par exemple : la fonction TON)lors de l'exécution d'une tâche IEC aboutissent donc toujours aux mêmes valeurs de temporisateur, même si le temps physique continue de s'écouler. Les implémentations doivent donc rester en attente (éventuellement dans une boucle). En effet, les valeurs des temporisateurs CEI ne changent pas pendant le cycle de balayage de la tâche en cours.

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">

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.

Pour plus d'informations, consultez les rubriques suivantes : Tâche et communication en temps réel

La méthode de mappage des E/S « Map on Existing » (mappage des E/S avec des variables existantes) n'est pas recommandée lors de l'utilisation du CODESYS Redundancy Configuration module complémentaire. 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.

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.

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 correspondants dans les zones de données qui ne sont pas soumises au contrôle de redondance. Chaque automate ouvre ses fichiers indépendamment les uns des autres. Un identifiant partagé n'est pas pris en charge. Un descripteur de fichier créé sur un automate doit pas être utilisé pour accéder aux fichiers de l'autre automate ou aux fichiers du PC local.

Lors de la compilation, le système vérifie qui gère les 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 poignée détectée dans une telle zone.

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.

CODESYS SoftMotion et CODESYS Redundancy Configuration ne peuvent pas être combinés. Les exigences de temps de SoftMotion ne peut pas être remplie lors de l'utilisation de la redondance.