Mechatronik für Aufzugsmonteure und Antriebstechniker, Teil 18 Götz Benczek / Axel Wolfram / Viktor Baumung (Dietz-electronic GmbH) Bus-Systeme im Aufzugsbau, Einführung in ein komplexes Thema Bus-Systeme erfreuen sich auch im Aufzugsbereich zunehmender Beliebtheit. Wobei zwischen der Vernetzung einzelner Komponenten im Aufzug und einer übergeordneten Gebäudeleittechnik unterschieden werden muss. Die Anbindung an eine eventuell vorhandene Gebäudeleitzentrale z. B. per Ethernet, LON- oder CAN-Bus soll hier nicht erklärt werden. Es soll hier in erster Linie um die Anbindung der Antriebstechnik an die Liftsteuerung gehen. Hierzu stellen wir uns zunächst einmal die Frage, wann ein Bus-System innerhalb der Antriebstechnik einen Sinn macht und welche Vorteile sich dabei für den Anwender ergeben. Des weiteren wird es sinnvoll sein, einige Grundlagen zu den etablierten Bus-Systemen zu bekommen, sowie die historischen Hintergründe zu kennen. Grundsätzlich bedeutet das Vorhandensein eines Bus-Systems zunächst einmal einen technologischen Mehraufwand. Bild 169 zeigt ein typische Options-Karte mit autarkem Prozessorkern, der die gängigen Bus-Systeme DCP, ACP und CAN an Frequenzumrichter (für Aufzüge) anbinden kann. Auf dem Bild sind auch zwei typische Bus-Kabel zu sehen.

Gute Gründe für den Einsatz der gängigsten Protokolle (DCP_03, ACP_03, CAN-DSP417) ist der Einsatz dezentraler Antriebe mit einem beliebigen Standort der Aufzugssteuerung. Typisch für ‚Roomless-Antriebe’ ist eine Bus-Anbindung laut Bild 172. In dem Bild 171 ist ein modernes Antriebskonzept gezeigt, bei welchem eine Gearless-Winde zusammen

mit dem Frequenzumrichter und allen Schützen im Schachtkopf sitzt. Die Steuerung in Bild 170 befindet sich dagegen in einer beliebigen Haltestelle neben einer Aufzugstür.

(Bild 171)

(Bild 170) (Bild 172) Hier ist das Bus-System deshalb sinnvoll, da es dem Monteur erstmalig möglich ist, alle Aufzugs-Einstellungen bequem an der (leicht zugänglichen) Steuerung zu machen. Er muss nicht mehr in den Schachkopf klettern, um einen Umrichter-Parameter zu ändern.

Im nächsten Schritt wollen wir die Bus-Systeme auf der Basis DCP / ACP / CANopen erklären, wobei folgende Begriffe wichtig sind (Auszug aus dem VDMA-Einheitsblatt): DCP Drive Control Position, das DCP-Protokoll basiert auf den

Empfehlungen einer Arbeitsgruppe ACP Advance Control Position, erweitertes Protokoll basierend auf dem

DCP-Protokoll CAN Controller Area Network, Das CAN-Protokoll ist im ISO 1189-1 international genormt. CANopen Höheres Protokoll basierend auf dem CAN-Bus CiA CAN in Automation, Non-Profit Organisation, welche die auf CAN basierenden höheren Protokolle normt. CiA-DSP-417 CANopen-Applikationsprofil für Aufzüge ISO Internationale Standardisierungs-Organisation OSI-Referenzmodel Open System Interconnection, normt den Aufbau aller technischen Kommunikationssysteme. Besteht aus 7 Schichten die aufeinander aufbauen. Hardware (empfohlene Steckerbelegung auf einer Bus-Optionskarte bzw. am Umrichter): Vollbelegung / Minimalbelegung Anschlüsse zur seriellen Ansteuerung: (Bild 174 SUB-D-9-f) RS 232 mit RS485/422 SUB-D9 i/o-Signal Funktion Anmerkung

1 Tx-A (485) Anschluss A der RS 485 Pin 1 gebrückt mit Pin 7 2 RXD (232) Read von RS 232 nur bei RS 232 3 TXD (232) Sent von RS 232 nur bei RS 232 4 Tx-B (485) Anschluss B der RS 485 Pin 4 gebrückt mit Pin 6 5 GND (3. Leitung auch bei RS485 empfohlen) für alle Schnittstellen 6 Rx-B (422) normalerweise bei RS485 interne Brücke nur bei RS 422 7 Rx-A (422) normalerweise bei RS485 interne Brücke nur bei RS 422 8 n. c. reserviert 9 +5V Versorgung für ev. externes Terminal optional

case shield (PE) Schirm bei RS232 Vollbelegung / Minimalbelegung Anschlüsse zur seriellen Ansteuerung: (Bild 173 SUB-D-9-m) LiftCAN und CANopen SUB-D9 i/o-Signal Funktion Anmerkung

1 n. c. reserviert 2 CAN_L CAN-low 3 CAN_GND (3. Leitung auch bei CAN empfohlen) 4 n. c. reserviert 5 CANshield Auflegepunkt für Schirm 6 GNDoption Bezugspunkt für Hilfsversorgung (+5V) optional 7 CAN_H CAN-high 8 n. c. reserviert 9 +5V Hilfsversorgung für eventuelle Koppler optional

case shield (PE) alternativer Auflegepunkt für Schirm

(Bild 174, ACP-DCP SUB-D-9-f) (Bild 173, CAN SUB-D9-m)

Historie der Bus-Systeme im Aufzug (hier Bereich ‚Lift-Steuerung zu Antriebseinheit’): Das erste frei und serienmäßig für den Aufzugsbereich verfügbare Bus-System zwischen Steuerung und Antriebeseinheit nennt sich DCP (von Böhnke+Partner) und startet seine Etablierung mit DCP_01- und DCP_02-Protokollen, welche mit 19200 Baud übertragen werden. Die Steuerung kann erstmalig Fahrbefehle an den Umrichter auf der Basis einer RS-485-Schnittstelle senden und umgekehrt Fehlermeldungen aus dem Antrieb erhalten.

