Diskussion:Drive Unit

PDO-Mapping

Mapping gemäss aktuellem Stand CiA-417:

1. RPDO: 'Controlword' und 'Target position'
1. TPDO: 'Statusword' und 'Control effort'
2. RPDO: 'Controlword' und 'Target velocity'
2. TPDO: 'Statusword' und 'Velocity actual value'
3. RPDO: 'Car position value' (kommt vom virtual device 'car position unit')

Das PDO-Mapping ist in meinen Augen nicht sehr sinnvoll gelöst. 'Statusword' und 'Controlword' sind in zwei PDOs gemapped und müssen je nach aktuellem Mode ('profile position mode' oder 'velocity mode') aktiviert bzw. inaktiviert werden. Dieses Umschalten im 'mode operational' halte ich für sehr gefährlich, da der Zeitpunkt für das Umschalten nicht spezifiziert ist. Im Zeitraum zwischen Umschalten (SDO-Zugriff auf 'Modes of operation' bis Aktivieren/Deaktivieren PDOs) kann es zu unkontrollierten PDOs (unkontrolliertes Verhalten) kommen.

Deshalb hier meine zwei alternativen Vorschläge:

Vorschlag 1:

---

1. RPDO: 'Controlword' und 'Modes of operation'
1. TPDO: 'Statusword' und 'Modes of operation display'
2. RPDO: 'Target position' und 'Target velocity'
2. TPDO: 'Velocity actual value'
3. RPDO: 'Car position value' (kommt vom virtual device 'car position unit')

Vorschlag 2 (PDOs für 'profile position mode' und 'velocity mode' getrennt):

---

1. RPDO: 'Controlword' und 'Modes of operation'
1. TPDO: 'Statusword' und 'Modes of operation display'
2. RPDO: 'Target position' und 'profile velocity' (profile position mode)
3. RPDO: 'Target velocity' (velocity mode)
3. TPDO: 'Velocity actual value'
4. RPDO: 'Car position value' (kommt vom virtual device 'car position unit')

Vorschlag 2 halte ich auch für sinnvoll, vorausgesetzt für den 'profile position mode' hat der Antrieb das TPDO mit dem 'Control effort' (siehe unten). Man könnte auch ein TPDO mit 'Velocity actual value' und 'Control effort' definieren, da auch im 'profile position mode' die aktuelle Geschwindigkeit interessant ist. Im 'velocity mode' könnte das Objekt 'Control effort' dann den relativen Verzögerungsweg [in mm] anzeigen. -- HBa 21.08.2007 08:00

3.TPDO: 'Velocity actual value' und 'Control effort'

'Target position' und 'Target velocity' in getrennten RPDOs definiert und 'Velocity actual value' und 'Control effort' im selben RPDO definiert? Man sollte unserer Meinung nach 'Target position' und 'Target velocity ebenfalls im selben PDO definieren. (wie in Vorschlag 1). Für den Position Mode können wir gerne noch die aktuelle Geschwindigkeit mit aufnehmen. Ist für den Velocity Mode der Bremsweg von Nöten? Wenn ja, sollte dieser dann nicht in der selben "Einheit" wie alle anderen Maße gesendet werden?dieffenb 21.08.2007 12:00

Es ist immer nur ein Mode aktiv, entweder 'profile position mode' oder 'profile velocity mode'. Deshalb mach es schon Sinn, für jeden Mode die PDOs festzulegen. Es kann sogar sein, das Anlagen nur den 'profile velocity mode' nutzen (daher auch das DSP-417 Mapping, das aus dem Geräteprofil DSP-402 übernommen wurde). Gegen 'Velocity actual value' und 'Control effort' im selben PDO spricht auch nichts, da das Objekt 'Control effort' keinem Mode zugeordnet ist und im Profil DSP-402 die Bedeutung des Objekts offengelassen wurde. -- HBa 21.08.2007 14:00

Control effort

Über das Objekt 'Control effort' liefert der Umrichter im 'profile position mode' den Verzögerungspunkt (aktueller Bremsweg) zurück. Im DCP-Protokoll wird diese Information dazu verwendet, um zu ermitteln, ob einem Aufzug eine neue 'target position' mitgeteilt werden kann.

Bei CiA-417 gibt es ein komfortables Handshake über Bit 12 des Statusword:

Beispiel-Ablauf:

1. Kabine ist in Etage 1, Kommando Etage 5
2. Kabine fährt nach Etage 5 (target position: Etage 5)
3. irgendwann kommt Kommando Etage 3
4. falls aktuelle Position kleiner als Etage 3: Steuerung schickt an Umrichter neue target position Etage 3
5. falls der Umrichter bremsen kann (Bit 12 im Statuswort), weiss die Steuerung, dass die Etage 3 angefahren wird, sonst hat es für Etage 3 nicht gereicht

Da bei CiA-417 im Gegensatz zu DCP mehrere Kommunikationsteilnehmer am Bus hängen, muss bei der Spezifikation von CiA-417 dringend berücksichtigt werden, dass die Buskommunikation auf ein Minimum gehalten wird! Ein zyklisches Übertragen von 'Control effort' würde demnach den Bus belasten.

