CANopen Spezifikation für Aufzugsteuerungssysteme - Versionsgeschichte

Joerg.Hellmich am 23. Oktober 2007 um 13:53 Uhr

2007-10-23T13:53:42Z

← Nächstältere Version		Version vom 23. Oktober 2007, 15:53 Uhr
Zeile 1:		Zeile 1:
	''Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/) von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)		[[en:CANopen specification for lift control systems]]
	''		''Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/) von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)''

	Der CAN-Bus wird seit vielen Jahren auch von den großen Firmen der Aufzugsindustrie verwendet. Im Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf einem höheren Layer genormten Protokoll, basierend auf CAN, zuzuwenden. Sie entschieden CANopen als Basis für diesen Standard zu nehmen. Das Ziel war eine Art von "plug and play"-Steuerungssystem für jede Standard-Aufzuganwedung. Das Ergebnis dieser Standardisierungsarbeit ist das CANopen-Applikationsprofil für Aufzugsteuerungssysteme CiA 417. Mit diesem Standard ist es möglich, eine Aufzuggruppe von acht Aufzügen mit bis zu 254 Etagen zu errichten.		Der CAN-Bus wird seit vielen Jahren auch von den großen Firmen der Aufzugsindustrie verwendet. Im Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf einem höheren Layer genormten Protokoll, basierend auf CAN, zuzuwenden. Sie entschieden CANopen als Basis für diesen Standard zu nehmen. Das Ziel war eine Art von "plug and play"-Steuerungssystem für jede Standard-Aufzuganwedung. Das Ergebnis dieser Standardisierungsarbeit ist das CANopen-Applikationsprofil für Aufzugsteuerungssysteme CiA 417. Mit diesem Standard ist es möglich, eine Aufzuggruppe von acht Aufzügen mit bis zu 254 Etagen zu errichten.
Zeile 35:		Zeile 35:

	Die virtuellen Gerätedefinitionen für den Hauptantrieb und die Schachtauflösung folgen dem typischen CANopen-Geräteprofil für Antriebssteuerungen (CiA 402) und Wertgeber (CiA 406). Abweichend von den Geräteprofilen werden im Applikationsprofil andere Objektverzeichniseinträge verwendet. Dies ist erforderlich, weil das Applikationsprofil ein einheitliches Objektverzeichnis in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation vordiefiniert, anders als bei den Geräteprofilen. Das Applikationsprofil Lift definiert die PDO-Kommunikation zwischen den Geräten. Eine simple Master/Slave-Kommunikation ist nicht spezifiziert. Beispielsweise erhalten die Steuerung und der Hauptantrieb gleichberechtigt die Information der Schachtauflösung. Der Vorteil dieses Applikationsprofils für Konstrukteure von Aufzügen ist, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das Applikationsprofil. Falls jedoch ein anderer Ablauf gefordert ist, können die zu ändernde Funktion durch Systemkonstrukteure einfach konfiguriert werden. Die Spezifikation ist offen für kundenspezifische Ansprüche. Sehr hochwertige Werkzeuge, die die Besonderheiten des Applikationsprofils beinhalten, stehen für diese Zwecke zur Verfügung.		Die virtuellen Gerätedefinitionen für den Hauptantrieb und die Schachtauflösung folgen dem typischen CANopen-Geräteprofil für Antriebssteuerungen (CiA 402) und Wertgeber (CiA 406). Abweichend von den Geräteprofilen werden im Applikationsprofil andere Objektverzeichniseinträge verwendet. Dies ist erforderlich, weil das Applikationsprofil ein einheitliches Objektverzeichnis in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation vordiefiniert, anders als bei den Geräteprofilen. Das Applikationsprofil Lift definiert die PDO-Kommunikation zwischen den Geräten. Eine simple Master/Slave-Kommunikation ist nicht spezifiziert. Beispielsweise erhalten die Steuerung und der Hauptantrieb gleichberechtigt die Information der Schachtauflösung. Der Vorteil dieses Applikationsprofils für Konstrukteure von Aufzügen ist, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das Applikationsprofil. Falls jedoch ein anderer Ablauf gefordert ist, können die zu ändernde Funktion durch Systemkonstrukteure einfach konfiguriert werden. Die Spezifikation ist offen für kundenspezifische Ansprüche. Sehr hochwertige Werkzeuge, die die Besonderheiten des Applikationsprofils beinhalten, stehen für diese Zwecke zur Verfügung.

			[[Kategorie:Presse]]

