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 macht 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 CiA-417 Mapping, das aus dem Geräteprofil CiA-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 CiA-402 die Bedeutung des Objekts offengelassen wurde. -- HBa 21.08.2007 14:00

Ich finde den erweiterten 2. Vorschlag auch gut. Bei der Erweiterung vom 21.08. von Herr Bär hat sich m.E. ein kleiner Fehler eingeschlichen: es ist das '2.TPDO' - richtig? Ich fasse nochmals zusammen:

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)

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

3. RPDO: 'Target velocity' (velocity mode)

3. TPDO: 'Velocity actual value'

4. RPDO: 'Car position value' (kommt vom virtual device 'car position unit')

-- MForrer 24.08.2007 10:30

Von meiner Seite her kein Einspruch. Sollen wir das dann so implementieren? Wie sollen die COB-IDs der einzelnen PDOs lauten? --Dieffenb 11:24, 24. Aug. 2007 (CEST)

Die Vergabe der COB-IDS sollte kein Problem sein, aber für PDOs gibt es nicht genug Objekt-Einträge (siehe CiA 417, Anhang A). Z. Z. können nur je 4 TPDO/RPDO benutzt werden, für den 2. Vorschlag werden aber je 6 benötigt. Dazu müßte man die Tabelle im Anhang A neu gestalten oder ändern. Wenn man zu bestehenden Implementierungen kompatibel sein möchte, könnte man vielleicht die Sensoren (180h .. 1FFh) weglassen und stattdesen 16 weitere PDOs pro Aufzug definieren. --Hba 13:38, 24. Aug. 2007 (CEST)

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

Es gibt nur ein grundsätzliches Problem: das virtuelle Gerät 'Car position unit' wird in zwei Klassen C1 und C2 unterteilt. In der Klasse C1 gibt es keine Möglichkeit, die Auflösung zu ändern. Die dazu notwendigen Objekte sind in der Klasse C1 optional und in der Klasse C2 Pflicht. Um die Position in Millimeter zu erhalten, müßte man nur Klasse C2 Geräte einsetzen oder vorschreiben, was sicherlich nicht im Interesse der Allgemeinheit ist. -- hba 21.09.2007 16:00

Belassen wir dann, in Betracht der Tatsache dass wir auf Geber der Klasse C2 angewiesen wären, die Entfernungsangaben bei Inkrementen? --Dieffenb 11:33, 24. Aug. 2007 (CEST)

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.

PDO-Timing

Es sollte muss geklärt werden, wer wann welche PDOs sendet. Meine Vorschläge (Voraussetzung: Heartbeat während der Fahrt heruntergesetzt, Überwachung alleinig durch den Heartbeat):

• Fall 1: Control- und Statusword getrennt von Geschwindigkeitswerten und Control-Effort gemappt:
  • Die Steuerung sendet PDOs nur bei Statewechseln
  • Der Regler sendet das PDO mit dem Statuswort nur während der Fahrt bei Statewechseln oder auf Remote-Anfragen
  • Der Regler sendet das PDO mit den Rückgabewerten nur auf Remote-Anfragen und während der Fahrt, hier dann zyklisch. Zeit einstellbar über Inhibit Time.

• Fall 2: Control- und Statusword in gemeinsamem PDO mit Geschwindigkeitswerten und Control-Effort gemappt:
  • Die Steuerung sendet PDOs nur bei Statewechseln
  • Der Regler sendet das PDO nur auf Remote-Anfragen und während der Fahrt, hier dann zyklisch. Zeit einstellbar über Inhibit Time.

--Dieffenb 09:04, 24. Aug. 2007 (CEST)

Ich bin der Meinung, dass PDO's nur bei Änderung geschickt werden sollen (von der Steuerung und vom Umrichter). Der Umrichter soll die PDO's auch schicken, wenn sich was ändert, wenn er nicht fährt. Mit Inhibit sollte man sich vor einer 'PDO-Flut' wehren können. Ich bin grundsätzlich gegen zyklische PDO's, die als 'Heartbeat-Überwachung' missbraucht werden. Dafür gibt es das kürzere CAN-Telegram 'Heartbeat'.--MForrer 10:30, 24. Aug. 2007 (CEST)

Können wir dann folgendes festhalten?:

Für die TPDOs gilt:

• Transmission Type: 255
• Inhibit Time: 200 (*100µs)
• Event Timer: 0 (keine zyklischen Übermittlungen)

--Dieffenb 11:29, 24. Aug. 2007 (CEST)