Das Handshake über Bit 4 Controlword und Bit 12 Statusword dient nur dazu, dem Antrieb eine neue Zielposition zu übergeben. Bestätigt der Antrieb mit Bit 12 im Statuswort die Zielposition, so wird diese auch angefahren, d. h. die Steuerung hätte keine Möglichkeit festzustellen, ob ein Halt an der Zielposition möglich wäre. Das ist aber Grundvoraussetzung für diverse Gruppenalgorithmen. Das Objekt 'Control effort' ist zwingend für den Antrieb (relativ oder absolut), damit die Steuerung die Möglichkeit hat, die dynamischen Fahreigenschaften der Aufzugsanlage zu optimieren.

Das Objekt 'Control effort' kann sich nur beim Losfahren ändern (und zwar nur so oft wie eine neue geänderte Position vorliegt). Während der Konstantfahrt ändert sich der 'Control effort' nur mit einer neuen Zielposition. Verzögert der Antrieb, braucht sich der 'Control effort' nicht mehr zu ändern (siehe Abbildung auf der Seite Drive Unit unten). Jedes TPDO hat den Parameter 'Inhibit timer', mit dem sich die minimale Pause zwischen zwei Sendungen parametrieren lässt. So kann die Buslast beeinflusst werden. Für das Objekt 'Velocity actual value' muss der Inhibit timer im Event-Mode sowieso verwendet werden, da die interne Geschwindigkeitserfassung des Antriebs relativ oft erfolgt. -- HBa 21.08.2007 08:00

Einheit 'car position unit'

Die Einheit des virtual device 'car position unit' kann in diversen Einheiten (Inkremente, Millimeter, ...) dem 'car drive unit' mitgeteilt werden. Die genaueste Einheit wäre Inkremente, da von den meisten Positionsgebern mehrere Inkremente pro Millimeter erwartet werden können.

Für einen Aufzug stellt sich jedoch die Frage, ob Millimeter nicht genügend genau sind. Das hätte den Vorteil, dass sich die Konfiguration der 'car drive unit' vereinfachen würde. Zudem sind Positionswerte auf dem Bus besser interpretierbar.

Deshalb ein möglicher Vorschlag, wie das virtual device 'car position unit' konfiguriert werden könnte:

"Die car position unit muss so konfiguriert werden, dass der 'car position value' in Aufwärtsrichtung kontinuierlich steigend ist und keine Sprünge und Überläufe aufweist. Die Einheit des car position value ist Millimeter"

Der Positionswert des Positionsgebers sollte keine Einheit haben. Man verschenkt damit Auflösung und würde sich zusehr einschränken, vorallem da es auch andere Anwendungen am Bus gibt, die den Positionswert verarbeiten. Damit der Antrieb dem Positionswert eine Einheit zuordnen kann, ginb es das Objekt 'Position encoder resolution'. Wobei man den Subindex 2 in 'Umfang bzw. Weg in mm' umdefinieren müsste.

Gerade beim Einfahren und kurzen Wegen ist es für den Antrieb besser, eine höhere Auflösung als Millimeter zu haben.

Die Konfiguration vereinfacht sich nicht und für die Diagnose und Busaufzeichnung ist es ebenfalls belanglos.

Die Richtungsvorgabe des Positionssystems muß auch nicht in der Spezifikation stehen, das ist Sache des Anwenders. -- HBa 21.08.2007 08:00

Für eine Nachvollziehbarkeit würde sich eine Einigung auf SI Einheiten anbieten. Wenn eine bessere Auflösung nötig ist, könnte man ja auch auf Zehntels Millimeter gehen. dieffenb 21.08.2007 12:00

Schützüberwachung

Fahrtschütz und Bremsschütz können entweder von der Liftsteuerung oder aber vom Umrichter angesteuert und überwacht werden.

Es gilt: wer ansteuert, der überwacht! (Beispiel: steuert der Umrichter die Schützen an, ist er auch für die Überwachung zuständig).

Ein Fehler in der Schützüberwachung soll mittels Emergency-Nachrichten den restlichen Kommunikationsteilnehmern mitgeteilt werden. Zudem führt der Fehler im Umrichter zu einem Statewechsel 'fault reaction active'.

Die Schützüberwachung stellt eine sicherheitsrelevante Funktion dar. Da die Schütze in der Sicherheitskette sitzen, erfolgt die Ansteuerung auch nicht alleinig durch den Umrichter. Sollte diese Überwachung nicht in der Steuerung bleiben? Die Schütze werden vom Regler immer überwacht, allerdings nur für interne Zwecke. dieffenb 21.08.2007 12:00

Heartbeat-Überwachung

Die Überwachung der Kommunikation zwischen Liftsteuerung und Umrichter geschieht über Heartbeat. Dazu muss im Umrichter sowohl ein 'Heartbeat-Consumer' (Erkennen Ausfall der Liftsteuerung) als auch ein 'Heartbeat-Producer' (Erkennen Ausfall des Umrichters) eingerichtet werden.

Es ist sinnvoll, vor einem Positioniervorgang die Heartbeat-Zeit zu verkleinern (schnellere Heartbeat-Überwachung) und nach dem Positioniervorgang wieder zu vergrössern (Verkleinerung der Buslast).

Ein Heartbeat-Timeout führt im Umrichter zu einem Nothalt.