Joerg.Hellmich: /* Das CANopen-Lift-Profil */

2007-10-23T13:50:55Z

Das CANopen-Lift-Profil

← Nächstältere Version		Version vom 23. Oktober 2007, 15:50 Uhr
Zeile 32:		Zeile 32:
	Alle diese virtuellen Geräte enthalten verschieden zwingend erforderliche und optionale Funktionen. Zum Beispiel überträgt die Türsteuerung das Steuerwort an die Kabinentür mit dem Befehl, die Tür in vordefinierter Weise zu öffnen oder zu schließen. Die Tür antwortet mit seinem Statuswort über das CANopen-Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält dabei ebenso die Statusinformation der Lichtschranke oder des Lichtgitters über das Netzwerk.		Alle diese virtuellen Geräte enthalten verschieden zwingend erforderliche und optionale Funktionen. Zum Beispiel überträgt die Türsteuerung das Steuerwort an die Kabinentür mit dem Befehl, die Tür in vordefinierter Weise zu öffnen oder zu schließen. Die Tür antwortet mit seinem Statuswort über das CANopen-Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält dabei ebenso die Statusinformation der Lichtschranke oder des Lichtgitters über das Netzwerk.

	Das Konzept des virtuellen Gerätes ermöglicht die Einführung von ~~anwendertranparenten~~ Gateways ~~(Knoten)~~. CANopen Netzwerke sind ~~begrnezt~~ auf 127 ~~Geräten~~ in einem Netzwerk (aktuell verfügbare CAN ~~transceiver~~ können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. ~~Der~~ Knoten ~~kann~~ bis zu 254 virtuelle Geräte ~~einsetzen, auf~~ jeder ~~Seite eine Darstellung zu der anderen~~ Schnittstelle. Der Gebrauch von Gateways löst auch das Problem ~~von~~ zu ~~hoher~~ Busbelastung.		Das Konzept des virtuellen Gerätes ermöglicht die Einführung von anwendungstranparenten Gateways. CANopen-Netzwerke sind begrenzt auf 127 Geräte in einem Netzwerk (aktuell verfügbare CAN-Transceiver können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. So kann der Knoten bis zu 254 virtuelle Geräte transparent an jeder Schnittstelle darstellen. Der Gebrauch von Gateways löst auch das Problem einer zu hohen Busbelastung.

	Die virtuellen Gerätedefinitionen für ~~Kabinenantriebe (Bewegungssteuerung)~~ und Schachtauflösung ~~(Wertgeber)~~ folgen ~~den~~ typischen CANopen Geräteprofil für ~~Bewegungssteuerungeen~~ (CiA ~~DSP~~ 402) und ~~Wertgebern~~ (CiA DS 406). ~~Jedoch verwenden sie in~~ den ~~lift control applications unterschiedliche/~~andere ~~Objektwörterbuch Einträge~~. ~~Das~~ ist, weil das ~~Application Profil genau das selbe Objektwöterbuch~~ in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation ~~in anderer Weise vordefiniert~~ als ~~die typischen Geräteprofile~~. Das ~~lift application profile~~ definiert die PDO-Kommunikation zwischen den Geräten. Eine simple ~~master~~/~~slave~~-Kommunikation ist ~~nich~~ spezifiziert. Beispielsweise erhalten die ~~Türsteuerung~~ und ~~die Kabinensteuerung~~ die Information der Schachtauflösung. Der Vorteil dieses ~~Application Profils ist~~ für Konstrukteure von ~~Aufzugsystemen~~, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das ~~lift application profile~~. Falls ~~aber~~ ein anderer Ablauf gefordert ist, können ~~Systemkonstrukteure~~ die zu ändernde Funktion ~~konfigurieren~~. Die Spezifikation ist offen für ~~diese Art der kundenspezifischen~~ Ansprüche. Werkzeuge ~~höchsten Niveaus~~, die die ~~Details~~ des ~~lift application profile einfügen~~, stehen für ~~dies~~ Zwecke zur Verfügung.		Die virtuellen Gerätedefinitionen für den Hauptantrieb und die Schachtauflösung folgen dem typischen CANopen-Geräteprofil für Antriebssteuerungen (CiA 402) und Wertgeber (CiA 406). Abweichend von den Geräteprofilen werden im Applikationsprofil andere Objektverzeichniseinträge verwendet. Dies ist erforderlich, weil das Applikationsprofil ein einheitliches Objektverzeichnis in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation vordiefiniert, anders als bei den Geräteprofilen. Das Applikationsprofil Lift definiert die PDO-Kommunikation zwischen den Geräten. Eine simple Master/Slave-Kommunikation ist nicht spezifiziert. Beispielsweise erhalten die Steuerung und der Hauptantrieb gleichberechtigt die Information der Schachtauflösung. Der Vorteil dieses Applikationsprofils für Konstrukteure von Aufzügen ist, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das Applikationsprofil. Falls jedoch ein anderer Ablauf gefordert ist, können die zu ändernde Funktion durch Systemkonstrukteure einfach konfiguriert werden. Die Spezifikation ist offen für kundenspezifische Ansprüche. Sehr hochwertige Werkzeuge, die die Besonderheiten des Applikationsprofils beinhalten, stehen für diese Zwecke zur Verfügung.

Joerg.Hellmich: Typo

2007-10-23T13:35:48Z

Typo

← Nächstältere Version		Version vom 23. Oktober 2007, 15:35 Uhr
Zeile 2:		Zeile 2:
	''		''

	Der CAN-Bus wird seit vielen Jahren von den großen ~~Aufzugsbaufirmen in Aufzügen~~ verwendet. In Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf ~~höherer Ebene bewegenden~~ Protokoll, basierend auf CAN, zuzuwenden. Sie entschieden CANopen als Basis für diesen Standard zu nehmen. Das Ziel war eine Art von "plug and play"-Steuerungssystem für jede ~~standard~~ Aufzuganwedung. Das Ergebnis dieser Standardisierungsarbeit ist das CANopen ~~application profile~~ für Aufzugsteuerungssysteme CiA ~~DSP~~ 417. Mit ~~dem Einsatz dieses Standards~~ ist es möglich, eine ~~Aufzuganwendung~~ mit ~~maximal~~ 254 Etagen ~~und acht parallelen Aufzügen einzubauen~~.		Der CAN-Bus wird seit vielen Jahren auch von den großen Firmen der Aufzugsindustrie verwendet. Im Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf einem höheren Layer genormten Protokoll, basierend auf CAN, zuzuwenden. Sie entschieden CANopen als Basis für diesen Standard zu nehmen. Das Ziel war eine Art von "plug and play"-Steuerungssystem für jede Standard-Aufzuganwedung. Das Ergebnis dieser Standardisierungsarbeit ist das CANopen-Applikationsprofil für Aufzugsteuerungssysteme CiA 417. Mit diesem Standard ist es möglich, eine Aufzuggruppe von acht Aufzügen mit bis zu 254 Etagen zu errichten.

	In Oktober 2003 wurden die ersten Prototypen ~~der~~ CANopen Steuerungssysteme auf der Messe Interlift in Deutschland vorgeführt. Ein Prototyp eines Aufzugsystems ~~war~~ auf dem Mitgliederstand der CiA, ~~installiert~~ aus Komponenten verschiedener Hersteller. ~~Die~~ Aufzugsteuerung, ~~die~~ Türsteuerung, Tableaus, Displays und ~~andere Ausstattung:~~ Kommunikation und Datenaustausch ~~waren alle~~ über das CANopen Netzwerk ~~integriert~~. Für die ~~Konstrukteure des Aufzugssysteme~~ ist es ein großer Vorteil Standardprodukte zu ~~kaufen~~, die mit ~~der~~ CANopen ~~lift application profile Spezifikation~~ versehen sind~~, sie zusammen zu stecken,~~ und das Steuerungssystem arbeitet mit nur einem minimalen Aufwand ~~zum Konfigurieren~~.		Im Oktober 2003 wurden die ersten Prototypen dieser CANopen-Steuerungssysteme auf der Messe Interlift in Deutschland vorgeführt. Ein Prototyp eines Aufzugsystems befand sich auf dem Mitgliederstand der CiA, zusammengesetzt aus kompatiblen Komponenten verschiedener Hersteller. Zwischen der Aufzugsteuerung, der Türsteuerung, Tableaus, Displays und anderen Geräten fand die Kommunikation und der Datenaustausch über das CANopen-Netzwerk statt. Für die Aufzugbauer ist es ein großer Vorteil solche Standardprodukte zu verwenden, die mit dem CANopen-Lift Applikationsprofil versehen sind. Sie können einfach zusammengesteckt werden und das Steuerungssystem arbeitet mit nur einem minimalen Aufwand an Konfiguration.

	~~Dieses~~ ist besonders interessant für alle kleineren und mittleren Hersteller von Aufzugsteuerungen. Sie sind nicht abhängig von speziellen Komponenten oder Steuerungslieferanten. Eine vielfältige Auswahl ist ein wichtiger Kernpunkt, um ein Maximum an Flexibilität und funktionalen Optionen zu sichern.		Dies ist besonders interessant für alle kleineren und mittleren Hersteller von Aufzugsteuerungen. Sie sind nicht abhängig von speziellen Komponenten- oder Steuerungslieferanten. Eine vielfältige Auswahl ist ein wichtiger Kernpunkt, um ein Maximum an Flexibilität und funktionalen Optionen zu sichern.

	~~[bearbeiten]~~ CANopen ~~basics~~		==CANopen-Grundlagen==
			CANopen ist eine Anzahl von Netzwerkprotokoll-Spezifikationen, die auf dem Controller Area Network (CAN) basieren, welches in den meisten modernen PKW vorhanden ist. Die CAN-Steuerungschips, die in großen Stückzahlen verkauft werden (ca. 300 Mio pro Jahr), sind zu angemessenen Preisen verfügbar. Deshalb haben mehrere der großen Aufzugbauer seit Mitte der 90er Jahre die CAN-basierenden Netzwerke genutzt.

	~~CANopen~~ ist eine ~~Menge von Netzwerkprotokoll-Spezifikationen~~, die ~~auf dem Controller Area Network (CAN) basieren, welches in den meisten modernen PKW vorhanden ist~~. ~~Die CAN Steuerungschips~~, die ~~in großen Stückzahlen verkauft~~ werden (~~ca. 300 Mio pro Jahr~~)~~, sind zu angemessenen Preisen verfügbar~~. ~~Deshalb haben mehrere der großen Aufzugbauer seit Mitte der 90er Jahre die CAN~~-~~basierenden Netzwerke genutzt~~.		Jedoch ist CAN nur ein »Link Layer Protokoll«. Bei der menschlichen Kommunikation würde man es einen Zeichensatz nennen, so wie das lateinische ABC. Um sich mit Menschen zu unterhalten braucht man aber eine gemeinsame Sprache, die aus Grammatik und Wörtern besteht. In der Netzwerktechnologie nennt man das »Application Layer« und »Application Profile«. Der »Application Layer« definiert, wie die Kommunikationsprotokolle angewendet werden (vergleichbar mit der Grammatik bei der Sprache) und das »Application Profile« definiert alle Parameter und Signale. Die CANopen-Protokolle sind in dem europäischen Standard EN 50325 spezifiziert.

	~~Jedoch ist CAN nur ein link layer Protokoll~~. ~~Bei~~ der ~~menschlichen Kommunikation würde man es einen Zeichensatz nennen~~, ~~so wie das lateinische ABC~~. ~~Um sich~~ mit ~~Menschen zu unterhalten braucht man eine gemeinsame Sprache, die aus Grammatik und Wörtern besteht~~. ~~In der Netzwerktechnologie nennt man das "application layer"~~ und ~~"application profile"~~. ~~Der "application layer" definiert, wie~~ die ~~Kommunikationsprotokolle angewendet~~ werden ~~(vergleichbar mit der Grammatik bei der Sprache), und das "application profile"~~ definiert ~~alle Parameter und Signale~~. Die ~~CANopen Protokolle~~ sind ~~in dem europäischen Standard EN 50325~~ spezifiziert.		==Das CANopen-Lift-Profil==
			Die in der CiA organisierte ''CANopen Special Interest Group (SIG) Lift'' entwickelte die Spezifikation CiA 417, welche die Kommunikation im multiplen Aufzugsteuerungssystem beschreibt. Die auf der Interlift ausstellenden Firmen zeigten Prototypen von Tableaus, Antrieben, Türen, Steuerungen usw. mit dem entsprechenden CANopen-Lift-Standard. Die CANopen-Spezifikation ist für CiA-Mitglieder frei verfügbar und kann ohne Lizenzgebühren in eigenen Produkten verwendet werden. Die Spezifikation beschreibt die Standard-Kommunikation eines Steuerungssystems für bis zu acht Aufzügen mit jeweils bis zu je 254 Etagen. Die Standardkommunikation kann per Konfiguration verändert werden. Das Applikationsprofil Lift definiert sogenannte virtuelle Geräte. Ein physikalisches Gerät kann mehrere virtuelle Geräte enthalten. Jedoch kann ein virtuelles Gerät nicht in verschiedene physikalische CANopen-Geräte aufgeteilt werden. Die folgenden virtuellen Geräte sind bisher spezifiziert:
			* Antriebssteuerung
			* Rufsteuerung
			* Displaysteuerung
			* Kabinentürsteuerung
			* Kabinenantrieb
			* Schachtkopierung
			* Kabinentür
			* Lichtschranken
			* Kabinentableaus
			* Kabinendisplay
			* Sensoren
			* Lastmessgerät
			* Ruftaster
			* Tableau Anzeigen

	~~[bearbeiten] Das CANopen Lift profile~~		Alle diese virtuellen Geräte enthalten verschieden zwingend erforderliche und optionale Funktionen. Zum Beispiel überträgt die Türsteuerung das Steuerwort an die Kabinentür mit dem Befehl, die Tür in vordefinierter Weise zu öffnen oder zu schließen. Die Tür antwortet mit seinem Statuswort über das CANopen-Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält dabei ebenso die Statusinformation der Lichtschranke oder des Lichtgitters über das Netzwerk.

	CiA's CANopen Special Interest Group (SIG) Lift entwickelte die DSP 417 Spezifikation, die die Kommunikation im multiplen Aufzugsteuerungssystem beschreibt. Die auf der Interlift ausstellenden Firmen zeigten Prototypen von Tableaus, Antrieben, Türen, Steuerungen usw mit dem entsprechenden CANopen Lift-Standard. Die CANopen Spezifikation ist für CiA-Mitglieder frei verfügbar und kann ohne Lizenzgebühren eingefügt werden. Die Spezifikation beschreibt die Standard Kommunikation eines Steuerungssystems für bis zu acht Aufzügen mit bis zu je 254 Etagen. Die Standardkommunikation kann per Konfiguration verändert werden. Das lift application profile definier sogenannte virtuelle Geräte. Ein physikalisches Gerät kann mehrere virtuelle Geräte enthalten. Jedoch kann ein virtuelles Gerät nicht in verschiedene physikalische CANopen Geräte übertragen werden. Die folgenden virtuellen Geräte sind spezifiziert:

	* Antriebssteuerung
	* Rufsteuerung
	* Displaysteuerung
	* Kabinentür Steuerung
	* Kabinenantrieb
	* Schachtkopierung
	* Kabinentür
	* Lichtschranken
	* Kabinentableaus
	* Kabinendisplay
	* Sensoren
	* Lastmessgerät
	* Ruftaster
	* Tableau Anzeigen

	Alle diese virtuellen ~~Einrichtungen~~ enthalten ~~zwingende~~ Funktionen ~~so wie optionale Wünsche~~. Zum Beispiel überträgt die Türsteuerung das Steuerwort an die Kabinentür mit dem Befehl, die Tür in vordefinierter Weise zu öffnen oder zu schließen. ~~Und die~~ Tür antwortet mit seinem Statuswort über das CANopen Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält ebenso die Statusinformation der Lichtschranke über das Netzwerk.

	Das Konzept des virtuellen Gerätes ermöglicht die Einführung von anwendertranparenten Gateways (Knoten). CANopen Netzwerke sind begrnezt auf 127 Geräten in einem Netzwerk (aktuell verfügbare CAN transceiver können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. Der Knoten kann bis zu 254 virtuelle Geräte einsetzen, auf jeder Seite eine Darstellung zu der anderen Schnittstelle. Der Gebrauch von Gateways löst auch das Problem von zu hoher Busbelastung.		Das Konzept des virtuellen Gerätes ermöglicht die Einführung von anwendertranparenten Gateways (Knoten). CANopen Netzwerke sind begrnezt auf 127 Geräten in einem Netzwerk (aktuell verfügbare CAN transceiver können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. Der Knoten kann bis zu 254 virtuelle Geräte einsetzen, auf jeder Seite eine Darstellung zu der anderen Schnittstelle. Der Gebrauch von Gateways löst auch das Problem von zu hoher Busbelastung.

	Die virtuellen Gerätedefinitionen für Kabinenantriebe (Bewegungssteuerung) und Schachtauflösung (Wertgeber) folgen den typischen CANopen Geräteprofil für Bewegungssteuerungeen (CiA DSP 402) und Wertgebern (CiA DS 406). Jedoch verwenden sie in den lift control applications unterschiedliche/andere Objektwörterbuch Einträge. Das ist, weil das Application Profil genau das selbe Objektwöterbuch in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation in anderer Weise vordefiniert als die typischen Geräteprofile. Das lift application profile definiert die PDO-Kommunikation zwischen den Geräten. Eine simple master/slave-Kommunikation ist nich spezifiziert. Beispielsweise erhalten die Türsteuerung und die Kabinensteuerung die Information der Schachtauflösung. Der Vorteil dieses Application Profils ist für Konstrukteure von Aufzugsystemen, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das lift application profile. Falls aber ein anderer Ablauf gefordert ist, können Systemkonstrukteure die zu ändernde Funktion konfigurieren. Die Spezifikation ist offen für diese Art der kundenspezifischen Ansprüche. Werkzeuge höchsten Niveaus, die die Details des lift application profile einfügen, stehen für dies Zwecke zur Verfügung.		Die virtuellen Gerätedefinitionen für Kabinenantriebe (Bewegungssteuerung) und Schachtauflösung (Wertgeber) folgen den typischen CANopen Geräteprofil für Bewegungssteuerungeen (CiA DSP 402) und Wertgebern (CiA DS 406). Jedoch verwenden sie in den lift control applications unterschiedliche/andere Objektwörterbuch Einträge. Das ist, weil das Application Profil genau das selbe Objektwöterbuch in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation in anderer Weise vordefiniert als die typischen Geräteprofile. Das lift application profile definiert die PDO-Kommunikation zwischen den Geräten. Eine simple master/slave-Kommunikation ist nich spezifiziert. Beispielsweise erhalten die Türsteuerung und die Kabinensteuerung die Information der Schachtauflösung. Der Vorteil dieses Application Profils ist für Konstrukteure von Aufzugsystemen, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das lift application profile. Falls aber ein anderer Ablauf gefordert ist, können Systemkonstrukteure die zu ändernde Funktion konfigurieren. Die Spezifikation ist offen für diese Art der kundenspezifischen Ansprüche. Werkzeuge höchsten Niveaus, die die Details des lift application profile einfügen, stehen für dies Zwecke zur Verfügung.

Joerg.Hellmich: Die Seite wurde neu angelegt: ''Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/) von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift) '' Der CAN-Bus wird seit viele...

2007-09-02T15:20:37Z

Die Seite wurde neu angelegt: ''Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/) von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift) '' Der CAN-Bus wird seit viele...