Wie im Bild 175 zu sehen ist, ergibt sich bei DCP_01/_02 ein Übertragungszyklus von ca. 10 ms, was bei schnelleren Aufzugsanlagen Abweichungen in der Bündigfahrt zur Folge haben kann. Daher wird bei den neueren Protokollen DCP_03/_04 bereits mit 38400 Baud übertragen. Im Gegensatz zu DCP_01/_02 arbeitet DCP_03/_04 mit 6 Byte statt 5 Byte, was den Zyklus auf 8,12 ms verkürzt. Weiterhin können erstmalig auch Parameter und Variablen des Umrichters durch einfache Simulation des Bedienteils von der Steuerung aus übergeben werden. Das DCP_03 wird damit das gebräuchlichste Bus-Protokoll zum Umrichter. Bild 176 zeigt uns den Übertragungszyklus bei DCP_03/_04.

Im DCP-Protokoll fehlt leider die Möglichkeit, bei vorhandener Magnetkopierung über die Inkremente des Motor-Drehgebers eine digitale Schachtkopierung zu simulieren. Diese Möglichkeit wurde erst mit dem ACP-Protokoll (Newlift) geschaffen. Bei ACP wurde auf dem DCP aufgesetzt, somit ergibt sich eine Funktionskompatibilität zu DCP_01 bis _04. Die maximale Übertragungsgeschwindigkeit ist bei allen ACP-Protokollen auf 500 kBaud festgelegt. Die maximale Zykluszeit für ein komplettes Telegramm beträgt demnach nur 0,8 ms. Zusätzlich wird nun auch die Information aus dem Motor-Drehgeber mit an die Steuerung übertragen. ACP kann auch bei Hochgeschwindigkeits-Aufzügen problemlos angewendet werden, ohne dass es zu störenden Schwankungen im Schleichweg kommt.

Bild 177 zeigt den für ACP_01 bis _04 typische Übertragungszyklus bei typ. 500 kBaud. Wir werden in späteren Berichten die Details zu DCP und ACP noch eingehend erklären. Das CAN-System ist ein weiterer neuer Lösungsansatz für Bus-Systeme im Aufzug. Es hat gegenüber dem DCP und ACP den Vorteil, dass sich innerhalb einer gemeinsamen Bus-Architektur weitere Komponenten (Schachtgeber, Türantrieb, Lichtgitter, Rufe usw.) mit einbinden lassen. In der Theorie könnte jeder Teilnehmer einem anderen Teilnehmer im Bus seinen Status bzw. einen Befehl mitteilen. In der Praxis wird man jedoch diese Möglichkeit einschränken müssen (die Steuerung muss aus Sicherheitsgründen stets der ‚Master’ im Bus bleiben). Zudem ist der zeitkritische (schnelle) CAN-Knoten z. B. zum Umrichter und Schachtgeber nicht geeignet, noch weitere Teilnehmer (z. B. Rufe) mit aufzunehmen. Für Rufe, Lichtgitter usw. wird ein eigener (langsamer) Knoten gebraucht.

CAN (Controller-Area-Network), Historie und ein erster Einblick in den CAN-Bus: Die moderne Automatisierungstechnik ist durch eine zunehmende Dezentralisierung von Verarbeitungsfunktionen gekennzeichnet. Der Einsatz von Feldbussystemen ermöglicht dabei eine Erhöhung der Flexibilität bzgl. Änderungen und Erweiterungen und eröffnet ein erhebliches Einsparungspotenzial hinsichtlich Projektierungs- und Installationskosten.

Zu den erfolgreichen Feldbussystemen gehören CANopen und DeviceNet. Die beide basieren sich auf dem Controller-Area-Network-Protokoll (CAN), das von der Firma BOSCH im Jahre 1983 definierte wurde.

Das CAN-Protokoll beschreibt lediglich die Schichten 1 (Übertragungsschicht) und 2 (Verbindungsschicht) des OSI-Referenzmodells und bietet zahlreiche Einsatzmöglichkeiten für die unterschiedlichsten Anwendungsbereiche. Unterschiedliche Anforderungen an die Bustechnologie haben zu verschiedenen Arten der CAN-Implementationen geführt. Unterschieden werden CAN 2.0A und CAN 2.0B, BasicCAN und FullCAN, sowie Low-Speed- und High-Speed-Netze. Praktisch alle Hersteller von Mikrocontrollern bieten heute Lösungen mit integrierter CAN-Schnittstelle für diese vielseitige Anforderungen an. Zu den wichtigsten Leistungsmerkmalen und Eigenschaften des von ISO standardisierten CAN-Protokolls zählen:

- Bustopologie, Datenrate, Anzahl von Teilnehmer - Nachrichtenorientiertes Protokoll - Priorisierung von Nachrichten - Multi-Master-Fähigkeit - Verlustlose Bus-Arbitrierung - Kurze Blocklänge - Hohe Sicherheit der Datenübertragung bei sehr kurzer

Fehlererholzeit - Netzweite Datenkonsistenz - Erkennung und Abschaltung defekter Teilnehmer - Geringe Latenzzeit für hochpriore Nachrichten - Standardisierung - Kostengünstige Protokollimplementierung - CAN-Anwendungsvereinigung

CAN arbeitet standardmäßig mit einer linienförmigen Topologie. Dabei ist die Netzausdehnung durch die Signallaufzeit auf etwa 40 m bei 1 MBaud oder 1 km bei 80 kBaud eingeschränkt. Über Repeater oder Router sind baumartige und hierarchische Netzstrukturen möglich. Es gibt keine im Protokoll festgelegte Höchstgrenze für die Anzahl der Busteilnehmer, in der Praxis wird diese allerdings durch die Leistungsfähigkeit der Bustreiber beschränkt. Je nach Bustyp gibt es für die Anzahl der Busteilnehmer verschieden definierte Mindestwerte. Die ISO hat für die Unterscheidung zwischen Nieder- und Hochgeschwindigkeitsnetzen eine simple Festlegung getroffen und die Grenze auf 125 kBit/s festgelegt. [Beitrag wird fortgesetzt]

19.11.2004 Götz Benczek (für die Liftreport Ausgabe 01/2005)!

