Gebernetzwerk

Allgemeines

In einer Reihe von Anwendungsfällen ist eine geschwindigkeits- oder gar winkelsynchrone Kopplung mehrerer Maschinen erforderlich. Ein Beispiel stellt die Produktübergabe einer Blistermaschine an einen Kartonierer dar. Hier müssen genaue Geschwindigkeits- und Positions­informationen von Maschine zu Maschine übertragen werden.

Für die Steuerungen steht die Busklemme BT-4/ENC1 zur Verfügung. BT-4/ENC1 hat einen Inkremental-Encoder-Ausgang. In der Folgemaschine wird das Ausgangssignal elektrisch über einen Gebereingang eingekoppelt.

Damit steht eine flexible winkelsynchrone Kopplung zur Verfügung. In der Regel sind weitere Maßnahmen zum einmaligen Positionsabgleich zwischen den beiden Maschinen, sowie ein kontinuierlicher Austausch von Status- und Fehlerinformationen erforderlich.

Ein alternativer Lösungsansatz ist das Gebernetzwerk. Er basiert auf der Ethernetverbindung der PacDrive Controller und ermöglicht die gesicherte Verteilung von „Geberdaten“ zur Maschinensyn­chronisation bei verteilten Steuerungen über Ethernet.

Merkmale

Allgemeine Anforderungen an das Encodernetzwerk

oEinfache Konfiguration und Inbetriebnahme

oEinfache und flexible Einbindung in die Applikation

oEinfache, robuste Verdrahtung

oNiedrige Kosten

Spezielle Anforderungen an das Gebernetzwerk

oMaschinenübergreifende virtuelle Königswellen

oIntegrierte Überwachung und Statusfunktionen

oKoordinierte Reaktionen zur Durchführung von Diagnosen

oZusätzliche Übertragungen von Anwenderdaten

Ausführung - Gebernetzwerk

Ein Gebernetzwerk besteht aus zwei oder mehr PacDrive Controllern. Genau ein Controller muss die Funktion Synchronisation Master übernehmen. Die anderen Teilnehmer arbeiten als Synchronisation Slave. Der Synchronisation Master übernimmt die Synchronisation und Koordination des Gebernetzwerks. Er ist für die Funktion des Netzwerkes zwingend erforderlich.

Die Aufgaben des hier vorgestellten Gebernetzwerkes können in fünf Teilaufgaben aufgespalten werden:

oSynchronisation der lokalen Uhren der beteiligten Controller und Bereitstellung einer globalen Uhr (in ms) für das gesamte System

oVerteilung der Geberdaten

oManagement des Netzwerkes

oVerteilen von zusätzlichen Anwenderdaten

oKoordinierte Diagnose der beteiligten Controller

Standard Architektur und Datenfluss in einem Gebernetzwerk

 

 

In der Abbildung ist die einfachste Architektur für ein Gebernetzwerk dargestellt: ein Master und ein Slave, die über Ethernet miteinander verbunden sind. Der Sync. encoderoutput des Synchronisation Master (EncoderOutput) liefert die Geberdaten an den Sync. encoder input (EncoderIn) Synchronisation Slave. Gleichzeitig werden die Daten an den lokalen Sync. encoder input des Synchronisation Master zurückgegeben. Betrachtet man dabei den Datenfluss, kann man die Kommunikation in zwei Ebenen aufteilen: Eine bidirektionale Kommunikationsebene zwischen Synchronisation Master und Synchronisation Slave und eine unidirektionale Kommunikation vom Sync. encoder output an die Sync. Gebereingänge. Dabei werden folgende Daten ausgetauscht:

Übertragung vom Synchronisation Master zum Synchronisation Slave („grüner Pfeil“):

oGlobale Uhr des Masters

oKontroll- und Diagnoseinformationen

oAnwenderdaten mit Zeitstempel

Antwort des Synchronisation Slave an den Synchronisation Master („schwarzer Pfeil“):

oStatus- und Diagnoseinformationen

oSynchronisationsqualität

oAnwenderdaten mit Zeitstempel

Übertragung der unidirektionalen Geberdaten:

oGeber-Position

oAnwenderdaten (wie Geberposition)

Synchronisation