Neue Seite

''Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter/) von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)
''

Der CAN-Bus wird seit vielen Jahren von den großen Aufzugsbaufirmen in Aufzügen verwendet. In Jahr 2002 haben sich mehrere mittelständische Firmen entschieden, sich einem auf höherer Ebene bewegenden Protokoll, basierend auf CAN, zuzuwenden. Sie entschieden CANopen als Basis für diesen Standard zu nehmen. Das Ziel war eine Art von "plug and play"-Steuerungssystem für jede standard Aufzuganwedung. Das Ergebnis dieser Standardisierungsarbeit ist das CANopen application profile für Aufzugsteuerungssysteme CiA DSP 417. Mit dem Einsatz dieses Standards ist es möglich, eine Aufzuganwendung mit maximal 254 Etagen und acht parallelen Aufzügen einzubauen.

In Oktober 2003 wurden die ersten Prototypen der CANopen Steuerungssysteme auf der Messe Interlift in Deutschland vorgeführt. Ein Prototyp eines Aufzugsystems war auf dem Mitgliederstand der CiA, installiert aus Komponenten verschiedener Hersteller. Die Aufzugsteuerung, die Türsteuerung, Tableaus, Displays und andere Ausstattung: Kommunikation und Datenaustausch waren alle über das CANopen Netzwerk integriert. Für die Konstrukteure des Aufzugssysteme ist es ein großer Vorteil Standardprodukte zu kaufen, die mit der CANopen lift application profile Spezifikation versehen sind, sie zusammen zu stecken, und das Steuerungssystem arbeitet mit nur einem minimalen Aufwand zum Konfigurieren.

