Grundlagen
Die Function TE1111 TwinCAT EtherCAT Simulation dient zur Simulation eines EtherCAT-Stranges. Dabei wird eine erstellte E/A-Konfiguration der realen Anlage exportiert und kann auf einem zweiten System als „EtherCAT-Simulation“-Device wieder importiert werden. Auf diesem System steht damit ein gespiegeltes Prozessabbild zur Verfügung, das mit entsprechenden TwinCAT-Modulen (z.B. erstellt in den Sprachen der IEC 61131-3 oder aus Matlab®/Simulink® heraus) verknüpft werden kann. In diesen Modulen muss das gewünschte Verhalten der Maschine hinreichend genau implementiert sein. Startet man nun auf beiden Systemen die TwinCAT-Echtzeit, hat man eine HIL-Simulation, ohne dass das Original-Projekt dafür angepasst werden muss.
 | Da das Projekt des zu testenden Steuerungssystems nicht verändert werden soll, arbeitet das EtherCAT-Simulation Device nicht synchronisiert. Dies bedeutet, dass die Task, welche das Simulation-Device treibt, aufgrund des Shannonschen Theorems (Abtast-Theorem) doppelt so schnell laufen muss. Auf Standard-IPC-Hardware ist die kleinste Zykluszeit des Simulation Devices derzeit 50µs. Somit sind HIL-Simulationen des zu testenden Steuerungssystems mit 100µs Zykluszeit möglich. |
Neben der HIL-Simulation kann die EtherCAT-Simulation aber auch zur Simulation eines oder mehrere EtherCAT-Stränge auf demselben Rechner verwendet werden, solange genügend freie Netzwerk-Schnittstellen zur Verfügung stehen. Je nach Anwendungsfall sind verschiedene Verkabelungsmöglichkeiten vorhanden, welche im Kapitel Verkabelung aufgezeigt werden.
Die EtherCAT-Simulation beschränkt sich im Wesentlichen auf die EtherCAT-relevanten Aspekte der Bus-Teilnehmer. Das interne Verhalten der Busteilnehmer selber wird dabei vernachlässigt. Für einige Busteilnehmer ist es aber erforderlich zumindest ein Teil des Verhaltens zu simulieren, da andersfalls der EtherCAT-Master nicht korrekt auf gestartet werden kann (z. B. EL6224). Um dies zu simulieren, bietet die EtherCAT-Simulation die Möglichkeit, die Option Mailbox Auto Response zu aktiveren, welche solche Anfragen automatisch beantwortet ohne das etwas implementiert werden muss. Sollten diese Parameter dennoch benötigt werden, kann diese Option auch deaktiviert werden. In diesem Fall ist es möglich die CoE, SoE und AoE-Kommunikation in ein Anwender-SPS-Module umzuleiten und dort auf diese Telegramme zu reagieren (siehe hierzu CoE / SoE / AoE).
Ein weiteres Beispiel, bei dem die reine EtherCAT-Betrachtung der Teilnehmer nicht ausreicht sind Antriebe. Hier ist es erforderlich zumindest einen Teil der Antriebs-State-Machine zu implementieren, damit die TwinCAT NC korrekt auf starten kann. Für die Antriebsprofile CoE und SoE sind diese beispielhaft als Funktionsbaustein implementiert (siehe hierzu Antriebssimulation). Diese Funktionsbausteine können für jeden in der Konfiguration enthaltenen Antrieb, entsprechend in einem SPS-Module instanziiert und mit den Achsen verknüpft werden. Sie werden somit zwischen der EtherCAT- und der zu implementierenden Prozess-Simulation geschaltet.