Die Synchronisation der Uhren erfolgt nach dem Master-Slave-Prinzip. Der Synchronisation Master verteilt eine synchronisierte Zeit mit einer Auflösung in µs an den Sercos-Zyklus. Synchronisation Slave synchronisieren ihre Uhren und deshalb ist ihre Sercos-Schleife gemäß diesem globalen Taktfehler zum Synchronisieren der Uhren bei 200 bis 200 µs niedrig.

Geberdaten

Als Kernaufgabe realisiert das Gebernetzwerk einen netzwerkweit verfügbaren Geber. Die Quelle der Geberdaten ist hierbei auf den Synchronisation Master beschränkt.

Da bei der Kommunikation über Standard-Ethernet immer mit einer Verzögerung von Telegrammen gerechnet werden muss, werden die Geberdaten mit einem Zeitstempel versehen, der um eine eingestellte Zeitspanne (Parameter DataDelay) in der Zukunft liegt. Auf der Empfängerseite werden die Geberdaten in einen Zwischenpuffer geschrieben und dann ausgelesen, wenn der Zeitstempel der aktuellen globalen Uhrzeit entspricht. Wie groß diese Verzögerungszeit dabei gewählt werden muss, hängt davon ab, wie stark die Netzwerkbelastung ist.

Verwaltung

Für die Verwaltung eines Gebernetzwerks ist der Synchronisation Master verantwortlich. Zuerst muss eine zyklische Kommunikation aufgebaut werden. Dazu werden die Synchronisation Slave vom Synchronisation Master einzeln angesprochen und konfiguriert. Hierbei werden die Synchronisation Slave einer Multicast-Gruppe zugeordnet. Darüber hinaus wird die Konfiguration desSynchronisation Slave überprüft (z. B. Sercos-Zykluszeit).

Ist die Konfiguration beendet, verschickt der Synchronisation Master zyklisch ein Multicast-Telegramm, das der Synchronisation Slave empfängt (bei anderen Netzwerkteilnehmern, die dieser Multicast-Gruppe nicht angehören, werden diese Telegramme schon auf Hardwareebene verworfen).

Sobald der Synchronisation Slave die zyklischen Telegramme des Synchronisation Master empfängt, fangen auch die Synchronisation Slave an, in ihrer eingestellten Zykluszeit, Antworttele­gramme (Unicast) an den Synchronisation Master zurückzusenden.

Die Statusinformationen in diesem Telegramm geben unter anderem dem Synchronisation Master darüber Auskunft, ob:

odie Slaves synchronisiert sind,

oGeberdaten empfangen werden,

oauf Slaveseite ein Fehler aufgetreten ist.

Der Synchronisation Master wertet diese Statusinformationen aus und versendet in seinen zyklischen Telegrammen entsprechende Kontrollinformationen, um den Synchronisation Master zu steuern.

Anwenderdaten

In einem Gebernetzwerk ist es bei jeder der in der Abbildung gezeigten Kommunikationsverbin­dungen möglich, Anwenderdaten mit zu versenden.

Anwenderdaten können bis zu 16 Byte groß sein. Dabei sind folgende Varianten möglich:

oAsynchrone Übertragung vom Synchronisation Master zum Synchronisation Slave (MasterUserData, „grüner Pfeil“).

oAsynchrone Übertragung vom Synchronisation Slave zum Synchronisation Master (SlaveUserData, „schwarzer Pfeil“).

oAsynchrone Übertragung vom Sync. encoder output zum Sync. encoder input (UserData, „blauer Pfeil“).

Bei einer asynchronen Übertragung werden die Daten zyklisch (MasterCycleTime bzw. SlaveCycleTime) mit dem aktuellen globalen Zeitstempel versehen und verschickt. Es findet keine Überprüfung statt, ob die Daten angekommen sind. Die Daten (inklusive dem globalen Sendezeitstempel) werden angezeigt, sobald sie empfangen wurden. Bei der synchronen Übertragung, werden die Daten synchron zu den Geberdaten übertragen. Sie werden beim Empfang genauso zwischengespeichert wie die Geberdaten und auch erst gleichzeitig mit diesen angezeigt. Wird ein Telegramm zerstört, wird eine Benachrichtigung über die Diagnose ausgegeben. Zusätzlich kann mit dem Parameter DataValid überprüft werden, ob für den aktuellen Zyklus gültige Daten vorliegen.