Dieses ist besonders interessant für alle kleineren und mittleren Hersteller von Aufzugsteuerungen. Sie sind nicht abhängig von speziellen Komponenten oder Steuerungslieferanten. Eine vielfältige Auswahl ist ein wichtiger Kernpunkt, um ein Maximum an Flexibilität und funktionalen Optionen zu sichern.

[bearbeiten] CANopen basics

CANopen ist eine Menge von Netzwerkprotokoll-Spezifikationen, die auf dem Controller Area Network (CAN) basieren, welches in den meisten modernen PKW vorhanden ist. Die CAN Steuerungschips, die in großen Stückzahlen verkauft werden (ca. 300 Mio pro Jahr), sind zu angemessenen Preisen verfügbar. Deshalb haben mehrere der großen Aufzugbauer seit Mitte der 90er Jahre die CAN-basierenden Netzwerke genutzt.

Jedoch ist CAN nur ein link layer Protokoll. Bei der menschlichen Kommunikation würde man es einen Zeichensatz nennen, so wie das lateinische ABC. Um sich mit Menschen zu unterhalten braucht man eine gemeinsame Sprache, die aus Grammatik und Wörtern besteht. In der Netzwerktechnologie nennt man das "application layer" und "application profile". Der "application layer" definiert, wie die Kommunikationsprotokolle angewendet werden (vergleichbar mit der Grammatik bei der Sprache), und das "application profile" definiert alle Parameter und Signale. Die CANopen Protokolle sind in dem europäischen Standard EN 50325 spezifiziert.

