Buszykluszeit, Synchronisationsgenauigkeit und Datenmenge sind bei Real-Time-Ethernet (RTE) gegenüber der Feldbustechnik um mindestens den Faktor zehn besser. Diese Eigenschaften werden heute in einem Verbund von schnellen Achsen z.B. in einer Roboterzelle, Verpackungs- oder Druckmaschine gefordert werden. Dazu muss die gesamte Informationskette Netzwerk Kommunikationsanschaltung Host aufeinander abgestimmt und sorgfältig entworfen werden. CNC-Steuerungen und Antriebe sind heute in der Regel als Zwei-Prozessor-Lösungen aufgebaut. Die Aufgaben Motion und Communication werden jeweils durch einen eigenständigen Prozessor ausgeführt. Der Zugriff auf das Ethernet-Netzwerk erfolgt über eine weitere Hardwareeinheit. Im einfachsten Fall besteht diese aus einem Standard Medium Access Controller (MAC) und Ethernet Leitungstreiber/Empfänger (PHY) z.B. für Ethernet/IP. Ergänzt um eine spezielle Logik werden diese Funktionen als dedizierte Asics z.B. Ertec für Profinet oder ET1100 für Ethercat oder auf Basis von FPGAs z.B. für Powerlink oder Sercos III realisiert. Alternativ bietet Hilscher mit dem netX Netzwerk-Controller an, die alle Real-Time-Ethernet-Systeme in einem Chip realisiert. Aufbau des Motion Controllers mit Real-Time-Ethernet Der Netzwerk-Controller netX umfasst den Kommunikations-Prozessor und die RTE-Funktionen sowie die PHYs für zwei Ethernet-Ports. Der Prozessor benutzt eine 32Bit/200MHz ARM-CPU für die Bearbeitung des Protokollstacks. Die Arithmetic Logic Units (ALU) hingegen realisieren die RTE-Funktionen in den Funktionsblöcken xMAC und xPEC. Die Arithmetic Logic Units haben eine RISC-Architektur (reduced instruction set computer) mit einem auf Kommunikationsaufgaben optimierten Befehlssatz. Sie arbeiten mit einem Taktzyklus von 100MHz. Der xMAC hat zwei Arithmetic Logic Units mit einem 64Bit-Befehlscode, die bis zu acht Befehle in einem Takt bearbeiten, während der xPEC als Event-Controller ausgelegt ist und über eine 32Bit-Arithmetik verfügt. Zusammen erreichen die Arithmetic Logic Units eine durchschnittliche Rechenleistung von 600MIPs und bilden einen Kommunikationskanal. Je nach Netzwerk-Controller sind bis zu vier dieser Kanäle in einem Chip vorhanden. Die Seriell/Parallel-Wandlung der Daten erfolgt in den beiden Arithmetic Logic Units des xMAC. Sie übernehmen auch die Synchronisation bzw. die Zeitstempelung der Ethernet-Frames, um die lokale Uhrzeit zu generieren. Das Zusammenbauen des Ethernet-Frames, die Telegrammablaufsteuerung und der Austausch mit der ARM (Advanced RISC Machines) werden von der Arithmetic Logic Unit im xPEC ausgeführt. Der Microcode der Arithmetic Logic Unit wird zum Systemstart durch die ARM geladen. Er ermöglicht es, Änderungen und Erweiterungen in den Real-Time-Ethernet-Spezifikationen per Software-Update zu berücksichtigen. Zur Datenübergabe an den Motion-Prozessor steht ein Dual-Port-Memory-Interface mit einer Datenbreite von 8 oder 16Bit (netX 100) bzw. bis zu 32Bit (netX 50) zur Verfügung. Das Dual-Port-Memory wird emuliert und nutzt den internen Speicher des Netzwerk-Controllers. Dadurch kann der Anwender den Speicher auf bis zu acht Blöcken mit eigenen Handshake-Bits und einer Speichergröße von bis zu 64kByte konfigurieren. Der interne Speicher ist in vier Blöcke aufgeteilt. Solange von der ARM, vom Direct Memory Access (DMA)-Controller oder über das DPM-Interface auf unterschiedliche Blöcke zugegriffen wird, erfolgen die parallelen Zugriffe über den Data-Switch ohne Arbitrierung im 100MHz-Systemtakt. Im netX 50 wurden die Erfahrungen aus den ersten Motion Designs eingebracht. So wurde u.a. der Softwareaufwand reduziert und Buszykluszeiten von 30µs beim Datentransfer zum Motion-Prozessor erzielt. Die Aufgabe im Design eines Antriebs mit RTE-Interface besteht darin, die Kommunikation auf dem Netzwerk mit dem Einlesen der Ist- und dem Ausgeben der Sollwerte im Motion-Prozessor auf deutlich unter 1µs zu synchronisieren. Parallel dazu müssen die zyklischen Daten im 30µs-Takt ausgetauscht werden. Alle Synchronisations- mechanismen in einem Chip Die einzelnen Real-Time-Ethernet-Syteme haben unterschiedliche Synchronisationsverfahren. Verbreitet ist die Nachregelung einer lokalen Uhr. Ethernet/IP und Profinet benutzen hierzu den Standard IEEE1588, während Ethercat ein eigenes Verfahren entwickelt hat. Generell werden die Empfangs- und Sendezeitpunkte bestimmter Synchronisationsframes von den xMACs mit einer Auflösung von 10ns gemessen und zur Laufzeitmessung auf der Ethernetleitung benutzt. Ist diese ermittelt, kann die Abweichung der lokalen Uhr gegenüber der empfangenen Systemzeit nachgeregelt werden. Hiermit lassen sich Genauigkeiten von besser als 100ns erreichen. Eine weitere Logik vergleicht die abgelaufene Zeit mit der eingestellten Zykluszeit und erzeugt daraus das zyklische Synchronisationssignal. Mit Ausnahme des Algorithmus zur Nachregelung der lokalen Uhr erfolgt die Bestimmung des Synchronisationszeitpunktes innerhalb der deterministisch arbeitenden Kommunikations-ALUs. Das Synchronisationssignal wird vom xPEC an einem Ausgang zur Verfügung gestellt oder kann als Interrupt der ARM konfiguriert werden. Im netX 50 kann das Signal mit dem Interrupt des Dual-Port-Memory verknüpft werden und steht als gemeinsamer Interrupt dem Motion-Prozessor zur Verfügung. Handelt es sich um einen Motion Controller, kann dieser den Synchronisationszeitpunkt bestimmen, und der Anschluss am xPEC wird als Eingang konfiguriert. Soll die Synchronisation über einen DPM-Zugriff vom Motion-Prozessor gesteuert werden, erfolgt dies beim netX 50 direkt zum xPEC, während beim netX 100 der FIRQ des ARM zu verwenden ist. Des Weiteren kann im netX 50 das Synchronisationssignal bezogen auf den Synchronisationszeitpunkt durch eine zusätzliche Logik verschoben werden. Im netX 100 wird dafür der xPEC des für die Kommunikation gesperrten vierten Kanals genutzt. Logik für den schnellen Datentransfer Nachdem die Daten vom xPEC dem Ethernet-Frame entnommen sind, müssen sie in den Speicher der ARM transportiert werden. Dabei gibt es – je nach Datentyp – unterschiedliche Verfahren zwischen ARM und xPEC, um den Transfer optimal zu gestalten. Daher ist der Datenspeicher des xPEC als Dual-Port-Memory ausgeprägt, und jeder xPEC verfügt über einen intelligenten DMA-Controller. Eine Pointer FIFO und der Buffer Manager steuern den Transfer. Azyklische Daten werden nach ihrer Priorität in Warteschlangen einsortiert und immer dann bearbeitet, wenn die notwendigen Ressourcen zur Verfügung stehen. Das geschieht über Speichersegmente, die die ARM verwaltet und der xPEC zum Parametrieren seines DMA-Controllers benötigt. Die Startadressen werden über eine Pointer FIFO ausgetauscht. Zyklische Daten werden je nach Menge über das Dual-Port-Memory des xPEC oder im internen ARM-Speicher per DMA übergeben. Ist die Übertragung vom xPEC in den ARM-Speicher und von dort in das Dual-Port-Memory zum Motion Controller zu entkoppeln, erfolgt das über so genannte Tripple Buffer. Im netX 50 wurde für die Verwaltung der Tripple Buffer ein eigener Buffer Manager implementiert. Dadurch ist der Transfer bei kleinen Zykluszeiten entspannt, da die Adresse des jeweils nächsten Schreib- oder Lesebuffers mit einem Lesezugriff auf den Buffer Manager zu ermitteln ist. Im netX 100 erfolgt dies unter Interruptschutz per Software. Daten für Motion Controller Synchron übergeben Die anspruchsvollste Kommunikations-Anwendung ist ein Motion Controller mit Encoder und Antriebsverstärker in einer über Ethernet geschlossenen Regelschleife. Mit dem Netzwerk-Controller ist ein Verbund von acht Achsen und einer Abtastfrequenz von 25kHz realisierbar. Für die synchrone Datenübertragung über das DPM zum Motion-Prozessor ist ein Verfahren mit einem Synchronisations-Interrupt und einem Datentransfer-Interrupt pro Übertragungsrichtungen geeignet. Das ermöglicht eine schnelle Regelschleife über das Netzwerk mit einer konstanten Totzeit von einem Bustakt. Dieser Bustakt steht für den Transfer der Daten und dem Motion Controller für den Regelalgorithmus zur Verfügung. Benötigt der Regelalgorithmus mehr Zeit, ändert sich das Verfahren nicht. Lediglich die Zeitüberwachung muss auf zwei oder drei Bustakte vergrößert werden. Der Netzwerk-Controller als Kommunikations-Prozessor gibt Bustakt und Abtasttakt dem Motion-Prozessor vor. Der Timer dazu wird im xPEC geführt. Alle Peripherieeinheiten für Single-Chip Motion Controller Der netX 100 enthält alle Peripherieeinheiten, um einen kompakten Motion Controller aufzubauen. Dazu zählen zwei Encodereingänge mit Impulsvervierfachung, acht A/D-Wandler mit 10Bit-Auflösung und zwei unabhängigen Sample&Hold-Stufen sowie eine programmierbare Drei-Phasen-Pulsweitenmodulation mit einstellbarer Totzeit. Die Einheiten sind direkt an den Arithmetic Logic Units der vierten xMAC/xPEC-Einheit angeschlossen. Damit kann die gesamte Ein- und Ausgabe der Daten von deren Arithmetic Logic Units mit einer Genauigkeit von 20ns bezogen auf den Synchronisationszeitpunkt der Kommunikation erfolgen. Weitere Möglichkeiten bestehen in dem mehrfachen Abtasten der Motorströme und der Signalaufbereitung durch die autonom laufenden Arithmetic Logic Units. Ein weiterer interessanter Aspekt beim Einsatz des Netzwerk-Controllers als Motion Controller ist der frei verfügbare dritte Kommunikationskanal. Hier steht bereits eine SSI-Implementation zur Verfügung. Bei Bedarf können weitere serielle Encoder-Schnittstellen implementiert werden oder ein Feldbus für lokale E/As gefahren werden.
Hilscher Gesell. f. Systemautomation mbH