Diagnose

Die Diagnose des Gebernetzwerkes ist aufgeteilt auf die beiden Kommunikationsebenen.

oSynchronisation der lokalen Uhren

oAustausch der Geberdaten

Wie exakt diese Überwachung ist, kann vom Anwender je nach Anwendungsfall und für jede Kommunikationsverbindung einzeln eingestellt werden. Treten Fehler auf Seite des Synchroni­sation Slave auf, so werden diese im Statuswort (soweit noch möglich) angezeigt und der Master veranlasst eine entsprechende Reaktion.

Grundsätzlich wird bei der Überwachung angegeben, nach wie vielen Zyklen ein schwerer Fehler gemeldet wird. Bei Auftreten eines schweren Fehlers im Gebernetzwerk, wird vom Synchroni­sation Master das gesamte Gebernetzwerk angehalten.

Tritt der schwere Fehler beim Austausch der Geberdaten auf (8333 "EncoderNet Datenempfang nicht möglich"), bleibt das Gebernetzwerk synchron und es müssen nach einer Fehlerquittierung nur die Synchronisationsgeber wieder anfangen, ihre Geberdaten zu verteilen.

Handelt es sich aber um einen schweren Synchronisationsfehler (8335 "EncoderNet Sync. nicht möglich"), so muss das Gebernetzwerk wieder neu aufgebaut (konfiguriert und synchronisiert) werden.

Bevor ein schwerer Fehler ausgelöst wird, wird zuerst ein einfacher Fehler als Benachrichtigung ausgegeben. Das Gebernetzwerk bleibt bei diesen Warnungen weiterhin aktiv. Bei einem Fehler bezüglich der Synchronisation wird eine Benachrichtigung ausgegeben, wenn die Hälfte der eingestellten Zyklen erreicht wurde und noch kein neues Telegramm empfangen wurde (8336 „EncoderNet Sync. Störung erkannt“).

Bei dem Austausch der Geberdaten wird eine Warnung schon dann ausgegeben, wenn ein einziges Telegramm nicht empfangen wird (8334 "EncoderNet Datenempfang Störung erkannt").

Systemanforderungen

Hardware

oPacDrive Steuerung

oVollduplex, 100 MBit Ethernet-Verbindung mit (verwaltetem) Switch

Architectures

Nachfolgend werden an einigen Beispielen mögliche Architekturen vorgestellt. Die Beispiele bestehen aus jeweils zwei Abbildungen. Die erste Abbildung zeigt die Controller und die „Geberverbindungen“. Die zweite Abbildung stellt die Konfiguration als Blockschaltbild mit mehr Details dar.

Einfache Geberverbindung zwischen zwei Steuerungen

 

 

Blockschaltbild einfache Geberverbindung zwischen zwei Steuerungen

 

 

Die einfachste Konfiguration besteht aus zwei Controllern mit einer Geberverbindung zwischen den beiden Teilnehmern. Der Synchronisation Master überträgt das Ausgangssignal EncoderOut1 an die Steuerung „Synchronisation Slave“ als ein Signal für Eingang EncoderIn1. Gleichzeitig wird EncoderOut1 an den Eingang EncoderIn1 am Synchronisation Master zurückgeführt. Beide Geräte können damit auf die gleichen synchronisierten Geberdaten zugreifen. Die Parametrierung, Uhrensynchronisation und Prüfung des Gebernetzwerkes wird vom Synchroni­sation Master koordiniert bzw. durchgeführt.

Ein möglicher Einsatzfall für diese Konfiguration wäre etwa eine Produktionsmaschine (z.B. Blistermaschine) mit angeschlossener Verpackungsmaschine (z.B. Kartonierer).

Geberverbindung zwischen mehr als zwei Steuerungen mit einer Geberdatenquelle

 

 

Blockschaltbild einer Geberverbindung zwischen mehr als zwei Steuerungen mit einer Geberdatenquelle.

 

 

Das Beispiel zeigt drei Controller. Das Signal EncoderOut1 des Synchronisation Master wird an die Controller SyncSlave1 und SyncSlave2 verteilt und gleichzeitig an den Synchronisation Master zurückgeführt. Die drei Geräte können damit auf die gleichen synchronisierten Geberdaten zugreifen. Auf diese Weise sind zwei Anwendungsfälle möglich.