[bearbeiten] Das CANopen Lift profile

CiA's CANopen Special Interest Group (SIG) Lift entwickelte die DSP 417 Spezifikation, die die Kommunikation im multiplen Aufzugsteuerungssystem beschreibt. Die auf der Interlift ausstellenden Firmen zeigten Prototypen von Tableaus, Antrieben, Türen, Steuerungen usw mit dem entsprechenden CANopen Lift-Standard. Die CANopen Spezifikation ist für CiA-Mitglieder frei verfügbar und kann ohne Lizenzgebühren eingefügt werden. Die Spezifikation beschreibt die Standard Kommunikation eines Steuerungssystems für bis zu acht Aufzügen mit bis zu je 254 Etagen. Die Standardkommunikation kann per Konfiguration verändert werden. Das lift application profile definier sogenannte virtuelle Geräte. Ein physikalisches Gerät kann mehrere virtuelle Geräte enthalten. Jedoch kann ein virtuelles Gerät nicht in verschiedene physikalische CANopen Geräte übertragen werden. Die folgenden virtuellen Geräte sind spezifiziert:

* Antriebssteuerung
* Rufsteuerung
* Displaysteuerung
* Kabinentür Steuerung
* Kabinenantrieb
* Schachtkopierung
* Kabinentür
* Lichtschranken
* Kabinentableaus
* Kabinendisplay
* Sensoren
* Lastmessgerät
* Ruftaster
* Tableau Anzeigen

