Grundlagen zur Funktion
Die EL66xx Ethernet Switchport Klemmen können mit 2 unterschiedlichen Betriebsarten die Aufgaben der Ethernet-Konnektivität optimal erfüllen. Die beiden Betriebsarten, die auch gleichzeitig aktiv sein können, bilden sowohl den echtzeitkritischen Versand und Empfang von konfigurierten Netzwerkvariablen als auch den Nicht-echtzeitkritischen aber durchsatzstarken Transport von Standard-Ethernet-Verkehr z. B. mit IP-Protokoll ab:
- Echtzeitverkehr: Publisher/Subscriber, Beckhoff Netzwerkvariablen, EAP
Durch die TwinCAT-Konfiguration *.tsm wird eine EL66xx beim EtherCAT-Start so mit CoE-Parametern konfiguriert, dass sie - im Echtzeitzyklus über den zyklischen Datenverkehr gelieferte Daten als Publisher versendet.
- ebenso empfangene Subscriber an den EtherCAT Master durch den zyklischen EtherCAT-Verkehr übermittelt.
Der zyklische Datenverkehr zur EL66xx wird beim EtherCAT-Start in den PDO-Einstellungen der EL66xx konfiguriert und ist online nicht veränderbar. - Nicht-Echtzeitverkehr
Parallel dazu kann die EL66xx Ethernet-Frames über den azyklischen Mailbox-Verkehr (EoE = Ethernet over EtherCAT) zwischen Klemme und EtherCAT Master/TwinCAT übertragen. Diese Übertragung erfolgt durchsatzoptimiert und ggf. mit automatischer Fragmentierung - standardmäßig werden alle Telegramme, die nicht im PDO-Kontext übertragen werden, im azyklischen Kanal über EoE transportiert.
Der Datenlauf in der EL66xx kann wie folgt schematisiert werden:
Die EL6601/EL6614 kann kein EtherNet Industrial Protocol (EtherNet/IP) transportieren.
Diagnose
Online Diagnose
Im CoE-Verzeichnis stehen folgende Objekte zur ersten Diagnose zur Verfügung:
- 0xFA01, Subindex 01: Frame Counter Rx (an RJ45-Buchse ankommend).
- 0xFA01, Subindex 02: Frame Counter Tx (ab RJ45-Buchse abgehend).
Die Werte können aus der Steuerung über PLC-Bausteine (FB_EcCoeSdoRead in TcEtherCAT.lib) ausgelesen werden.
Diese und weitere Diagnoseinformationen aus dem CoE der EL66xx sind über diesen beispielhaften PLC-Baustein 
zugänglich.
Error LED
Die rote Error-LED leuchtet 250 ms bei
- Ethernet Receive Overrun --> es werden allgemein mehr Ethernet Frames am RJ45-Anschluß empfangen als über EtherCAT (PDO oder Mailbox) abtransportiert werden können. Die Telegramme werden verworfen.
- Ethernet EoE Overrun --> es werden mehr Nicht-Realtime-Frames am RJ45-Anschluß empfangen als über EtherCAT/EoE abtransportiert werden können. Die Daten werden verworfen.
- Ethernet Frame Error
Falls es durch den Overrun-Fall zu Datenverlusten kommt, sind übergeordnete Protokollschichten in einem Ethernet-Netzwerk für eine erneute Übertragung zuständig.
 | Overrun-Fall Im Overrun-Fall kann mit folgenden Maßnahmen entgegengewirkt werden:
|
Kabelredundanz
Wird die EL66xx in einem System mit Kabelredundanz betrieben, ist zu beachten:
- der Realtime-Betrieb mit Netzwerkvariablen ist möglich
- beim Nicht-Realtime-Betrieb mit IP-Übertragung wird der IP-Verkehr über den primären EtherCAT-Port geleitet. Es werden deshalb auch die Windows-IP-Einstellungen dieses Ports angewendet.
Entfällt der Link zu diesem Port, ist aus Windows heraus unter TwinCAT 2 bzw. 3 z.Z. auch keine IP-Kommunikation zu diesem Port mehr möglich.
Deshalb ist zu vermeiden, dass die Ethernet-Verbindung zwischen primärem EtherCAT-Port und dem ersten EtherCAT-Slave ausfällt, da ansonsten keine IP-Kommunikation über die EL66xx mehr möglich ist.