Als erste Variante kann man den Ausgang EncoderOut1 als virtuelle Königswelle für die drei Maschinen verwenden (z. B.: Zuliefermaschine, Produktionsmaschine, Verpackungsmaschine). Die zweite Möglichkeit ist, zwei Maschinen als Folgemaschine des Masters (z. B. Produktionsma­schine mit zwei Verpackungsmaschinen) zu betreiben. Hierbei ist die Rückführung des Gebersignals von EncoderOut1 auf EncoderIn1 am Synchronisation Master eventuell sogar überflüssig.

Einschränkungen

Verzögerungen aufgrund der Ethernet Schnittstelle

Da die Übertragung der Geberdaten über eine Standard-Ethernet Schnittstelle erfolgt, ist es möglich, dass einzelne Telegramme um mehrere Millisekunden verzögert werden oder sogar bei der Übertragung zerstört werden. Diese Faktoren lassen sich jedoch durch eine entsprechende Ethernet Infrastruktur beeinflussen.

Folgende Punkte sollten dabei unbedingt erfüllt werden:

oAnschluss der beteiligten Steuerungen an einen 100 Mbit/s Vollduplex-Switch.

oVerwendung von geschirmten Ethernet-Kabeln je nach Umgebung (mind. CAT5).

oMinimierung der Netzwerkbelastung durch Kommunikation, die nicht mit der Synchronisation in Verbindung steht (vor allem Broadcasts).

Weiterhin können auch folgende Maßnahmen bei Synchronisationsprob-lemen sinnvoll sein:

oEinsatz eines Managed Switch, der VLAN und die Priorisierung von Telegrammen beherrscht, da die Synchronisationstelegramme auf höchste Priorität eingestellt sind.

oIsolation des Netzes (keine direkte Verbindung zum restlichen Firmennetz).

Um diese Kommunikationseinflüsse und Verzögerungen zu kompensieren, wurde für die Verwendung der Geberdaten eine Verzögerung eingebaut, die über den Parameter DataDelay des Sync. Encoder output bestimmt werden kann.

Vorgaben für Zykluszeiten

Um eine aufwändige Interpolation von Geberdaten zu vermeiden, wurde für die beteiligten Steuerungen vorausgesetzt, dass sie die gleiche Sercos-Zykluszeit eingestellt haben. Dies ist nötig, da die Zykluszeiten für Synchronisation und Geberdatenaustausch fest auf die Sercos-Zykluszeit eingestellt sind.

Beispiel: „Verteilte Königswelle”

Im folgenden Beispiel soll eine Maschinenkonfiguration aufgezeigt werden, bei der eine virtuelle Königswelle an die beteiligten Slave-Steuerungen verteilt wird. Zur Vereinfachung werden nur zwei Controller (ein Synchronisation Master und ein Synchronisation Slave) verwendet, aber es können auch mehrere Synchronisation Slave auf gleiche Weise verwendet werden.

Für den Synchronisation Master wird hierbei ein virtueller Mastergeber verwendet, der eine verteilte Königswelle darstellt. Diese wird bei der Initialisierung des Systems mit folgendem Befehl aufgerufen: SetMasterEncoder(_SyncDataOut ,_VMEnc);

aufgerufen. Als lokale Königswelle müssen dann alle Steuerungen (Synchronisation Master und Synchronisation Slave) des Sync. encoder input verwendet werden.

Beispiel:

SetMasterEncoder(_LEnc, _SyncDataIn); 

Um dieses Beispiel zu realisieren müssen also auf der Synchronisation Master-Steuerung folgende Objekte eingefügt werden:

oLeitgeber virtuell (VMEnc)

oSynchronisation Master (SyncMaster)

oSync. Modul- (SyncModule_1)

oSync. Geberausgang (SyncDataOut)

oSync. Gebereingang (SyncDataIn)

Bei der Synchronisation Slave-Steuerung sind folgende Objekte erforderlich:

oSynchronization slave (Synchronisation Slave)

oSync. Encoder Input (SyncDataIn)

