Neue Funktionen in CANopen-Lift V2.1 - Versionsgeschichte

WikiSysop am 18. September 2016 um 10:25 Uhr

2016-09-18T10:25:20Z

← Nächstältere Version		Version vom 18. September 2016, 12:25 Uhr
Zeile 9:		Zeile 9:
	Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Special Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.		Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Special Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.

	Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten ~~Special~~ Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.		Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.
	In den folgenden Monaten integrierten die Hersteller Schritt für Schritt die Funktionen in ihre Komponenten und bereits 2005 waren die ersten 1000 Aufzüge mit CANopen-Lift-Komponenten ausgeliefert und in Betrieb.		In den folgenden Monaten integrierten die Hersteller Schritt für Schritt die Funktionen in ihre Komponenten und bereits 2005 waren die ersten 1000 Aufzüge mit CANopen-Lift-Komponenten ausgeliefert und in Betrieb.

	In den Jahren 2003 bis 2009 wurden immer mehr Geräte mit einer CANopen-Schnittstelle ausgestattet und in den Standard überwiegend die Funktionen integriert, die auch schon konventionell bzw. mit anderen Schnittstellen realisierbar waren, wie z. B. die serielle Kommunikation zwischen Umrichter und Steuerung mit dem DCP-Protokoll. Die volle Funktionalität steht mit der Version 2.0 der CiA-417 zur Verfügung, die 2010 verabschiedet wurde und seit 2011 als Draft Standard öffentlich frei zur Verfügung steht.		In den Jahren 2003 bis 2009 wurden immer mehr Geräte mit einer CANopen-Schnittstelle ausgestattet und in den Standard überwiegend die Funktionen integriert, die auch schon konventionell bzw. mit anderen Schnittstellen realisierbar waren, wie z. B. die serielle Kommunikation zwischen Umrichter und Steuerung mit dem DCP-Protokoll. Die volle Funktionalität steht mit der Version 2.0 der CiA-417 zur Verfügung, die 2010 verabschiedet wurde und seit 2011 als Draft Standard öffentlich frei zur Verfügung steht.
	Zur Veranschaulichung der Funktionalität wurde durch die ~~Special~~ Marketing Group Lift der CANopen-Lift-Demonstrator entwickelt und im März 2009 erstmals auf den Heilbronner Aufzugstagen ausgestellt.		Zur Veranschaulichung der Funktionalität wurde durch die Marketing Group Lift der CANopen-Lift-Demonstrator entwickelt und im März 2009 erstmals auf den Heilbronner Aufzugstagen ausgestellt.

	Zur Überprüfung der Interoperabilität wurden so genannte PlugFests eingeführt, die regelmäßig seit Anfang 2009 stattfinden. Auf den PlugFesten werden nacheinander an Hand von Checklisten die einzelnen Geräte in ihrer Funktionalität mit den Geräten anderer Hersteller getestet. Die Entwickler haben die Möglichkeit kleinere Unzulänglichkeiten, die bei den Tests auffallen, direkt zu beheben. Weiterhin wurden bei den PlugFesten Tests an den physikalischen Grenzen der CANopen-Spezifikation durchgeführt. Es wurde die Stabilität der Verbindungen mit unterschiedlich langen Busverbindungen bis zu einer Länge von 230 m überprüft und die Geräte am Bus Stresstests unterzogen, bei denen die Buslast schrittweise mit hoch- und niedrigpriorisierten Nachrichten bis zu 100% Buslast erhöht und dabei das Verhalten der Geräte überprüft wurde.		Zur Überprüfung der Interoperabilität wurden so genannte PlugFests eingeführt, die regelmäßig seit Anfang 2009 stattfinden. Auf den PlugFesten werden nacheinander an Hand von Checklisten die einzelnen Geräte in ihrer Funktionalität mit den Geräten anderer Hersteller getestet. Die Entwickler haben die Möglichkeit kleinere Unzulänglichkeiten, die bei den Tests auffallen, direkt zu beheben. Weiterhin wurden bei den PlugFesten Tests an den physikalischen Grenzen der CANopen-Spezifikation durchgeführt. Es wurde die Stabilität der Verbindungen mit unterschiedlich langen Busverbindungen bis zu einer Länge von 230 m überprüft und die Geräte am Bus Stresstests unterzogen, bei denen die Buslast schrittweise mit hoch- und niedrigpriorisierten Nachrichten bis zu 100% Buslast erhöht und dabei das Verhalten der Geräte überprüft wurde.

WikiSysop: WikiSysop verschob die Seite Neue Funktionen in CANopen-Lift nach Neue Funktionen in CANopen-Lift V2.1: Neue Version V2.2

2015-12-18T12:06:31Z

WikiSysop verschob die Seite Neue Funktionen in CANopen-Lift nach Neue Funktionen in CANopen-Lift V2.1: Neue Version V2.2

Neue Seite

