Diskussion:Drive Unit
Hier kann die Diskussion zur Ansteuerung der Umrichter stattfinden.
PDO-Mapping
Mapping gemäss aktuellem Stand DSP-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 PDO's 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 PDO's) kann es zu unkontrollierten PDO's (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 (PDO's 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')
Control effort
Über das Objekt 'Control effort' liefert der Umrichter im 'profile position mode' den Verzögerungspunkt (aktueller Restweg) zurück. Im DCP-Protokoll wird diese Information dazu verwendet, um zu ermitteln, ob einem Aufzug eine neue 'target position' mitgeteilt werden kann.
Bei DSP-417 gibt es ein komfortables Handshake über Bit 12 des Statusword:
Beispiel-Ablauf:
- Kabine ist in Etage 1, Kommando Etage 5
- Kabine fährt nach Etage 5 (target position: Etage 5)
- irgendwann kommt Kommando Etage 3
- falls aktuelle Position kleiner als Etage 3: Steuerung schickt an Umrichter neue target position Etage 3
- 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 DSP-417 im Gegensatz zu DCP mehrere Kommunikationsteilnehmer am Bus hängen, muss bei der Spezifikation von DSP-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.
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"
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'.
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.