Alle diese virtuellen Einrichtungen enthalten zwingende Funktionen so wie optionale Wünsche. Zum Beispiel überträgt die Türsteuerung das Steuerwort an die Kabinentür mit dem Befehl, die Tür in vordefinierter Weise zu öffnen oder zu schließen. Und die Tür antwortet mit seinem Statuswort über das CANopen Netzwerk an das Steuersystem. Die Kabinentürsteuerung erhält ebenso die Statusinformation der Lichtschranke über das Netzwerk.

Das Konzept des virtuellen Gerätes ermöglicht die Einführung von anwendertranparenten Gateways (Knoten). CANopen Netzwerke sind begrnezt auf 127 Geräten in einem Netzwerk (aktuell verfügbare CAN transceiver können sogar auf weniger begrenzt sein). Gateways können diese Beschränkung überwinden. Der Knoten kann bis zu 254 virtuelle Geräte einsetzen, auf jeder Seite eine Darstellung zu der anderen Schnittstelle. Der Gebrauch von Gateways löst auch das Problem von zu hoher Busbelastung.

Die virtuellen Gerätedefinitionen für Kabinenantriebe (Bewegungssteuerung) und Schachtauflösung (Wertgeber) folgen den typischen CANopen Geräteprofil für Bewegungssteuerungeen (CiA DSP 402) und Wertgebern (CiA DS 406). Jedoch verwenden sie in den lift control applications unterschiedliche/andere Objektwörterbuch Einträge. Das ist, weil das Application Profil genau das selbe Objektwöterbuch in allen physikalischen Geräten verwendet. Zusätzlich ist jede PDO-Kommunikation in anderer Weise vordefiniert als die typischen Geräteprofile. Das lift application profile definiert die PDO-Kommunikation zwischen den Geräten. Eine simple master/slave-Kommunikation ist nich spezifiziert. Beispielsweise erhalten die Türsteuerung und die Kabinensteuerung die Information der Schachtauflösung. Der Vorteil dieses Application Profils ist für Konstrukteure von Aufzugsystemen, dass sie sich nicht um die Details der Kommunikation kümmern müssen. Alles ist vordefiniert durch das lift application profile. Falls aber ein anderer Ablauf gefordert ist, können Systemkonstrukteure die zu ändernde Funktion konfigurieren. Die Spezifikation ist offen für diese Art der kundenspezifischen Ansprüche. Werkzeuge höchsten Niveaus, die die Details des lift application profile einfügen, stehen für dies Zwecke zur Verfügung.