[[en:New Functions with CANopen-Lift]]
''Quelle: Lift Report 4-2012 [(http://www.lift-report.de/ www.lift-report.de)] + CAN Newsletter 10/2013 von Jörg Hellmich, [[ELFIN GmbH]] [(http://elfin.de/ elfin.de)]''

[[Datei:Logo_CANopen-Lift.png|thumb|CANopen-Lift ermöglicht die herstellerübergreifende Vernetzung und Wartung von Komponenten eines Aufzugs]]
Viele elektronische Baugruppen sind nötig, um die gewünschte Funktionalität, den Komfort und die aktuell geforderten Anforderungen an die Sicherheit in modernen Aufzügen realisieren zu können. Diese elektronischen Baugruppen sind über moderne Bussysteme miteinander vernetzt und tauschen darüber Statusinformationen oder Kommandos aus. Dazu ist es notwendig, dass alle beteiligten Baugruppen für die Kommunikation das gleiche Busprotokoll 'sprechen und verstehen'. Dies ist nur möglich, wenn entweder alle verwendeten Baugruppen ein offenes standardisiertes Protokoll verwenden und dadurch von jedermann hergestellt werden können oder aber ein geschlossenes proprietäres Protokoll verwenden und somit nur von einem einzigen Hersteller produziert werden können. Ein Beispiel für ein offenes standardisiertes Protokoll ist das auf CANopen basierende Applikationsprofil CiA-417 Lift Control 'CANopen-Lift'. In diesem Applikationsprofil sind alle Parameter und Kommandos eines modernen Aufzugs standardisiert, wie z. B. die Parameter der Frequenzumrichter des Antriebs, die Parameter der Türsteuergeräte und Kommandos wie 'Tür A öffen', 'Kabinenruf Etage 8' oder 'Position 23,263 m; Geschwindigkeit 0,8 m/s; Beschleunigung 0,5 m/s^2'. In dem folgenden Artikel sollen die wichtigsten Meilensteine der Entwicklung von CANopen-Lift und die neusten Funktionen vorgestellt werden.

==Rückblick==
[[Datei:Stand_Interlift_2003.jpg|thumb|Gemeinschaftsstand der CANopen-Lift Gruppe auf der Interlift 2003]]
Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Special Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.

Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten Special Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.
In den folgenden Monaten integrierten die Hersteller Schritt für Schritt die Funktionen in ihre Komponenten und bereits 2005 waren die ersten 1000 Aufzüge mit CANopen-Lift-Komponenten ausgeliefert und in Betrieb.

In den Jahren 2003 bis 2009 wurden immer mehr Geräte mit einer CANopen-Schnittstelle ausgestattet und in den Standard überwiegend die Funktionen integriert, die auch schon konventionell bzw. mit anderen Schnittstellen realisierbar waren, wie z. B. die serielle Kommunikation zwischen Umrichter und Steuerung mit dem DCP-Protokoll. Die volle Funktionalität steht mit der Version 2.0 der CiA-417 zur Verfügung, die 2010 verabschiedet wurde und seit 2011 als Draft Standard öffentlich frei zur Verfügung steht.
Zur Veranschaulichung der Funktionalität wurde durch die Special Marketing Group Lift der CANopen-Lift-Demonstrator entwickelt und im März 2009 erstmals auf den Heilbronner Aufzugstagen ausgestellt.

Zur Überprüfung der Interoperabilität wurden so genannte PlugFests eingeführt, die regelmäßig seit Anfang 2009 stattfinden. Auf den PlugFesten werden nacheinander an Hand von Checklisten die einzelnen Geräte in ihrer Funktionalität mit den Geräten anderer Hersteller getestet. Die Entwickler haben die Möglichkeit kleinere Unzulänglichkeiten, die bei den Tests auffallen, direkt zu beheben. Weiterhin wurden bei den PlugFesten Tests an den physikalischen Grenzen der CANopen-Spezifikation durchgeführt. Es wurde die Stabilität der Verbindungen mit unterschiedlich langen Busverbindungen bis zu einer Länge von 230 m überprüft und die Geräte am Bus Stresstests unterzogen, bei denen die Buslast schrittweise mit hoch- und niedrigpriorisierten Nachrichten bis zu 100% Buslast erhöht und dabei das Verhalten der Geräte überprüft wurde.

==Neue Funktionen ==
Seit 2009 werden stetig neue Funktionen in den Standard und durch die Hersteller in die Geräte integriert, die ohne einen offenen Standard so nicht möglich wären. Einige davon werden in den folgenden Abschnitten kurz beschrieben.

===Energiezähler===
[[Datei:CANopen_Energiemessung.png|thumb|CANopen ermöglicht die Energiemessung in verschiedenen vernetzten Verbraucher]]
Mit der Richtlinie VDI 4707 wurde ein Verfahren zur energetischen Bewertung von Aufzügen veröffentlicht. Zur Ausstellung des Zertifikates sind die Messung des Energiebedarfs während einer definierten Testfahrt und die Ermittlung des Energiebedarfs im Stillstand notwendig. Diese Messungen sind sehr aufwendig und können nur einmal manuell und nicht kontinuierlich durchgeführt werden. Bei der Messung muss der Energiebedarf mit teuren Messgeräten gleichzeitig in den 3 Phasen und dem Neutralleiter erfasst werden. Dabei stellt der sehr große Unterschied im Messbereich während der Fahrt und im Stillstand eine besondere Herausforderung dar.

Zur Vereinfachung wurde die Protokolle für eine automatische Messung entwickelt und in den CANopen-Lift-Standard integriert. Die Frequenzumrichter in den Antrieben moderner Aufzüge kennen den Energiefluss zum Antrieb und den aktuellen Eigenbedarf. Diese Messwerte werden über den CAN-Bus an die Steuerung übertragen. Nun reicht ein einfaches Messgerät zur Ermittlung des restlichen Energiebedarfs des Aufzugs, das nur einen kleinen Messbereich abdecken muss, ein- oder zweiphasig sein kann und nicht einmal über ein eigenes Display verfügen muss. Dieses Messgerät überträgt den restlichen Energiebedarf ebenfalls zur Steuerung des Aufzugs, wo dann über die Kumulation der Gesamtenergiebedarf auch über längere Zeiträume automatisch ermittelt werden kann.

===Energiemanagement===
Ein Aufzug wird in verschiedenen Betriebsmodi betrieben, wie z. B. in Fahrt, betriebsbereit, standby oder aus. Viele Geräte könnten automatisch ihren Energiebedarf reduzieren, wenn ihnen der aktuelle Betriebsmodus bekannt wäre, bzw. sie könnten aktiv in verschiedene Energiesparmodi geschaltet werden, wenn dafür entsprechende Eingänge vorhanden wären.

Im Standard CANopen-Lift wurden verschiedene Kommandos definiert, um Komponenten in Abhängigkeit vom aktuellen Betriebszustand in verschiedene Energiesparmodi zu schalten.

In der Vergangenheit wurden zur Reduzierung des Energiebedarfs einzelne Verbraucher komplett abgeschaltet, wenn vermutet wurde, dass der Aufzug für längere Zeit nicht mehr benötigt wird. Relativ sicher kann man dies jedoch nur in der Nacht oder in Bürogebäuden an Wochenenden vorhersagen. In der restlichen Zeit steht der Aufzug betriebsbereit zur sofortigen Nutzung zur Verfügung, ohne den Energiebedarf zu reduzieren.

Mit den neuen Kommandos für das Energiemanagement besteht nun zusätzlich die Möglichkeit, gezielt einzelne Verbraucher sofort nach jeder Fahrt in einen internen Standby-Modus mit reduziertem Energiebedarf zu versetzen. Der daraus resultierende Einspareffekt ist wesentlich größer, als das vollständige Abschalten zu begrenzten Zeiten.

===Person Present===
[[Datei:Person_Present.png|thumb|Durch die Auswertung vieler Sensoren über das Netzwerk kann die Anwesenheit von Personen in der Kabine bestimmt werden]]
Durchschnittlich ein Drittel des Stillstandsbedarfs eines aktuellen Aufzugs verursacht das Kabinenlicht, wenn es im Stillstand nicht abgeschaltet wird. Moderne Steuerungen schalten das Kabinenlicht automatisch ab, wenn sich der Aufzug in einer Ruhehaltestelle bzw. Parketage befindet, die Türen geschlossen sind und keine Rufe vorliegen. Es wird dann angenommen, dass sich keine Personen mehr in der Kabine befinden. Dies ist jedoch eine reine Annahme.

Verschiedene Sensoren ermöglichen die präzisere Erfassung von Personen in der Kabine. So können zum Beispiel genaue Lastmesssysteme erfassen, ob sich eine Person/Last in der Kabine befindet und ein entsprechendes Signal ausgeben. Auch in oder auf der Kabine angebrachte Beschleunigungssensoren erfassen leichteste Bewegungen von Personen in der Kabine und können dies signalisieren und ebenso Kamerasysteme, welche die Belegung der Kabinenfläche ermitteln. In der Summe dieser Signale lässt sich sehr genau bestimmen, ob sich eine Person in der Kabine befindet oder nicht.

Diese Information kann gezielt dazu verwendet werden, dass Kabinenlicht zu deaktivieren auch bei so genannten Leerfahrten. Auch für die Feuerwehr im Brandfall bzw. bei Evakuierungen, Zugangskontrollsysteme und das Gebäudemanagement können diese Information nutzen.

===Bootloader===
Eines der Ziele bei der Entwicklung von CANopen-Lift war die Möglichkeit, dass man herstellerübergreifend mit einem einheitlichen Tool alle Geräte konfigurieren kann. Eine entsprechende Software wird mit dem CANwizard schon seit vielen Jahren von der Firma BÖHNKE + PARTNER angeboten.

Ebenfalls von Interesse ist die Möglichkeit, die aktuelle Firmware von Geräten zu sichern und eine Firmwareupdate durchzuführen. Ein Verfahren dazu wurde 2006 von BÖHNKE + PARTNER entwickelt und eine Beschreibung veröffentlicht. Dieses Verfahren wurde bereits von mehreren Herstellern in die eigenen Produkte integriert und wurde nun auch offiziell in den Standard aufgenommen.

Mit diesem Verfahren besteht nicht nur die Möglichkeit ein Softwareupdate in einer Baugruppe durchzuführen, sondern es können auch die Parametersets aller Baugruppen nach einer Inbetriebnahme ausgelesen und gesichert werden. Somit können leicht Manipulationen erfasst werden, die nach einer Abnahme an einer Anlage durchgeführt werden. Dies ist nicht nur für das Wartungsunternehmen und den Betreiber eines Aufzugs von Interesse, sondern auch für die zugelassene Überwachungsstelle oder für die Feuerwehr im Schadensfall.

===Faststart und Faststop===
[[Datei:Fast_Stop.png|thumb|Sichere Sensoren (PESSRAL) können den Aufzug elektrisch stoppen]]
Um störende Verzögerungen beim Starten nach dem Schließen der Kabinentüren zu verhindern und somit die Transportkapazität der Aufzüge zu erhöhen, steht in CANopen-Lift die Faststart-Funktion zur Verfügung, bei der der Antrieb schon während des Schließens der Türen mit der Geschwindigkeit Null angesteuert wird und nach dem vollständigen Schließen der Türen ohne Verzögerung starten kann.

In der Vergangenheit führt ein Loslassen des Auf- bzw. Ab-Tasters der Inspektionssteuerung bzw. Rückholsteuerung meist zu einer Unterbrechung des Sicherheitskreises und somit zum Abfall der Hauptschütze während der Antrieb im Betrieb ist. Dies führt zur vorzeitigen Alterung der Frequenzumrichter und der Hauptschütze.

Zusätzlich zur Faststart-Funktion wurde in CANopen-Lift eine Faststop-Funktion definiert, die ein schnelles, definiertes Anhalten des Aufzugs über den Antrieb ermöglicht. Diese Funktion kann zum Einen verwendet werden beim Verfahren der Kabine mit der Inspektionssteuerung bzw. Rückholsteuerung. Nach dem Loslassen des Auf- bzw. Ab-Tasters kann die Kabine mit dem Antrieb auf einer fest definierten Rampe bis zum Stillstand verzögert werden. Dadurch ist nicht nur ein definiertes Anhalten möglich sondern es wird auch die Lebensdauer des Frequenzumrichters und der Hauptschütze wesentlich erhöht.

Weiterhin kann diese Funktion auch durch neue auf PESSRAL-basierende elektronische Sicherheitsbauteile verwendetet werden. Wird durch ein Sicherheitsbauteil ein unsicherer Zustand erkannt, kann es durch ein Faststop-Kommando unabhängig von der Steuerung den Antrieb dazu veranlassen, auf einer fest definierten Rampe bis zum Stillstand zu verzögern und gleichzeitig diese Verzögerung überwachen. Somit kann die Kabine mit definierten Verzögerungen elektrisch zum Stehen gebracht werden, statt unkontrolliert durch mechanische Verfahren.

===Virtuelle Konsole===
[[Bild:Virtuelle_Konsole_grafisch.png|thumb|Übertragung grafischer Displayinhalte über den CAN-Bus]]
Seit der Entwicklung des DCP-Protokolls besteht die Möglichkeit, den Inhalt des Displays des Frequenzumrichters in der Steuerung darzustellen und den Umrichter von der Steuerung aus zu parametrieren. Diese Funktion ist beim DCP-Protokoll jedoch auf die beiden Geräte Steuerung und Umrichter begrenzt und sie ist unidirektional.

Im Standard CANopen-Lift steht dieses Verfahren seit 2003 als 'Virtuelle Konsole' allen angeschlossenen Baugruppen zur Verfügung. Jedes Gerät kann einen virtuellen Displayinhalt auf den Bus legen und jedes andere Gerät, das über ein Display und Tasten verfügt, kann für die Darstellung und Konfiguration verwendet werden. So könnte man zum Beispiel eine in der Kabine vorhandene LCD-Anzeige und die Tasten des Kabinentableaus verwenden, um während der Wartung das Menü der Steuerung in der Kabine anzuzeigen und auf Parameter oder Störungsinformationen zuzugreifen.
Bisher konnten mit der 'Virtuellen Konsole' nur Zeichen übertragen werden, die im ASCII-Zeichensatz definiert sind. Nun wurde von BÖHNKE + PARTNER ein Verfahren zur Aufnahme in den Standard vorgeschlagen, mit dem auch der Inhalt von grafischen Displays übertragen werden kann. Dieses Verfahren bietet zukünftig die Möglichkeit, herstellerübergreifend Geräte mit grafischen Displays z. B. über Smartphones zu konfigurieren.

===Busqualität ===
[[Bild:Signalqualitaet-balken.jpg|thumb|Darstellung der Signalqualität auf dem CAN-Bus durch Auswertung von Error Countern]]
Bei vernetzten Systemen kann es hin und wieder zu Busstörungen kommen. Dies kann viele Ursachen haben, zum Beispiel EMV-Störungen, eine schlechte Verkabelung, falsche Topologien oder nicht vorhandene Leitungsterminierungen. Auf Grund der sehr guten Fehlerkorrekturmaßnahmen, die automatisch durch die CAN-Controller durchgeführt werden, fallen diese Störungen erst auf, wenn sie über eine längere Zeit anliegen und sehr massiv sind.

Vor allem bei den PlugFesten entstand der Wunsch, das Verhalten der einzelnen Geräte beim Auftreten von Störsignalen, hohen Buslasten und zerstörten Nachrichten zu überprüfen.
Für diese Tests wurde interne Fehlerzähler definiert, die während der Tests durch Diagnosewerkzeuge ausgelesen werden können und die einen Hinweis auf die Signalqualität der Netzwerke schließen lassen. Mit Hilfe dieser Fehlerzähler können schon während der Installation eines Netzwerkes eventuell vorhandene Störquellen aufgedeckt und dann leicht behoben werden.

==Zusammenfassung==
Der Standard CANopen-Lift wird gelebt und ständig weiterentwickelt. Die wesentlichen Neuerungen kommen immer noch aus Deutschland, aber CANopen-Lift erlangt zunehmend auch international an Bedeutung.

In den Jahren 2003-2009 wurden die bekannten Funktionen eines Aufzugs, die auch mit diskreten Eingängen und seriellen Punkt-zu-Punkt-Verbindungen realisierbar waren, in das Applikationsprofil und in die Komponenten der Hersteller integriert. Seit 2009 werden nun auf dieser Basis immer mehr neue Funktionen entwickelt, die ohne den Standard CANopen-Lift nicht möglich wären. Im Mittelpunkt der aktuellen Erweiterungen stehen Funktionen zur Erfassung und Reduzierung des Energiebedarfs von Aufzügen, Funktionen zur Erhöhung der Lebensdauer von Komponenten und Funktionen zur komfortableren Inbetriebnahme und Diagnose des Netzwerks und von Komponenten. Immer mehr Firmen beteiligen sich an der Weiterentwicklung von CANopen-Lift und bringen neue Ideen in den Standard ein, die allen Beteiligten zur Verfügung stehen. Die Zukunft bleibt spannend.

[[Kategorie: Presse]]
[[Kategorie: CAN Newsletter]]

WikiSysop am 16. Mai 2014 um 11:24 Uhr

2014-05-16T11:24:10Z

← Nächstältere Version		Version vom 16. Mai 2014, 13:24 Uhr
Zeile 1:		Zeile 1:
	[[en:New Functions with CANopen-Lift]]		[[en:New Functions with CANopen-Lift]]
	''Quelle: Lift Report 4-2012 [(http://www.lift-report.de/ www.lift-report.de)] von Jörg Hellmich, [[ELFIN GmbH]] [(http://elfin.de/ elfin.de)]''		''Quelle: Lift Report 4-2012 [(http://www.lift-report.de/ www.lift-report.de)] + CAN Newsletter 10/2013 von Jörg Hellmich, [[ELFIN GmbH]] [(http://elfin.de/ elfin.de)]''

	[[Datei:Logo_CANopen-Lift.png\|thumb\|CANopen-Lift ermöglicht die herstellerübergreifende Vernetzung und Wartung von Komponenten eines Aufzugs]]		[[Datei:Logo_CANopen-Lift.png\|thumb\|CANopen-Lift ermöglicht die herstellerübergreifende Vernetzung und Wartung von Komponenten eines Aufzugs]]
Zeile 81:		Zeile 81:

	[[Kategorie: Presse]]		[[Kategorie: Presse]]
			[[Kategorie: CAN Newsletter]]

Joerg.Hellmich am 9. Juli 2013 um 10:32 Uhr

2013-07-09T10:32:07Z

← Nächstältere Version		Version vom 9. Juli 2013, 12:32 Uhr
Zeile 1:		Zeile 1:
			[[en:New Functions with CANopen-Lift]]
	''Quelle: Lift Report 4-2012 [(http://www.lift-report.de/ www.lift-report.de)] von Jörg Hellmich, [[ELFIN GmbH]] [(http://elfin.de/ elfin.de)]''		''Quelle: Lift Report 4-2012 [(http://www.lift-report.de/ www.lift-report.de)] von Jörg Hellmich, [[ELFIN GmbH]] [(http://elfin.de/ elfin.de)]''

Joerg.Hellmich: /* Virtuelle Konsole */

2012-07-05T16:09:14Z

Virtuelle Konsole

← Nächstältere Version		Version vom 5. Juli 2012, 18:09 Uhr
Zeile 60:		Zeile 60:

	===Virtuelle Konsole===		===Virtuelle Konsole===
			[[Bild:Virtuelle_Konsole_grafisch.png\|thumb\|Übertragung grafischer Displayinhalte über den CAN-Bus]]
	Seit der Entwicklung des DCP-Protokolls besteht die Möglichkeit, den Inhalt des Displays des Frequenzumrichters in der Steuerung darzustellen und den Umrichter von der Steuerung aus zu parametrieren. Diese Funktion ist beim DCP-Protokoll jedoch auf die beiden Geräte Steuerung und Umrichter begrenzt und sie ist unidirektional.		Seit der Entwicklung des DCP-Protokolls besteht die Möglichkeit, den Inhalt des Displays des Frequenzumrichters in der Steuerung darzustellen und den Umrichter von der Steuerung aus zu parametrieren. Diese Funktion ist beim DCP-Protokoll jedoch auf die beiden Geräte Steuerung und Umrichter begrenzt und sie ist unidirektional.

	Im Standard CANopen-Lift steht dieses Verfahren seit 2003 als 'Virtuelle Konsole' allen angeschlossenen Baugruppen zur Verfügung. Jedes Gerät kann einen virtuellen Displayinhalt auf den Bus legen und jedes andere Gerät, das über ein Display und Tasten verfügt, kann für die Darstellung und Konfiguration verwendet werden. So könnte man zum Beispiel eine in der Kabine vorhandene LCD-Anzeige und die Tasten des Kabinentableaus verwenden, um während der Wartung das Menü der Steuerung in der Kabine anzuzeigen und auf Parameter oder Störungsinformationen zuzugreifen.		Im Standard CANopen-Lift steht dieses Verfahren seit 2003 als 'Virtuelle Konsole' allen angeschlossenen Baugruppen zur Verfügung. Jedes Gerät kann einen virtuellen Displayinhalt auf den Bus legen und jedes andere Gerät, das über ein Display und Tasten verfügt, kann für die Darstellung und Konfiguration verwendet werden. So könnte man zum Beispiel eine in der Kabine vorhandene LCD-Anzeige und die Tasten des Kabinentableaus verwenden, um während der Wartung das Menü der Steuerung in der Kabine anzuzeigen und auf Parameter oder Störungsinformationen zuzugreifen.
	Bisher konnten mit der 'Virtuellen Konsole' nur Zeichen übertragen werden, die im ASCII-Zeichensatz definiert sind. Nun wurde von BÖHNKE + PARTNER ein Verfahren zur Aufnahme in den Standard vorgeschlagen, mit dem auch der Inhalt von grafischen Displays übertragen werden kann. Dieses Verfahren bietet zukünftig die Möglichkeit, herstellerübergreifend Geräte mit grafischen Displays z. B. über Smartphones zu konfigurieren.		Bisher konnten mit der 'Virtuellen Konsole' nur Zeichen übertragen werden, die im ASCII-Zeichensatz definiert sind. Nun wurde von BÖHNKE + PARTNER ein Verfahren zur Aufnahme in den Standard vorgeschlagen, mit dem auch der Inhalt von grafischen Displays übertragen werden kann. Dieses Verfahren bietet zukünftig die Möglichkeit, herstellerübergreifend Geräte mit grafischen Displays z. B. über Smartphones zu konfigurieren.

	===Busqualität ===		===Busqualität ===

Joerg.Hellmich: /* Faststart und Faststop */

2012-07-05T15:03:09Z

Faststart und Faststop

← Nächstältere Version		Version vom 5. Juli 2012, 17:03 Uhr
Zeile 50:		Zeile 50:

	===Faststart und Faststop===		===Faststart und Faststop===
			[[Datei:Fast_Stop.png\|thumb\|Sichere Sensoren (PESSRAL) können den Aufzug elektrisch stoppen]]
	Um störende Verzögerungen beim Starten nach dem Schließen der Kabinentüren zu verhindern und somit die Transportkapazität der Aufzüge zu erhöhen, steht in CANopen-Lift die Faststart-Funktion zur Verfügung, bei der der Antrieb schon während des Schließens der Türen mit der Geschwindigkeit Null angesteuert wird und nach dem vollständigen Schließen der Türen ohne Verzögerung starten kann.		Um störende Verzögerungen beim Starten nach dem Schließen der Kabinentüren zu verhindern und somit die Transportkapazität der Aufzüge zu erhöhen, steht in CANopen-Lift die Faststart-Funktion zur Verfügung, bei der der Antrieb schon während des Schließens der Türen mit der Geschwindigkeit Null angesteuert wird und nach dem vollständigen Schließen der Türen ohne Verzögerung starten kann.

Zeile 56:		Zeile 57:
	Zusätzlich zur Faststart-Funktion wurde in CANopen-Lift eine Faststop-Funktion definiert, die ein schnelles, definiertes Anhalten des Aufzugs über den Antrieb ermöglicht. Diese Funktion kann zum Einen verwendet werden beim Verfahren der Kabine mit der Inspektionssteuerung bzw. Rückholsteuerung. Nach dem Loslassen des Auf- bzw. Ab-Tasters kann die Kabine mit dem Antrieb auf einer fest definierten Rampe bis zum Stillstand verzögert werden. Dadurch ist nicht nur ein definiertes Anhalten möglich sondern es wird auch die Lebensdauer des Frequenzumrichters und der Hauptschütze wesentlich erhöht.		Zusätzlich zur Faststart-Funktion wurde in CANopen-Lift eine Faststop-Funktion definiert, die ein schnelles, definiertes Anhalten des Aufzugs über den Antrieb ermöglicht. Diese Funktion kann zum Einen verwendet werden beim Verfahren der Kabine mit der Inspektionssteuerung bzw. Rückholsteuerung. Nach dem Loslassen des Auf- bzw. Ab-Tasters kann die Kabine mit dem Antrieb auf einer fest definierten Rampe bis zum Stillstand verzögert werden. Dadurch ist nicht nur ein definiertes Anhalten möglich sondern es wird auch die Lebensdauer des Frequenzumrichters und der Hauptschütze wesentlich erhöht.

	Weiterhin kann diese Funktion auch durch neue auf PESSRAL-basierende elektronische Sicherheitsbauteile verwendetet werden. Wird durch ein Sicherheitsbauteil ein unsicherer Zustand erkannt, kann es durch ein Faststop-Kommando unabhängig von der Steuerung den Antrieb dazu veranlassen, auf einer fest definierten Rampe bis zum Stillstand zu verzögern und gleichzeitig diese Verzögerung überwachen. Somit kann die Kabine mit definierten Verzögerungen elektrisch zum Stehen gebracht werden, statt unkontrolliert durch mechanische Verfahren.		Weiterhin kann diese Funktion auch durch neue auf PESSRAL-basierende elektronische Sicherheitsbauteile verwendetet werden. Wird durch ein Sicherheitsbauteil ein unsicherer Zustand erkannt, kann es durch ein Faststop-Kommando unabhängig von der Steuerung den Antrieb dazu veranlassen, auf einer fest definierten Rampe bis zum Stillstand zu verzögern und gleichzeitig diese Verzögerung überwachen. Somit kann die Kabine mit definierten Verzögerungen elektrisch zum Stehen gebracht werden, statt unkontrolliert durch mechanische Verfahren.

	===Virtuelle Konsole===		===Virtuelle Konsole===

Joerg.Hellmich: /* Person Present */

2012-07-05T14:41:18Z

Person Present

← Nächstältere Version		Version vom 5. Juli 2012, 16:41 Uhr
Zeile 35:		Zeile 35:

	===Person Present===		===Person Present===
			[[Datei:Person_Present.png\|thumb\|Durch die Auswertung vieler Sensoren über das Netzwerk kann die Anwesenheit von Personen in der Kabine bestimmt werden]]
	Durchschnittlich ein Drittel des Stillstandsbedarfs eines aktuellen Aufzugs verursacht das Kabinenlicht, wenn es im Stillstand nicht abgeschaltet wird. Moderne Steuerungen schalten das Kabinenlicht automatisch ab, wenn sich der Aufzug in einer Ruhehaltestelle bzw. Parketage befindet, die Türen geschlossen sind und keine Rufe vorliegen. Es wird dann angenommen, dass sich keine Personen mehr in der Kabine befinden. Dies ist jedoch eine reine Annahme.		Durchschnittlich ein Drittel des Stillstandsbedarfs eines aktuellen Aufzugs verursacht das Kabinenlicht, wenn es im Stillstand nicht abgeschaltet wird. Moderne Steuerungen schalten das Kabinenlicht automatisch ab, wenn sich der Aufzug in einer Ruhehaltestelle bzw. Parketage befindet, die Türen geschlossen sind und keine Rufe vorliegen. Es wird dann angenommen, dass sich keine Personen mehr in der Kabine befinden. Dies ist jedoch eine reine Annahme.

	Verschiedene Sensoren ermöglichen die präzisere Erfassung von Personen in der Kabine. So können zum Beispiel genaue Lastmesssysteme erfassen, ob sich eine Person/Last in der Kabine befindet und ein entsprechendes Signal ausgeben. Auch in oder auf der Kabine angebrachte Beschleunigungssensoren erfassen leichteste Bewegungen von Personen in der Kabine und können dies signalisieren und ebenso Kamerasysteme, welche die Belegung der Kabinenfläche ermitteln. In der Summe dieser Signale lässt sich sehr genau bestimmen, ob sich eine Person in der Kabine befindet oder nicht.		Verschiedene Sensoren ermöglichen die präzisere Erfassung von Personen in der Kabine. So können zum Beispiel genaue Lastmesssysteme erfassen, ob sich eine Person/Last in der Kabine befindet und ein entsprechendes Signal ausgeben. Auch in oder auf der Kabine angebrachte Beschleunigungssensoren erfassen leichteste Bewegungen von Personen in der Kabine und können dies signalisieren und ebenso Kamerasysteme, welche die Belegung der Kabinenfläche ermitteln. In der Summe dieser Signale lässt sich sehr genau bestimmen, ob sich eine Person in der Kabine befindet oder nicht.

	Diese Information kann gezielt dazu verwendet werden, dass Kabinenlicht zu deaktivieren auch bei so genannten Leerfahrten. Auch für die Feuerwehr im Brandfall bzw. bei Evakuierungen, Zugangskontrollsysteme und das Gebäudemanagement können diese Information nutzen.		Diese Information kann gezielt dazu verwendet werden, dass Kabinenlicht zu deaktivieren auch bei so genannten Leerfahrten. Auch für die Feuerwehr im Brandfall bzw. bei Evakuierungen, Zugangskontrollsysteme und das Gebäudemanagement können diese Information nutzen.

	===Bootloader===		===Bootloader===

Joerg.Hellmich: /* Energiezähler */ Grafik hinzugefügt

2012-07-05T13:55:16Z

Energiezähler: Grafik hinzugefügt

← Nächstältere Version		Version vom 5. Juli 2012, 15:55 Uhr
Zeile 20:		Zeile 20:

	===Energiezähler===		===Energiezähler===
			[[Datei:CANopen_Energiemessung.png\|thumb\|CANopen ermöglicht die Energiemessung in verschiedenen vernetzten Verbraucher]]
	Mit der Richtlinie VDI 4707 wurde ein Verfahren zur energetischen Bewertung von Aufzügen veröffentlicht. Zur Ausstellung des Zertifikates sind die Messung des Energiebedarfs während einer definierten Testfahrt und die Ermittlung des Energiebedarfs im Stillstand notwendig. Diese Messungen sind sehr aufwendig und können nur einmal manuell und nicht kontinuierlich durchgeführt werden. Bei der Messung muss der Energiebedarf mit teuren Messgeräten gleichzeitig in den 3 Phasen und dem Neutralleiter erfasst werden. Dabei stellt der sehr große Unterschied im Messbereich während der Fahrt und im Stillstand eine besondere Herausforderung dar.		Mit der Richtlinie VDI 4707 wurde ein Verfahren zur energetischen Bewertung von Aufzügen veröffentlicht. Zur Ausstellung des Zertifikates sind die Messung des Energiebedarfs während einer definierten Testfahrt und die Ermittlung des Energiebedarfs im Stillstand notwendig. Diese Messungen sind sehr aufwendig und können nur einmal manuell und nicht kontinuierlich durchgeführt werden. Bei der Messung muss der Energiebedarf mit teuren Messgeräten gleichzeitig in den 3 Phasen und dem Neutralleiter erfasst werden. Dabei stellt der sehr große Unterschied im Messbereich während der Fahrt und im Stillstand eine besondere Herausforderung dar.

	Zur Vereinfachung wurde die Protokolle für eine automatische Messung entwickelt und in den CANopen-Lift-Standard integriert. Die Frequenzumrichter in den Antrieben moderner Aufzüge kennen den Energiefluss zum Antrieb und den aktuellen Eigenbedarf. Diese Messwerte werden über den CAN-Bus an die Steuerung übertragen. Nun reicht ein einfaches Messgerät zur Ermittlung des restlichen Energiebedarfs des Aufzugs, das nur einen kleinen Messbereich abdecken muss, ein- oder zweiphasig sein kann und nicht einmal über ein eigenes Display verfügen muss. Dieses Messgerät überträgt den restlichen Energiebedarf ebenfalls zur Steuerung des Aufzugs, wo dann über die Kumulation der Gesamtenergiebedarf auch über längere Zeiträume automatisch ermittelt werden kann.		Zur Vereinfachung wurde die Protokolle für eine automatische Messung entwickelt und in den CANopen-Lift-Standard integriert. Die Frequenzumrichter in den Antrieben moderner Aufzüge kennen den Energiefluss zum Antrieb und den aktuellen Eigenbedarf. Diese Messwerte werden über den CAN-Bus an die Steuerung übertragen. Nun reicht ein einfaches Messgerät zur Ermittlung des restlichen Energiebedarfs des Aufzugs, das nur einen kleinen Messbereich abdecken muss, ein- oder zweiphasig sein kann und nicht einmal über ein eigenes Display verfügen muss. Dieses Messgerät überträgt den restlichen Energiebedarf ebenfalls zur Steuerung des Aufzugs, wo dann über die Kumulation der Gesamtenergiebedarf auch über längere Zeiträume automatisch ermittelt werden kann.

	===Energiemanagement===		===Energiemanagement===

Joerg.Hellmich am 5. Juli 2012 um 12:22 Uhr

2012-07-05T12:22:56Z

← Nächstältere Version		Version vom 5. Juli 2012, 14:22 Uhr
Zeile 5:		Zeile 5:

	==Rückblick==		==Rückblick==
	[[Datei:Stand_Interlift_2003.jpg]]Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Spezial Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.		[[Datei:Stand_Interlift_2003.jpg\|thumb\|Gemeinschaftsstand der CANopen-Lift Gruppe auf der Interlift 2003]]
			Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Spezial Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.

	Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten Special Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.		Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten Special Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.

Joerg.Hellmich: /* Rückblick */ Grafik eingefügt

2012-07-05T12:20:36Z

Rückblick: Grafik eingefügt

← Nächstältere Version		Version vom 5. Juli 2012, 14:20 Uhr
Zeile 5:		Zeile 5:

	==Rückblick==		==Rückblick==
	Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Spezial Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.		[[Datei:Stand_Interlift_2003.jpg]]Auf der Interlift 2001 vereinbarten erstmals 20 mittelständische Hersteller von Komponenten für Aufzüge an einem offenen Standard für die Kommunikation auf dem CAN-Bus mitzuarbeiten. Anfang 2002 einigten sich diese Hersteller den schon seit vielen Jahren in der Automatisierungstechnik verbreiteten Standard 'CANopen' als Basis für die Entwicklung zu verwenden und um die benötigten Funktionen für Aufzüge zu erweitern. Innerhalb der CAN-in-Automation (CiA) wurde eine Spezial Interest Group (SIG) "Lift" gegründet. Aufgabe dieser SIG war die Überprüfung der vorhandenen Profile auf eine Eignung für den Aufzugbau sowie deren Erweiterung oder Neudefinition benötigter Funktionen.

	Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten Special Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.		Ergebnis dieser Arbeit war das im Juni 2003 veröffentlichte Applikationsprofil CiA-417 Lift Control (CANopen-Lift). In diesem Profil wurden viele 'virtuelle Geräte' eines Aufzugs, Objekte und Nachrichten dieser virtuellen Geräte sowie technische Randbedingungen (Baudraten, Dienste, Pinbelegungen von Steckverbindern usw.) festgelegt. Auf der Interlift 2003 wurden auf einem von der dafür gegründeten Special Marketing Group Lift entwickelten Gemeinschaftsstand, von mehren Herstellern die ersten Prototypen von Komponenten ausgestellt.