Mechatronik für Aufzugsmonteure und Antriebstechniker, Teil 18a Götz Benczek / Viktor Baumung (Dietz-electronic GmbH) CAN (Controller-Area-Network), Einblicke in den CAN-Bus im Aufzugsbau: Die Leistungseigenschaften des CAN-Protokolls im Zusammenhang mit geringerem Material-Verbrauch machen den CAN-Bus für den Aufzugsbereich sehr interessant. Im Vergleich zu anderen Systemen lassen sich mit CAN auch Inbetriebnahme- und Wartungskosten minimieren. Wie auf dem Bild 183 zu erkennen ist, könnten komplett alle Geräte eines Aufzugs an einem gemeinsamen CAN-Bus angeschlossen werden.

Auf diesem Bild sind jedoch nicht nur die Vorteile des gesamten Aufbaus zu sehen, sondern es stellen sich auch viele Fragen: ’Wie ist dies alles zu verwalten?’, ’Werden die Geräte überhaupt erkannt?’ ’Wie werden die Geräte automatisch erkannt?’ ’Wie und in welcher Reihenfolge kommunizieren die einzelnen Geräte miteinander?’ Die Lösung heißt: ’CANopen’. CANopen ist ein Kommunikationsprotokoll unter CAN, so wie z. B. FTP und HTTP beim Ethernet mögliche Kommunikationsprotokolle darstellen. CANopen ist also ein Kommunikationsprotokoll das der Anwendungsschicht entspricht. In der Praxis stellen wir uns die Komponenten einer Aufzugsanlage vor: Zuerst müssen wir einzelne Geräte definieren (Sensoren, Geber, programmierbare Steuerungen, usw.). Dafür definiert CANopen nun virtuelle Geräte (Funktionen), welche in ’physikalischen’ Geräten implementiert werden können: So könnte ein Positions-Geber zusätzlich einen Temperatur-Sensor enthalten. Das reale Gerät wird im CAN-Bus dann als zwei virtuelle Geräte dargestellt.

Diese Unabhängigkeit von konkreten physikalischen Geräten gibt dem gesamten System sehr hohe Flexibilität und eine weitgehende Hersteller-Unabhängigkeit. In sogenannten Geräteprofilen werden sowohl die Funktionalität, als auch die Parameter von Standardgeräten des jeweiligen Typs festgelegt. Auf der Grundlage derartig standardisierten Profile kann auf identische Art und Weise über den Bus auf ’CANopen-fähige’ Geräte zugegriffen werden. Für den Aufzug sind folgende Virtuelle Geräte vorgesehen:

- Call controller - Input panel unit - Output panel unit - Car door controller - Car door unit - Car position unit - Light barrier unit - Car drive controller - Car drive unit - Load measuring unit - Sensor unit

Im CANopen ist die Beschreibung der Gerätefunktionalität über ein ’Objektverzeichnis ’ realisiert. Das Objektverzeichnis ist unterteilt in einen Bereich, welcher allgemeine Angaben über das Gerät, wie die Geräteidentifikation, den Herstellername, etc., sowie Kommunikationsparameter enthält. Zusätzlich gibt es noch einen Teil, der die spezifische Gerätefunktionalität selbst beschreibt. Zur eindeutigen Beschreibung von ’Objekten’ werden ein 16-Bit Index und ein 8-Bit Sub-Index vergeben. Über die Einträge des Objektverzeichnisses werden die ’Anwendungsobjekte’ eines Gerätes (z. B. die Netzwerkvariablen, Geräteparameter oder Gerätefunktionen) in standardisierter Form über das Netzwerk zugänglich gemacht. Wenn z.B. ein Objekt mit dem Index ’6400’ und dem Sub-Index ’00’ angefordert wird, dann wird vom virtuellen Device ’Car drive unit’ eine 16-Bit Variable mit dem aktuellen Status dieses Gerätes auf den CAN-Bus gesendet. Wird ein zweites Objekt mit dem Index ’6433’ und Subindex ’00’ gewählt, dann wird vom selben Gerät eine 32-Bit Variable mit dem aktuellen Geschwindigkeitswert des Aufzuges gesendet. An dieser Stelle können wir für die entsprechende Anlage Geräte zusammenstellen und uns anschließend noch Gedanken bezüglich des Kommunikationsverfahrens machen: Für diese wichtige Aufgabe ist beim CANopen das Kommunikationsprofil verantwortlich. Wie bei allen anderen Feldbus-Protokollen auch, werden hierbei die Echtzeitdaten Von den Parameterdaten unterschieden. CANopen ordnet diesen vom Charakter her völlig unterschiedlichen Datenarten jeweils passende Kommunikationselemente zu:

- Network Managment Object (NMO) o Boot-Up o Life/Node-Guarding o Error Control Protocol

- Special Function Object (SFO)

o Synchronization (SYNC) o Time Stamp o Em ergency (EM CY) Protocol

- Process Data Object (PDO) - Service Data Object (SDO)

Bevor wir die Kommunikationsobjekte detaillierter untersuchen, werfen wir ein Blick auf das Bild 179 mit dem Gerätemodul:

Auf der rechten Seite steht der Anwendungs-Prozess, der die Geräteaufgaben meistert. Das Objektverzeichnis bietet einen streng reglamentierten Buffer von Daten mit zwei Schnittstellen: Zum Anwendungs-Prozess und zum Kommunikationsinterface. Wie so ein Informationsaustausch funktioniert, konnten wir schon an zwei kleinen Beispielen sehen. Im Prinzip besteht für das Kommunikationsinterface die Aufgabe, Daten in Datenpakete zu packen und auf den CAN-Bus zu anderen Teilnehmern zu senden, die Datenpakete zu empfangen, wieder zu entpacken und an das bestimmte Objekt danach zu übergeben. Wieso enthält dann das Kommunikationsinterface mehrere kommunikationsverfahren? Das hat mehrere Gründe: Zuerst einmal haben wir eine ganze Reihe von unterschiedlichen Daten (Parametrierungsdaten, Echtzeitdaten, usw.), die an unterschiedlichen Stellen und mit unterschiedlichen Prioritäten ausgeführt und empfangen werden müssen. Zudem unterscheidet sich CANopen von anderen Protokollformen durch hohe Leistungsfähigkeit und gilt als extrem sicheres Protokoll. Dies wird durch die Implementierung von bestimmten Mechanismen / Technologien erreicht (NMT State Maschine, Synchronisationsverfahren, Fehlererkennungsverfahren, usw.). Die Kommunikationsobjekte sind durch die sogenannten COB-Id’s mit 11 Bits eindeutig zugeordnet. Die Zuordnung der CAN-Nachrichten-Identifiers ist durch direktes Eintragen von Identifiern in die entsprechenden Datenstrukturen des Objektverzeichnisses möglich oder für einfache Systemstrukturen durch Verwendung von vordefinierten Identifiern, wie es im Tabelle 180 (Broadcast) und in Tabelle 181 (Peer-to-Peer) hier dargestellt ist:

Wenn wir verstehen möchten, wie die einzelnen Kommunikationselemente aufgebaut sind und wie sie funktionieren, müssen wir ein kleinen Exkurs zum strukturellen Aufbau des CAN-Protokolls machen. Wie wir wissen, gibt es derzeit auf dem Markt zwei aktuelle CAN Versionen: CAN 2.0A und CAN 2.0B (ob später weitere Versionen folgen, ist unwichtig). Der wichtigste Unterschied zwischen diese beiden Versionen ist durch die Größe der Identifier gekennzeichnet: CAN 2.0A hat 11-Bit-Identifier und CAN 2.0B aber 29-Bit. CANopen funktioniert mit beiden Versionen, deswegen sehen wir uns nur den Frame des CAN 2.0A an, der in Bild 182 gezeichnet ist (Standard-Frame):

Die im Text erwähnten COB-IDs werden als Identifier für jene CAN-Frames versendet. [Beitrag wird fortgesetzt]

17.01.2005 Götz Benczek (für die Liftreport Ausgabe 02/2005)!

Mechatronik für Aufzugsmonteure und Antriebstechniker, Teil 18b Götz Benczek / Viktor Baumung (Dietz-electronic GmbH) CAN (Controller-Area-Network), Velocity-Mode, DCP_04, Position-Mode: Unter CANopen, wie wir schon angedeutet haben, können praktisch alle Geräte der Aufzugsanlage durch einen gemeinsamen BUS bedient werden. Das macht CANopen für den Aufzugsbereich besonders attraktiv. Die Spezifikationen dafür sind in der DSP-417 des Cia-Komitee beschrieben. Wir haben uns den Frame-Aufbau von CAN-2.0A angeschaut und wissen bereits, dass die ersten 11 Identifier-Bits die COB-ID der CANopen-Nachricht spiegeln. Hierdurch wird der Inhalt vom Daten-Feld (bis 8 Data-Byts) bestimmt. An dieser Stelle interessieren uns nur diese Felder: Nachrichten-Identifier und Daten-Feld. Jeder CANopen-Objekt-Type verfügt über bestimmte Regeln zum Aufbau des Data-Feldes. Diese Regeln werden durch die Aufgaben von Objekten bestimmt. Betrachten wir noch einmal eine reale Situation mit drei CANopen – Geräten. Wir haben schon allgemeinen den internen Geräteaufbau angesprochen: Anwendungs-Prozess, Objektverzeichnis und Kommunikationsinterface:

Das Bild 184 zeigt die Implementierung unserer drei CANopen Geräte am CAN-Bus. Jedes Gäret verfügt über Informationen, die im Anwendungs-Prozess gewonnen werden und die auch für andere Teilnehmer (am CAN-Bus) von Bedeutung sind. Dies geschieht durch die Objektverzeichnis-Schnittstelle mit Hilfe des Nachrichten-Dienstes, so das jeder Teilnehmer die Information bekommt, die er braucht und auch wann er diese braucht. Bei der Lösung dieser Aufgabe sind Dienstdatenobjekte (SDOs) und Prozessdatenobjekte (PDOs) als Nachrichtenarten entstanden. Über Dienstdatenobjekte erfolgt der bestätigte Transfer von Daten beliebiger Länge zwischen zwei Netzteilnehmern. Der Datentransfer von einem Teilnehmer zu einem anderen Teilnehmer wird im Client-Server-Modell beschrieben. Der SDO-Client ist immer der Initiator der SDO-Verbindung. Wenn der SDO-Client Information vom SDO-Server benötigt, dann sendet er eine SDO an den Server mit entsprechender Anforderung. Die Art dieser Anforderung wird durch die einzelnen Bits des ersten Bytes (Comand-Byte genant) des Data-Feldes festgelegt. Die folgenden Bytes des Data-Feldes tragen zusätzliche Informationen, z.B. Index und Sub-Index des benötigten Objektes. Der SDO-Server interpretiert die Data-Bytes und sendet an den Client die entsprechende Information - die auch gleichzeitig als Kommunikationsbestätigung gilt - dann zurück. Auf gleiche Weise kann der Client im ersten Data-Byte dem Server mitteilen, dass die Informationen für den Server vorgesehen sind. Dann übernimmt der Server diese Daten und sendet eine Bestätigung zurück. Diese Kommunikation wird über verkürzte SDO UP-und Download-Protokolle beschrieben. Auf diese Weise kann auch z.B. die Fahrmethode (Geschwindigkeits- oder Positions-Verfahren) vor der Aufzugsfahrt festgelegt werden!

Das Bild 185 zeigt ein verkürztes (expedited) SDO UP- und Download-Protokoll Für größere Datenmengen sind ’Segmentierte’ SDO UP- und Download-Protokolle definiert:

Das Bild 186 zeigt ein segmentiertes SDO Download-Protokoll. Die Übertragung wird durch eine Initiate-Download-Sequenz für einen segmentierten Datentransfer eingeleitet. Anschließend erfolgt die segmentweise Übertragung der Daten. Wenn ein CANopen-Gerät in ein System integriert wird, bedeutet das, dass seine Dienste von anderen Mitgliedern benötigt werden. Deswegen muss dieses Gerät auch für die Datenmitteilung mindestens einen SDO-Server haben. Ein Impulsgeber z. B. wird die Daten der Geschwindigkeit zur Verfügung stellen, und die Tür-Sensoren z. B. ihren entsprechende Zustand. Wie wir schon angedeutet haben, sind die SDOs vor allem für die Konfigurationsphase gedacht, die beim Gerätestart stattfindet. Aus diesem Grund wurde die Transfertechnik mit Bestätigung gewählt. Im vergleich zu PDOs verfügen die Dienstobjekte über etwas niedrigere Prioritäten. Die eigentlichen ’Transportmittel’ für die Übertragung von Prozeßdaten stellen die Prozeßdatenobjekte dar. Dieses Model wird über ’Producer’ und ’Consumer’ beschrieben. Eine PDO wird von einem ’Producer’ gesendet und kann von einem oder mehreren ’Consumern’ empfangen werden. Die von einem PDO-Producer gesendeten Daten können dabei maximal 8 Byte umfassen. Die Übertragung einer PDO erfolgt unbestätigt und erfordert eine, der PDO eindeutig zugeordneten COB-ID. Die Bedeutung der hierbei übertragenen Daten wird durch den verwendeten COB-ID, sowie dem einer PDO zugeordneten ’PDO-Mapping’ festgelegt. Da die Identifizierung einer PDO implizit über den Nachrichtenidentifier erfolgt und die Übertragung auf maximal 8 Bytes begrenzt ist, erfolgt die Übertragung von PDOs damit ohne einen zusätzlichen Protokoll-Overhead:

Das Bild 187 zeigt das ’Write-PDO-Protokoll’. Das Senden einer PDO durch einen PDO-Producer kann auch durch einen PDO-Consumer veranlasst werden. Hierzu fordert dieser mittels einer Datenanforderungsnachricht (’Remote Transmission Request’) - unter dem Nachrichtenidentifier der angeforderten PDO - den zuständigen PDO-Producer zum Senden der entsprechenden PDO auf. Diese kann auch von mehreren PDO-Consumern übernommen werden:

Das Bild 188 zeigt das ’Read-PDO-Protokoll’. Für die Verwaltung von PDOs benötigen sowohl PDO-Producer als auch PDO-Consumer entsprechende Datenstrukturen. Die von einem PDO-Producer benötigten Daten werden von diesem in Form von ’TXT-PDO’-Datenstrukturen, die von einem PDO-Consumer zu empfangenden Daten in Form von’RX-PDO’-Datenstrukturen verwaltet. Eine PDO kann bis 8 Data-Bytes übertragen. Damit ist es möglich mehrere Geräteparameter, -daten und –funktionen in so einem PDO nach bestimmter Anordnungsfestlegung zu übertragen. Diese Festlegung wird auch als ’PDO-Mapping’ bezeichnet. Das läst sich am besten an einem Beispiel zu erklären:

Nach DSP417 haben wir eine Vordefinierte TX-PDO mit COB-ID 185. Für die Consumer bedeutet das, dass diese PDO im 6-Byte Data-Feld zwei Daten transferiert: Die erste zwei Bytes gehören der Statusword-Variable (Index 6401h, Sub-Index 00h), die weitere vier Bytes gehören einem Objekt mit Index 6433h, Sub-Index 00h (Velocity actual value).

Der Consumer weiß also automatisch, wie er die PDOs auspacken muss und wie er mit dieser Information weiter umzugehen hat. Nach diesem Verfahren kann man nun den Bearbeitungscode maximal optimieren. Damit auch die CANopen-Geräte miteinander reibungslos kommunizieren können, wurde das Netzwerkmanagement (NMT) mit zwei Gruppen von Diensten und zugehörigen Protokollen entwickelt: - Fehlerüberwachung

Fehlerüberwachungsdienste ermöglichen die kontinuierliche Überwachung des Kommunikationszustandes von Knoten. Zwei unterschiedliche Methoden (Node-Guarding und Hearbeat-Nachrichten) stehen zur Verfügung.

- Knotensteuerung Dienste der Knotensteuerung werden für die Initialisierung der Knoten, die an einer verteilten Anwendung teilnehmen möchten, verwendet. Diese Dienste ermöglichen neben der Steuerung eines einzelnen Knotens auch die gleichzeitige Steuerung des Kommunikationszustandes aller Knoten.

Betrachten wir zuerst einmal das NMT-Model:

Das Bild 189 beschreibt das NMT-Model. Im NMT-Model kommunizieren NMT-Slaves nur mit dem NMT-Master. Zur Sicherstellung der Funktionalität von CANopen-Knoten sind zwei optionale Überwachungsmechanismen vorgesehen: Das zyklisches Polling durch den NMT-Master und das zyklisches Senden einer ’Heartbeat’-Nachricht. Die Wichtigkeit der Knotenüberwachung werden wir im folgenden Beispiel erfahren. Nehmen wir unseren Aufzug z. B. im Velocity-Modus. Der Fahrgast wird zum gewünschten Stockwerk gefahren. Der Frequenzumrichter bekommt Geschwindigkeistsvorgaben, die Kabine fährt los und der Antrieb wartet auf den Zeitpunkt, an dem ihm die Steuerung den ’Einfahr-Befehl’ sendet. Fällt nun die übergeordnete Steuerung (bzw. der Knoten) aus, hilft nur das Not-System. Ist die Überwachung implementiert, erkennt der Frequenzumrichter zeitlich diesen Ausfall und die Situation wird - ohne Schwierigkeiten - durch einen definierten Fahrt-Abbruch gemeistert. Betrachten wir das Bild 189 genauer, sehen wir, dass die Überwachungsqualität durch die ’Heartbeat Producer Time’ und die ’Hearbeat Consumer Time’ bestimmt wird. Hierbei sollten man sich merken, dass die Konstant-Werte bei höheren Geschwindigkeiten nach unten korrigiert werden müssen. Auf CANopen basierende, verteilte Automatisierungssysteme bestehen aus autonom arbeitenden Einheiten, deren Kommunikationsfähigkeit ab Systemstart jederzeit sichergestellt sein muss. Außerdem muss es möglich sein, den Zustand jedes Knotens so zu steuern, dass es möglich ist, einen Knoten vor Freigabe der Kommunikation zu konfigurieren oder die auf einem Knoten laufende Anwendung und/oder die Kommunikationsparameter eines Knotens gegebenenfalls auch zurückzusetzen. Die Steuerung des Kommunikationszustandes eines Knotens wird durch das zugehörige Zustandsdiagramm eines CANopen-Knotens beschrieben:

Das Bild 190 zeigt das Zustandsdiagramm eines CANopen-Knotens. Dieses Verfahren bietet in der Praxis neue Möglichkeiten im Bezug auf eine schnelle Inbetriebnahme, bequeme Wartung, rasche Fehlersuche, Qualitätssteigerung und Kostensenkung. Wir können an das vollfunktionierende CAN-Bus-System die CANopen-fähigen Geräte schrittweise anschließen, konfigurieren und testen. Wir können - dank dieser Knotensteuerung - Geräte vom Bus entkoppeln und durch andere Geräte ersetzen, ohne das gesamte System abschalten zu müssen. Stellen wir uns vor, dass es eine Wartung des Frequenzumrichters - in einer vernetzten Aufzugsgruppe – anliegt. Der NMT-Master sendet an den NMT-Slave des zu wartenden Frequenzumrichters entsprechende Befehle und der NMT-Slave sorgt automatisch für die Durchführung von Optionen und versetzt den Antrieb in den ’Stopped’-Zustand. Der Antrieb kann nun problemlos ausgeschaltet werden und z. B. ausgewechselt und neu gestartet werden. Der NMT-Slave des neuen Antriebs meldet sich am CAN-Bus und wird vom NMT-Master erkannt und in den Pre-Operational-Zustand versetzt. Jetzt kann die Einstellung von Geräteparametern und die Zuordnung von Applikatonsdaten durchgeführt werden. Mit dem NMT-Kommando ’Start-Remote-Node’’ geht der neue – getauschte - Frequenzumrichter in den ’Operational’-Zustand. Das Aufzugsystem kann weiterlaufen.

Zum Abschluss gehen wir kurz auf den Geschwindigkeits-Modus (Velocity-Mode) und den Lageregelungs-Modus (Position-Mode) ein. Als Basis dient hierbei das in der ’CiA DS 402’ zugrundegelegte Zustandsdiagramm eines Antriebs. Dieses definiert mehrere Drive-Varianten: Im DSP417 sind davon zwei vorgesehen: Profile Velocity Mode und Profile Position Mode. Der erste ist dem DCP_03 ähnlich. Der wesentliche Unterschied für das Fahrverfahren besteht nun darin, dass im DCP/ACP_03 Protokoll die Fahrstufen V1, V2, V3 usw. fest definiert sind, aber CANopen Profile Velocity Mode keine vordefinierte Geschwindigkeit kennt. Es wird also einfach eine zusätzliche Variable mit der Höhe der zu fahrenden ’V3’ geschickt, woit man – im Gegensatz zu DCP/ACP_03 – unendlich viele Fahrstufen erhält. Das Profile Position Mode ist die konsequente Fortsetzung von DCP/ACP_04. Es arbeitet – wie DCP_04 – mit dem sogenannten Restweg/Bremsweg-Verfahren. Derartige Verfahren ermöglichen auch ein ’Last-Call-Catching’ (optimale Rufverteilung innerhalb einer Lift-Gruppe). Um den Position-Mode zu verstehen, sehen wir uns die Bilder zu DCP_04 an:

In Bild 191 sehen wir eine Fahrt über eine Haltestelle. DCP_04 kennt nur eine maximale Geschwindigkeit, daher wird sich bei einer Stockwerksfahrt immer ein Spitzbogen zeigen. Man erkennt, dass der Bremsweg schnell den Punkt erreicht, bei dem der Restweg nicht mehr zum Anhalten ausreicht. Wenn der Bremsweg größer als der Restweg wird, kann der Aufzug nicht mehr anhalten. Hat er eine weiteren Ruf zu einer entfernten Haltestelle, so wird nun dieses Stockwerk angefahren.

In Bild 192 ist unser Aufzug nun an der ersten Etage vorbeigefahren und hält in der nächsten Etage an. Nach Unterschreiten des Bremswegs zur vorherigen Etage springt nun der Restweg wieder auf einen Maximalwert, danach verhält es sich wie im Bild davor.

In Bild 193 konnte der Aufzug ungestört in eine entfernte Haltestelle gelangen. Der Frequenzumrichter meldete dabei bei allen Zwischenetagen den aktuellen Restweg an die Steuerung. Somit hätte die Lift-Steuerung einen Zwischen-Ruf verarbeiten können.

Das Bild 194 zeigt einen Ausschnitt des typischen Datenvolumens unter dem Protokoll DCP_04 zwischen Frequenzumrichter und Lift-Steuerung. Die vorletzte Spalte ist der Restweg, die letzte der Bremsweg. Es handelte sich hierbei um eine Stockwerksfahrt.

In Bild 195 zeigt das Monitoring der Stockwerksfahrt (Rohdaten der Kurve Bild 191). [Beitrag wird fortgesetzt]

20.03.2005 Götz Benczek (für die Liftreport Ausgabe 03/2005)!

Mechatronik für Aufzugsmonteure und Antriebstechniker, Teil 18c Götz Benczek / Viktor Baumung (Dietz-electronic GmbH) CAN (Controller-Area-Network), Grundlagen DSP-417 im Velocity-Mode: Nach unserem kurzen Ausblick in das Verfahren von DCP_04, kehren wir in diesem Artikel wieder zum DSP-417 zurück, um den Velocity-Mode genauer zu betrachten. Die wichtigsten Merkmale des CANopen-Protokolls hinsichtlich DSP-417 haben wir ausführlich in den vorherigen Kapiteln besprochen. Betrachten wir nun am Beispiel der Kommunikation zwischen Liftsteuerung und Frequenzumrichter, wie mindestens zwei parallel laufende Prozesse ausgeführt werden: Ein Prozess für das Kommunikations-Interface und einer für die Gerätefunktionalität. Bild 196: Abstraktes CANOpen-Prozessmodel Car-Drive-Controller + Car-Drive-Unit:

Diese zwei Prozesse arbeiten weitgehend unabhängig von einander. Wenn z. B. beim laufenden Aufzug das Kommunikations-Interface ausfällt, wird der Aufzug durch den Funktions-Prozess kontrolliert abgebremst. Umgekehrt wird bei fehlendem Funktions- Prozess das Kommunikations-Interface dies der Liftsteuerung miteilen, die daraufhin dann den Sicherheitskreis abfallen lassen wird. Den Kommunikations-Prozess, welcher aus mehreren Services (NMT, SDO usw.) besteht, haben wir in den vorherigen Kapiteln bereits erklärt. In diesem Artikel beschäftigen wir uns mit der Zustandsmaschine des Frequensumrichters. Auf dem Bild 197 ist das Blockdiagramm dieser Zustandsmaschine dargestellt, die sich weitgehend an das Antriebs-Profil DSP-402 anlehnt und somit Bestandteil von DSP-417 ist. Ziel des Profils DSP-402 ist es, die gleiche Beschreibung der sichtbaren Funktionalität von Antrieben bereitzustellen. Das Profil DSP-417 wiederum sorgt für die Abstimmung dieser Vielfalt von Möglichkeiten auf die besonderen Bedürfnisse unserer Aufzugsanlage. Das Zustandsdiagramm wird über verschiedenen Zustände und eventuelle zusätzliche Zustandsübergänge beschrieben:

Hier die entsprechende Beschreibung der Zustandsmaschine und die Zustandsübergänge nach DSP-417 (englischer Originaltext):

The following states of the device are possible: • NOT READY TO SWITCH ON: Low level power (e.g. ± 15V, 5V) has been applied to the drive. The drive is being initialized or is running self test. A brake, if present, has to be applied in this state. The drive function is disabled.

• SWITCH ON DISABLED: Drive initialization is complete. The drive parameters have been set up. Drive parameters may be changed. High voltage may not be applied to the drive, (e.g. for safety reasons). The drive function is disabled. • READY TO SWITCH ON: High voltage may be applied to the drive. The drive parameters may be changed. The drive function is disabled. • SWITCHED ON: High voltage has been applied to the drive. The power amplifier is ready. The drive parameters may be changed. The drive function is disabled. • OPERATION ENABLE: No faults have been detected. The drive function is enabled and power is applied to the motor. The drive parameters may be changed. (This corresponds to normal operation of the drive.) • QUICK STOP ACTIVE: The drive parameters may be changed. The quick stop function is being executed. The drive function is enabled and power is applied to the motor. If the quick stop option code is switched to 5 (stay in the state QUICK STOP ACTIVE), you can’t leave the state QUICK STOP ACTIVE, but you can transmit to the state OPERATION ENABLE with the command ‘Enable Operation’. DEVICE CONTROL Drives and Motion Control CiA DSP 402 V 2.0 (47) • FAULT REACTION ACTIVE: The drive parameters may be changed. A fault has occurred in the drive. The quick stop function is being executed. The drive function is enabled and power is applied to the motor. • FAULT: The drive parameters may be changed. A fault has occurred in the drive. High voltage switch-on/-off depends on the application. The drive function is disabled. State transitions of the drive supervisor State transitions are caused by internal events in the drive or by commands from the host via the controlword. • State Transition 0: START => NOT READY TO SWITCH ON Event: Reset. Action: The drive self-tests and/or self-initializes. • State Transition 1: NOT READY TO SWITCH ON => SWITCH ON DISABLED Event: The drive has self-tested and/or initialized successfully. Action: Activate communication. • State Transition 2: SWITCH ON DISABLED => READY TO SWITCH ON Event: 'Shutdown' command received from host. Action: None • State Transition 3: READY TO SWITCH ON => SWITCHED ON Event: 'Switch On' command received from host. Action: The power section is switched on if it is not already switched on. • State Transition 4: SWITCHED ON => OPERATION ENABLE Event: 'Enable Operation' command received from host. Action: The drive function is enabled.

• State Transition 5: OPERATION ENABLE => SWITCHED ON Event: 'Disable Operation' command received from host. Action: The drive operation will be disabled. • State Transition 6: SWITCHED ON => READY TO SWITCH ON Event: 'Shutdown' command received from host. Action: The power section is switched off. • State Transition 7: READY TO SWITCH ON => SWITCH ON DISABLED Event: 'Quick Stop' and ‘Disable Voltage’ command received from host. Action: None • State Transition 8: OPERATION ENABLE => READY TO SWITCH ON Event: 'Shutdown' command received from host. Action: The power section is switched off immediately, and the motor is free to rotate if unbraked. • State Transition 9: OPERATION ENABLE => SWITCH ON DISABLED Event: 'Disable Voltage' command received from host. Action: The power section is switched off immediately, and the motor is free to rotate if unbraked. • State Transition 10: SWITCHED ON => SWITCH ON DISABLED Event: 'Disable Voltage' or 'Quick Stop' command received from host. Action: The power section is switched off immediatly, and the motor is free to rotate if unbraked. DEVICE CONTROL Drives and Motion Control CiA DSP 402 V 2.0 (48) • State Transition 11: OPERATION ENABLE => QUICK STOP ACTIVE Event: 'Quick Stop' command received from host. Action: The quick stop function is executed. • State Transition 12: QUICK STOP ACTIVE => SWITCH ON DISABLED Event: 'Quick Stop' is completed or 'Disable Voltage' command received from host. This transition is possible, if the Quick-Stop-Option-Code is different 5 (stay in the state ‘Quick Stop Active’). Action: The power section is switched off. • State Transition 13: All states => FAULT REACTION ACTIVE A fault has occurred in the drive. Action: Execute appropriate fault reaction. • State Transition 14: FAULT REACTION ACTIVE => FAULT Event: The fault reaction is completed. Action: The drive function is disabled. The power section may be switched off. • State Transition 15: FAULT => SWITCH ON DISABLED Event: 'Fault Reset' command received from host. Action: A reset of the fault condition is carried out if no fault exists currently on the drive. After leaving the state Fault the Bit 'Fault Reset' of the controlword has to be cleared by the host. • State Transition 16: QUICK STOP ACTIVE => OPERATION ENABLE Event: 'Enable Operation' command received from host. This transition is possible if the Quick-Stop-Option-Code is 5, 6, 7 or 8 (→ Chapter 10.3.5). Action: The drive function is enabled. Notes: If a command is received which causes a change of state, this command must be processed completely and the new state attained before the next command can be processed. 'Drive function is disabled' implies no energy is supplied to the motor. This may be achieved by different manufacturers in different ways. Reference values are not processed. 'Drive function is enabled' implies that energy can be supplied to the motor. The reference values (torque, velocity, position) are processed. 'Fault occurred' implies that a fault in the drive has occurred. In this case there is a transition to the state FAULT REACTION ACTIVE. In this state the device will execute a special fault reaction. After the execution of this fault reaction the device will switch to the state FAULT. This state can only be left by the command 'Fault Reset', but only if the fault is not active any more.

Die Steuerung der Zustandsmaschine, ihre Zustände werden über den Empfang eines 16-Bit breiten ’Control Word’ (Steuerwort) oder interne Ereignisse realisiert, siehe Bild 198:

Die für die Steuerung des Gerätezustands erforderlichen Objekte werden im Objekt-Verzeichnis-Bereich ’6040 hex’ bis ’6041 hex’ beschrieben. Bild 199 zeigt die Belegung des Steuerworts ’6040 hex’:

Über das Steuerwort ’6040 hex’ kann die Steuerung über ein entsprechendes Kommando direkt den Zustand des Antriebs steuern. Das Steuerwort wird in den ersten beiden Bytes jeder Kommandonachricht gesendet: Im Profile ’Velocity Mode’ ist das PDO mit COBID 184 hex; im Profile Position Mode ist das PDO mit COBID 180 hex; Bild 200 zeigt die Belegung des Statusworts ’6041 hex’:

Über das 16-Bit-Statuswort ’6041 hex’ wird der aktuelle Status des Antriebs beschrieben. Das Statuswort wird in den ersten beiden Bytes jeder - vom Frequenzumrichter gesendeten PDO - übertragen: Im Profile Velocity Mode ist das PDO mit COBID 185 hex; im Profile Position Mode ist das PDO mit COBID 181 hex; Zum Schluss sehen wir uns ein reales Beispiel für den Fahrablauf im ’Profile Velocity Mode’ an. Der Aufzug wird von einer Haltestelle in die Nächste gefahren (Bild 201):

0. Nach dem die Steuerung und der Frequenzumrichter ihre Betriebsbereitschaft erreicht haben, signalisiert der FU durch das PDO mit COBID: 185 (hex.) und Statuswort: XXXX XXXX X0XX 0000 (Bin.), dass er den Zustand Switch-on-disabled erreicht hatte. (Mit X sind für entsprechende Zustande die nicht relevanten Bits dargestellt). 1. Die Steuerung schließt die Motorschütze und setzt damit die Reglerfreigabe aktiv. Durch das PDO mit COBID: 184 (hex.) und Steuerwort: XXXX XXXX X0XX 0000 (Bin.) gibt die Steuerung das Kommando Shutdown aus. Der Frequenzumrichter wechselt durch Aufruf der Shutdown-Routine in den Ready-to- switch-on-Zustand und signalisiert dies mit dem PDO: 184 hex.: X01X 0001. 2. Wenn die Schütz-Entprellzeit abgelaufen ist und der FU im Ready-to-switch-on-Zustand ist, gibt die Steuerung das Kommando Switch on + Geschwindigkeit Soll-wert aus. 3. Ab dieser Zeit wird vom Frequenzumrichter der Geschwindigkeits-Sollwert übernommen. Der Frequenzumrichter baut durch den Aufruf der Switch-On-Routine das Feld auf, wechselt in den Switched-On–Zustand und signalisiert das mit PDO:184 hex.: X01X 0011. 4. Die Steuerung öffnet die Bremse. 5. Die Steuerung wartet die Bremsöffnungszeit ab und gibt das Kommando Enable Operation. 6. Der Frequenzumrichter meldet Operation Enabled und beginnt die Fahrt. 7. Zum Verzögern gibt die Steuerung die Einfahrgeschwindigkeit vor und der Frequenzumrichter führt die entsprechende Aktivität durch. 8. Zum Anhalten gibt die Steuerung die Geschwindigkeit Null vor und der Frequenzumrichter führt wieder die entsprechende Aktivität durch. 9. Nach Stillsetzen des Motors meldet der Frequenzumrichter ’Ziel erreicht’, wobei im Steurerwort dabei das Bit 10 gesetzt und gesendet wird. 10. Die Steuerung schließt nun die Bremse und gibt das Kommando Disable Operation aus. Der Frequenzumrichter wechselt in Switched-On-Zustand. 11. Die Steuerung wartet die Brems-Schließzeit ab und sendet das Kommando Shutdown, wenn der Umrichter den Switched-On-Zustand gemeldet hat. 12. Der Umrichter baut das Feld ab und meldet darauf den Ready-to-switch-on-Zustand. 13. Die Steuerung öffnet die Motorschütze und löscht damit die Reglerfreigabe. Die Steuerung sendet das Kommando Disable Voltage. Der Frequenzumrichter geht nun in den Switch-on-disabled–Zustand. So ist der Fahrablauf abgeschlossen und das Lift-System steht für neue Fahrt bereit. Ein Schwachpunkt im DSP-417 ist allerdings die Bremsensteuerung. In ACP/DCP wird dies vom Frequenzumrichter (nicht von der Steuerung) erledigt. Hier sollte der Anwender beim CIA einen entsprechenden Antrag auf Ergänzung stellen, der erlauben würde, die Bremse wieder vom Frequenzumrichter zu steuern, was sich bisher ja bewährt hat. Der Grund für die ’unintelligente’ Art der Bremsensteuerung liegt im Ur-Protokoll DSP-402. [Beitrag wird fortgesetzt]

22.05.2005 Götz Benczek (für die Liftreport Ausgabe 04/2005)!