Technologie
Einführung
Der CU2508 erweitert als möglichst transparenter Port-Multiplier einen GBit-Ethernet-Port an der Steuerung auf 8 FastEthernet-Ports im Feld. Er transportiert IEEE802.3-konforme Ethernet-Frames beliebigen Inhaltes.
Jeder Port des CU2508 sendet und empfängt FastEthernet-Frames (100 MBit, 100BASE-TX) über bis zu 100 m Kupferleitung/RJ45. Der CU2508 erzeugt selbst keine Frames oder verarbeitet ihren Inhalt, sondern er leitet ausschließlich von einem besonderen Software-Treiber an ihn gesendete Frames über seine 8 Ports gezielt weiter an das Feld bzw. leitet aus dem Feld empfangene Frames an den Treiber weiter. Optional ist dabei die hochgenaue zeitliche Information, wann die Frames versendet bzw. empfangen werden.
Der CU2508 verfügt dazu
- über den Uplink-GBit-MasterPort (X9) zum Treiber im Controller, der an der Gegenseite einen Gbit-Anschluss benötigt
- über 8 10/100 MBit-Downlink-Ports (X1-X8) für den Realtime-Traffic zu den angeschlossenen Feld-Geräten
Ein CU2508-System besteht somit aus dem CU2508-Gerät und dem CU2508-Treiber, z. B. integriert in TwinCAT 2.11R2 oder TwinCAT 3
Das CU2508-System ersetzt nicht Masterimplementationen von Ethernet-basierenden Feldbussen, sondern es tunnelt vorgegebene Datentelegramme über die GBit-Verbindung und versendet die Frames dann zur vorgegebenen Zeit. Es verhält sich für die darüber geführten Protokolle transparent, mit Ausnahme des EtherCAT-Protokolls - hier ist ein CU2508-Teilnehmer als erster Slave in der Konfiguration ersichtlich. Jedem real vorhandenen I/O-System auf der Feldseite muss also eine logische Masterkomponente in der Steuerung gegenüberstehen.
Es können mehrere CU2508 je TwinCAT-System eingesetzt werden.
Im Folgenden werden einige Teilfunktionen des CU2508 und Betriebsarten beschrieben.
Downlink Port Eigenschaften
Die Grundeinstellung des CU2508 ist für Verwendung mit EtherCAT-Downlinks optimiert, insbesondere für den EtherCAT–IO-Redundanz Betrieb. Deshalb hatten die 8 Downlinks bis inkl. FW11 in der Werkseinstellung die Eigenschaft, ankommende 100Mbit-Frames an den Sender zurückzuspiegeln, wenn der 1GBit-Uplink fehlt, genannt „Auto Link Close“.
Im Nicht-EtherCAT-Betrieb kann diese Eigenschaft hinderlich sein und das darunterliegende Netzwerk irritieren. Deshalb ist sie ab FW12 global für alle Downlink-Ports deaktiviert, so dass im Falle eines Uplink-Verlusts keine Zurücksendung ankommender 100 Mbit-Frames stattfindet sondern die Frames im CU2508 „versickern“. Der elektrische Link wird nicht verändert.
ESL-Protokoll
Der Software-Treiber im Controller/Steuerungsgerät/IPC bildet das Gegenstück zum CU2508. Er arbeitet auf einem GBit-Port im Controller und "verpackt" die User-Daten in das EtherCAT Switch Link-Protocol (ESL) bzw. entpackt das ESL-Protokoll vom CU2508 und leitet die Nutzdaten weiter zur Anwendung. Es wird also kein extra Telegramm mit Steuerdaten zum/vom CU2508 für das Handling der Nutzdaten gesendet, sondern die vom Anwenderprogramme erzeugten Nutzdaten werden für die Verbindung zwischen Controller und CU2508 um einige Byte Steuer- und Informationsdaten ergänzt.
Der CU2508-Treiber ist in TwinCAT ab Version 2.11R2 integriert, beachten Sie dazu die Angaben in den Technischen Daten. Das ESL-Protokoll ist offengelegt, siehe Beschreibungsseite. Außerdem ist es in der Wireshark-Installation seit der Version 1.4.2 enthalten.
EtherCAT Systeme am CU2508
Eine mögliche Verwendung des CU2508 ist der Betrieb von mehreren FastEthernet-EtherCAT-Systemen an 1 Port des IPC, also quasi als Port-Vervielfacher. Daraus resultiert auch die Bezeichnung als „Port Multiplier“.
Beim Betrieb von mehreren EtherCAT Systemen an den Ports eines CU2508 sind ggf. zeitliche Effekte zu beobachten die relevant für die Applikation sein können. Dazu im Folgenden einige Erläuterungen.
Der CU2508 unterstützt grundsätzlich die folgenden 3 Betriebsarten. Zum Verständnis sind grundlegende Kenntnisse über die EtherCAT-Betriebsarten und Synchronisierungsmethoden hilfreich.
- Standard-Modus: keine Frame-Beeinflussung, kein DistributedClocks
- Der CU2508 leitet per GBit-ESL ankommende Frames am gewünschten FastEthernet-Port weiter, genauso in Gegenrichtung. Es erfolgt keine zeitliche Steuerung der Ethernet Frames.
- Somit arbeiten die EtherCAT-Slaves der unterlagerten Systeme frame-getriggert (oder FreeRun) und der Zeitpunkt von Ausgaben ist wesentlich abhängig z. B. von Frameverzögerungen/Jitter.
- Zeit-gesteuertes Senden/zeit-gestempeltes Empfangen: mit Frame-Beeinflussung, kein DistributedClocks
- Der CU2508 leitet per GBit-ESL ankommende Frames am gewünschten FastEthernet-Port zum angeforderten Zeitpunkt weiter, in Gegenrichtung erfolgt eine Zeitstempelung. Es erfolgt also eine zeitliche Steuerung der Ethernet Frames.
- Frame-getriggerte EtherCAT-Slaves arbeiten somit „jitter-arm“, auch zeitlich „gleich“ zwischen den EtherCAT Systemen.
- Damit die Frames zeitgesteuert weitergeleitet werden können, ist eine Zwischenspeicherung im CU2508 erforderlich, dies kann u. U. erhebliche Verzögerung bewirken. Die Verwendbarkeit ist bei kurzen Zykluszeiten zu prüfen!
- Diese Betriebsart wird noch nicht unterstützt (Stand 2019).
- DistributedClocks-Modus, keine Frame-Beeinflussung
- Die weitergeleiteten EtherCAT-Frames unterliegen zeitlicher Beeinflussung durch den sendenden IPC, den CU2508 und die EtherCAT-Slaves.
- Die Ports X1..8 werden als DistributedClocks - ReferenceClock parametriert
- Somit arbeiten die EtherCAT-Slaves der unterlagerten Systeme, die DistributedClocks unterstützen, ebenfalls DC-synchron. Das bedeutet, die Ein/Ausgabe-Operationen in diesen Slaves können synchronisiert erfolgen, auch zeitlich „gleich“ zwischen den EtherCAT-Systemen an Port X1..8.
Das Gesamtsystem ist dann im Grunde unabhängig von Frameverzögerungen/Jitter, solange diese nicht so wesentlich werden, dass die DistributedClocks-Regelung beeinträchtigt wird. - Diese Methode ist (in Bezug auf EtherCAT-Betrieb) im Endeffekt die sinnvollste, denn
• die Ein/Ausgabeoperationen der EtherCAT-Teilnehmer sind zeitlich am besten definiert
• es werden keine Zeitpuffer im CU2508 nötig
Folgende Aspekte sind zu berücksichtigen um zeitliche Effekte in den Betriebsarten 1 und 3 abschätzen zu können:
- Ethernet-Frames haben je nach Dateninhalt eine zeitliche Länge von
- X1..8 FastEthernet: 7..128 µs, InterFrameGap (IFG) 9,6 µs
- X9 Gbit: 0,7..12 µs, IFG 0,96 µs
- Der CU2508 hat aufgrund der unterschiedlichen Transportgeschwindigkeit für jeden Port einen internen verzögernden Datenpuffer.
- Auf dem GBIT/ESL-Anschluss werden die GBit-Frames für X9 von TwinCAT seriell (hintereinander) gesendet. Die GBit-Framelängen können in Relation zu ggf. kurzen TwinCAT-Zykluszeiten bereits in relevanter Größenordnung liegen!
- Sind in TwinCAT mehrere Tasks zu bearbeiten, rechnet TwinCAT diese in der Standard-Einstellung seriell (hintereinander) ab. Dies führt in der Folge dazu, dass die ESL-Frames entsprechend verzögert abgeschickt werden.
Abhilfe schafft die Einstellung „isolated core“ in den RealTime Tasks damit die Tasks parallel bearbeitet werden. - Zu berücksichtigen ist auch die EtherCAT-Framelänge.
Beispiel: Es wird an Port X1 und X2 jeweils ein EtherCAT-System installiert mit je einer EL2202 als Ausgabeklemme. Die Flanken sollen zu Demonstrationszwecken per Oszilloskop nachgemessen werden. Das Bit der jeweils verwendeten Ausgabeklemme liegt im System X1 in einem kurzen 7 µs Frame, im System X2 aber in einem langen 128 µs Frame. Allein dadurch wird das Signal in System X2 121 µs später ausgegeben.
Abhilfe schafft die Verwendung von DistributedClocks, siehe oben.
(Die Position der Ausgabe-Daten im EtherCAT-Frame spielt üblicherweise keine Rolle da Ausgabedaten erst nach vollständiger Passage des Frames am Ausgabegerät nach Kontrolle der Checksumme ausgegeben werden.) - Die Verzögerungen, die durch das Management des CU2508 verursacht werden, betragen typischerweise
- Im Downlink
Gbit X9 to FastEthernet X1..4: tFE = 1 µs
Gbit X9 to FastEthernet X5..8: tFE = 1,6 µs - Im Uplink
FastEthernet X1..X4 to Gbit X9: tGE = 0,7 µs
FastEthernet X5..X8 to Gbit X9: tGE = 1,1 µs - Diese Verzögerungen sind also relativ unbedeutend im Vergleich zu den o. a. anderen Faktoren. Was aber anhand der Grafik sofort ins Auge fällt, ist die Bedeutung der Framelänge und der nötigen Zwischenspeicherung im Uplink.
CU2508 als EtherCAT Slave
Jeder Downlink-Port des CU2508 kann als eigenes "EtherCAT Gerät" konfiguriert werden, s. Kapitel Einrichtung EtherCAT-Gerät. In diesem Fall stellt der CU2508-Port den ersten EtherCAT-Teilnehmer im System dar. Er ist Distributed-Clocks-fähig und kann damit als ReferenceClock im Strang dienen.
Durch Kombination zweier solcher EtherCAT Ports unter Verwendung des (kostenpflichtigen) Supplements "TwinCAT Kabelredundanz" ist die Kombination von EtherCAT-Kabelredundanz und Distributed-Clocks-Funktion möglich.
Zeitgesteuertes Senden/Empfangen (in Vorbereitung)
Die Frameweiterleitung im CU2508 kann einer exakten Zeitkontrolle durch die lokale Uhr unterworfen werden:
- der Treiber bzw. die Anwenderapplikation gibt an, zu welchem Zeitpunkt und über welchen Downlink-Port ein Frame vom CU2508 versendet werden soll.
Diese Angaben werden vom Treiber als Zusatzinformation jedem Frame angefügt. - jeder vom CU2508 an einem Downlink-Port empfangene Frame wird um Empfangsinformationen ergänzt (Empfangsport, Zeitpunkt) und über den Uplink zum Controller weitergeleitet.
Die lokale Hardware-basierte Uhr im CU2508 steuert dann das Versenden der Frames mit einer hohen zeitlichen Güte. Dadurch erlaubt der CU2508 den Aufbau eines Realtime-Ethernet-Netzwerkes (TwinCAT Publisher/Subscriber, Profinet, ...) auch wenn das Steuergerät keine harte Echtzeit in der Versendung der Protokolldaten gewährleisten kann. Das Steuergerät muss jedoch die Daten ausreichend schnell anliefern bzw. abnehmen können.
Die Zeitsteuerung nutzt das vom EtherCAT Distributed Clocks System bekannte 64-Bit-Zeitformat: Auflösung 1 ns, beginnend ab 1.1.2000 00:00 und damit ausreichend für ~584 Jahre
Die Zeitstempelinformationen (Senden und Empfangen) werden vorläufig nur vom CU2508-Treiber ausgewertet und stehen der Anwenderapplikation nicht zur Verfügung.
Als Beginn eines Ethernet-Frames wird der SFD (Start of Frame Delimiter) nach IEEE802.3-Standard gewertet.
EoE und TCP/IP
Der CU2508 ist über die GBit-Schnittstelle mit dem IPC verbunden. Diese Ethernet-Schnittstelle tritt im Betriebssystem/Windows des IPC mit ihren Eigenschaften (IP-Adresse, IP-mask etc.) auf. Aus der Sicht des Betriebssystems gibt es also "nur" diesen einen Netzwerkanschluss an den Telegramme gesendet oder von dem empfangen werden kann. Der CU2508-Treiber kann nun Datenverkehr der Betriebssystemebene entweder an einen dezidierten CU2508-Port durchleiten oder in den virtuellen EtherCAT-EoE-"Switch" einspeisen. Vergleiche dazu auch die Dokumentation der EL6601/EL6614. Die Auswahl wird über die Einstellung im System Manager getroffen. Über "TCP/IP Port" kann entweder der bestimmte CU2508-Port oder allgemein EoE ausgewählt werden.
Siehe dazu insbesondere die TCP/IP-Hinweise.
Anwendungen
Die oben beschriebenen Funktionen lassen die Verwendung des CU2508 u.a. für folgende Anwendungen zu:
- Multi-EtherCAT Adaper
Es können bis zu 8 eigenständige EtherCAT-Systeme erstellt werden. - Synchronisierte EtherCAT Systeme
Wird der CU2508 als ReferenceClock gewählt, werden die am CU2508 angeschlossenen EtherCAT-Systeme mit gleicher synchronisierter Zeitbasis betrieben. - EtherCAT Kabelredundanz
Je 2 Downlink-Ports des CU2508 können zu einem kabelredundanten EtherCAT-System zusammengefasst werden. Damit werden weniger Ethernet-Ports an der Steuerung belegt, nur noch ein GBit-Ethernet-Port wird für den Uplink benötigt. Es sind somit je CU2508 bis zu 4 kabelredundante EtherCAT-Systeme möglich. Der CU2508 wird bei der Steuerung im Schaltschrank platziert, trennungsgefährdete I/O-Kabelverbindungen werden dann redundant im Ringschluss aus dem Schaltschrank geführt. - EtherCAT Kabelredundanz mit Distributed Clocks
Durch die gemeinsame Zeitbasis des CU2508 sind auch EtherCAT Slaves, die Distributed Clocks benötigen, im Redundanzfall weiterhin der Synchronisierung unterworfen.
Der CU2508 ist derzeit die einzige Möglichkeit, Distributed-Clocks-fähige Slaves in einem kabelredundanten Ring zu betreiben. - TCP/IP Nutzung ohne Echtzeit
Am CU2508 kann ein Downlink-Port als Nicht-Echtzeit-EthernetPort konfiguriert werden, oder der CU2508 arbeitet im Ethernet over EtherCAT (EoE) - Verbund und leitet aus den angeschlossenen EtherCAT-Systemen TCP/IP-Frames weiter. - Echtzeit-Feldbus an Nicht-Echtzeit-Steuerung
Wenn ein Ethernet-basierender Feldbus eine verlässliche Konstanz in Bezug auf das Versenden der Kommunikationstelegramme erfordert, ist ein geringer Jitter in den zyklischen Operationen der Steuerung gefordert. Vermag eine performante Steuerung zwar die zyklische Operationen ausreichend häufig (= geforderte kurze Zykluszeit) bearbeiten können, der Jitter, d. h. der regelmäßige Abstand zwischen den Zyklen aber unzulässig hoch liegen, kann das CU2508-System als Echtzeit-Framehandler den konstanten Abstand im Frameversenden bereitstellen, wenn die neuen Daten ausreichend rechtzeitig im CU2508 vorliegen.
Einschränkungen bestehen derzeit (TwinCAT 2.11/3.1, FW10) noch bzgl.
- externe Synchronisierung des CU2508
Die Einflussnahme auf die interne CU2508-Uhr befindet sich noch in Vorbereitung. - Profinet
- BACnet
- zeitstempelgesteuerte Versendung/Empfangen von Frames
Die Implementierung dieser und weiterer Protokolle befindet sich in Vorbereitung.
Datenumsatz in den unterlagerten EtherCAT-Strängen
Die Ports 1 und 5 sind ab FW07 und ESI-Revision -0018 für EtherCAT-Stränge mit besonders hohem Datenumsatz mit einem vergrößerten Daten-Zwischenspeicher von 16 kByte statt sonst 8 kByte ausgestattet.
„Hoher Datenumsatz“ wird erzeugt durch IO-Systeme mit vielen zyklischen Daten, z. B. wenn viele Teilnehmer (über 100) oder/und Teilnehmer mit großem Datenbedarf (z. B. analoge Oversampling-Klemmen) eingesetzt werden.
Wird ein „großes“ IO-System im EtherCAT-Redundanz-Modus betrieben, ist es zweckmäßig dazu die Ports 1 und 5 zu benutzen.
Die vorgefunden Speicher-Situation wird fallweise von TwinCAT mit „Cu2508 fifo sizes…“ gemeldet: