Einschränkungen

CODESYS -Version

Auf beiden Geräten muss die gleiche Version des Laufzeitsystems installiert sein, denn das Bootprojekt wird zwischen den Steuerungen übertragen und muss deshalb auf der 2. Steuerung ladbar sein.

Task und Kommunikation in Echtzeit

Nur zyklische Tasks sind erlaubt. Tasks vom Typ Ereignis, Status oder Freilaufend können nicht synchronisiert werden.

Die CODESYS Redundancy -Funktionalität synchronisiert genau eine Task (Redundanztask). Weitere Tasks und Applikationen sind möglich, laufen jedoch unsynchronisiert auf beiden SPSen.

Außerdem muss das Redundanzsystem, was die Taskausführung und die Kommunikation betrifft, gewisse Echtzeitanforderungen erfüllen: Die Laufzeit der Nachrichten (Anfrage und Antwort) der Redundanzkommunikation muss innerhalb eines vorher fest definierten Zeitintervalls vorliegen und der Task-Jitter muss berücksichtigt werden.

Echtzeit-Taskausführung bedeutet, dass die Applikationstask, die durch Redundanz gesteuert wird, einen begrenzten Jitter hat. Echtzeitkommunikation bedeutet, dass eine über die Redundanzverbindung gesendete Nachricht von der anderen SPS innerhalb einer bestimmten Zeit empfangen werden muss.

Task-Ausführungszeit

Die Nachrichtenlaufzeit (Zeit für Anfrage und Antwort) erhöht die Ausführungszeit der Task: Bei Verwendung von Redundanz wird die Gesamtausführungszeit der Task länger.

Ändern von Applikations- und Tasknamen

Das Ändern des Namens der redundanten Applikation oder der redundanten Task ist eine wesentliche Änderung und ist während des redundanten Betriebs nicht möglich. Denn nach einer Änderung müssen Sie beide SPSen neu konfigurieren, so wie in „Erste Schritte“ unter „Redundanzsystem konfigurieren“ beschrieben.

Wert für Zeitüberschreitung

Der Wert, den Sie für die Zeitüberschreitung angeben, muss höher sein als die Summe aus Task-Jitter-Zeit und maximaler Kommunikations-Jitter-Zeit. Beide Zeiten sind systemspezifisch. Wenn zur Laufzeit der Task-Jitter hoch ist und die Nachrichtenübertragung sich verzögert, tritt eine Zeitüberschreitung ein. Beim Warten auf eine Nachricht von der anderen SPS wird dann angenommen, dass die andere SPS nicht mehr läuft. Daraufhin schalten sowohl die wartende SPS als auch die sendende SPS jeweils in den Standalone-Betrieb. Das führt zu Synchronisierungsverlusten und zu Kommunikationsproblemen auf dem Feldbus.

IEC-Timer

Unterschiedliche Taskausführungszeiten auf den beiden SPSen können „Bumps“ (voneinander abweichende Werte der Ausgänge) beim Umschalten verursachen. Um das zu vermeiden, werden die IEC-Timerwerte während der Ausführung einer IEC-Task eingefroren. Aufrufe von IEC-Zeitgebern (beispielsweise von der Funktion TON) während der Ausführung einer IEC-Task führen deshalb zu immer gleichen Timerwerten, auch wenn die physikalische Zeit weiterläuft. Implementierungen sollten deshalb nicht aktiv (eventuell in einer Schleife) warten. Denn IEC-Timerwerte ändern sich im aktuellen Task-Scan nicht.

Pointer, Referenzen, Interfaces

Die Mittel POINTER TO, REFERENCE TO und INTERFACE (und Interface-Instanzen) für das Ausdrücken von Beziehungen zwischen Applikationseinheiten funktionieren nicht mit synchronisierten redundanten Applikationen.

POINTER-Variablen dürfen nicht in Datenbereichen deklariert werden, die unter Redundanzkontrolle liegen. Denn redundant kontrollierte Daten werden während einer Synchronisierung auf die andere SPS übertragen. Pointer sind jedoch auf der anderen SPS nicht gültig, weil dort ein anderes Speicherlayout vorliegen kann.

Während des Übersetzens prüft die Redundanzfunktionalität, ob ein Pointer in einem redundant kontrollierten Bereich liegt. Für jeden Pointer, der dort gefunden wird, erscheint eine Warnung. Die Prüfung kann mit Hilfe des folgenden Eintrags in der Gerätebeschreibungsdatei deaktiviert werden:

<Device>
    <Custom>
            <Redundancy DisablePointerChecks="true">

EtherCAT DC

Die Redundanzerweiterung ist eher für die Prozessindustrie als für die Fabrikautomation ausgelegt. Deshalb werden EtherCAT-Antriebe mit verteilten Uhren nicht unterstützt. EtherCAT-E/As werden jedoch unterstützt.

Siehe auch Abschnitt „Task und Kommunikation in Echtzeit“ oben.

"Map on Existing": Abbilden auf bestehende Variablen

Die E/A-Mapping-Methode „Map on Existing” (Abbilden von E/As auf bestehende Variablen) wird bei Verwendung von CODESYS Redundancy nicht empfohlen. Solche Variablen werden nicht in den Eingangs- oder Ausgangsdatenbereichen gespeichert, sondern dort, wo sie deklariert sind. Dies führt dazu, dass sie während des Betriebs nicht synchronisiert werden.

Netzwerkvariablen

Netzwerkvariablen mit Schreibzugriff dürfen nicht verwendet werden, weil sonst mehrere Schreibtelegramme gleichzeitig gesendet werden. Netzwerkvariablen mit Lesezugriff sind erlaubt.

Dateizugriff

Ein Dateizugriff darf nicht verwendet werden, da unterschiedliche Dateidaten auf den unterschiedlichen SPSen beim Umschalten „Bumps“ verursachen können.

Wenn Sie Dateien verwenden, müssen Sie Dateihandles in den Datenbereichen deklarieren, die nicht der Redundanzkontrolle unterliegen. Die Dateien müssen auf beiden SPSen separat geöffnet werden. Das Dateihandle einer anderen SPS darf nicht verwendet werden, um auf Dateien auf dem lokalen PC zuzugreifen.

Beim Übersetzen prüft CODESYS Redundancy , ob Handlevariablen (RTS_IEC_HANDLE, CAA.HANDLE) in einem redundant kontrollierten Bereich liegen. Für jede Handlevariable, die in einem solchen Bereich gefunden wird, erscheint eine Warnung.

Online-Security-Benutzerverwaltung

Wenn eine Online-Security-Benutzerverwaltung verwendet wird, müssen Sie beide SPSen mit den gleichen Benutzernamen und den gleichen Passwörtern konfigurieren. Ansonsten werden Onlinedienste wie write variable oder online change nicht auf die Standby-SPS übertragen.

SoftMotion

CODESYS SoftMotion und CODESYS Redundancy können nicht kombiniert verwendet werden. Die Zeitanforderungen von SoftMotion können beim Einsatz von Redundanz nicht erfüllt werden.