Die Konfiguration für dieses Beispiel ist relativ einfach, da bei den Parametern die Standardwerte verwendet werden. Die Auswirkungen der Standardwerte sind in der Tabelle ersichtlich.

Es müssen nur die folgenden beiden Parameter im Sync. Module (SyncModule_1):

oSyncModule_1.Enable = True

oSyncModule_1.SlaveIPAdress = <IP-Adresse der Synchronisation Slave-Steuerung>

Wenn das Beispiel auch mit einer Sercos cycle time von 4 ms arbeiten muss, dann muss der Parameter SyncModule_1 SlaveCycleTime zusätzlich auf 8 ms oder 12 ms geändert werden, da die Zykluszeit des Synchronisatios-Slaves ein Vielfaches der Sercos-Zykluszeit sein muss.

Um die Synchronisation zu starten, müssen dann nur noch die Enable-Parameter von Synchroni­sation Slave und Synchronisation Master auf TRUE gesetzt werden. Sobald der Parameter State des Synchronisation Slave und des Synchronisation Master auf „5 / aktiv“ wechselt, steht die Synchronisation und das Gebernetzwerk ist betriebsbereit.

Auswirkungen der CycleTime- und Limit-Parameter

Beispiel: „Kopplung an eine reale Achse“

In diesem Beispiel wird eine Kopplung zweier Maschinen über das Gebernetzwerk beschrieben, bei der die Synchronisation Slave-Steuerung einer realen Achse des Synchronisation Master folgen soll.

Es gelten daher folgende Ziele:

oSchnelle Rückmeldung von Fehlern

oMöglichst kleiner Zwischenpuffer für Telegramme

Hierzu sind die gleichen Voraussetzungen wie im ersten Beispiel nötig. Allerdings kann der virtuelle Mastergeber (VMEnc) entfallen, da dieser durch eine reale Achse ersetzt wird. In diesem Fall wird die Verbindung zwischen Achse und Sync. Geberausgang durch den Befehl SetMasterEncoder(_SyncDataOut,_Axis) herstellt.

Außerdem kann der Sync. Gebereingang am Synchronisation Master entfallen, da das Gebersignal beim Synchronisation Master nicht mehr benötigt wird.

Weiterhin müssen einige Parameter angepasst werden, um die neuen Ziele zu erreichen:

Da die Statusmeldung des Synchronisation Slave im ersten Beispiel relativ langsam erfolgt ist, muss für eine schnelle Reaktion im Falle eines Fehlers die Zykluszeit der Slave-Telegramme (SyncModule_1.SlaveCycleTime = Sercos-Zykluszeit (1, 2 ms oder 4 ms)) reduziert werden. aus diesem Grund muss die Fehlergrenze angehoben werden, um auftretende Telegramm-Verzögerungen zu kompensieren (SyncModule_1.SlaveCycleErrorLimit = 20 Zyklen).

Die bidirektionale Kommunikation zwischen Synchronisation Master und Synchronisation Slave erfolgt nun mit der gleichen Geschwindigkeit in beide Richtungen. Es muss allerdings beachtet werden, dass hierdurch die Belastung der Ethernet-Kommunikation steigt und somit evtl. weniger Steuerungen als Synchronisation Slave verwendet werden können.

Um das primäre Ziel, eine möglichst geringe Verzögerung zwischen Synchronisation Master und Synchronisation Slave, zu erreichen, wird der Parameter SyncDataOut.DataDelay auf einen Zyklus herabgesetzt. Diese geringe Verzögerung sollte aber auch durch eine höhere Fehlerto­leranz ausgeglichen werden. Dazu muss der Sync. encoder input am Synchronisation Slave für den Parameter SyncDataIn.DataCycleErrorLimit auf 10 Zyklen erhöht werden.

Da bei den Sync. encoder inputs die Warnung für einen Telegramm-Empfangsfehler schon beim ersten fehlenden Telegramm ausgegeben wird, ist es hier eventuell notwendig, die Diagnosereaktion der Diagnosemeldung 334 „Fehler beim Encoderdaten-Empfang (Warnung)“ auf die Diagnoseklasse 8 zu setzen und somit nur im message logger einzutragen. Dies ist mit folgendem Befehl möglich: FC_DiagConfigSet(334,8);

Auswirkungen der CycleTime- und Limit-Parameter