Das Studentenpraktikum war mal für eine Mini-Drehmaschine vorgesehen, stattdessen wurde ein Aufzug-Modell mit 2 Motoren (Hebezug und Tür) und vier Tasten realisiert.
Ziel ist das Kennenlernen von Frequenzumrichtern, erst mal im Kleinformat. Trotzdem hat der ARS2302 bereits eine Drehstrom-Speisung ohne Sternpunkt.
Derzeitiger Stand: Steuerung in LabVIEW funktionstüchtig und vorführbar. Vollständige automatische Funktion der Etagenrufknöpfe, revidierbar in der GUI. LabVIEW-Programm ist übersichtlich, dokumentiert und archivierbar. Keine Dokumentation für die Versuchsdurchführung. (Nach meinen Vorstellungen geht diese auf das Programm ServoCommander ein, dann die Schnittstellen-Betrachtung mit Beispiel-Übertragungen im LabVIEW-Programm, schließlich auf die Realisierung eines Automaten in LabVIEW.)
Ursprünglich sollte zur Kommunikation RS-485 verwendet werden. Ich halte das im Zeitalter von Industrie 4.0 für total rückschrittlich! Wenn sich schon Sensoren und Aktoren gegenseitig erkennen sollen, dann schon mit einem PnP-fähigen Anschluss. Daher ist jetzt alles lückenlos auf USB getrimmt. Am schwierigsten war das für den ARS2003 umzusetzen. Viel zu teuer gekaufte USB-zu-RS-485-Konverter (von NI) gammeln nun im Schrank herum und warten auf den Sankt-Nimmerleinstag. Ausgerechnet der ARS2003 ließ damit überhaupt nicht zur Kommunikation bewegen, also völlig sinnlos.
Die Referenztaster können sowohl mit dem NI USB-6008 als auch mit den jeweiligen Steuerungen abgefragt werden. Die Doppelbelegung rührt daher, weil das nicht von vornherein klar war. Werden weitere USB-6008-Anschlüsse gebraucht, sollte man sich hier bedienen.
Hier können die einzelnen LabVIEW-Unterprogramme (für das Terminalprogramm) an Bildern studiert werden. Sämtliche GUI-Elemente sind aus der Bibliothek „System“, damit das laufende LabVIEW-Programm (ein Dialog) nicht allzu sehr wie ein Fremdkörper in der Windows-Umgebung aussieht. Abgesehen vom Fehler-Cluster kann man's nur noch am Fenster-Symbol (oben links) erkennen, dass es LabVIEW ist. ENTER drückt den Knopf „Abfragen“ und ESC sowie Alt+F4 beendet das Programm.
Für den PC-Zugriff (vorzugsweise LabVIEW) zum Umrichter ARS2302 standen einige Möglichkeiten offen:
Der Umrichter „vergisst“ die Einstellung zur „Reglerfreigabe über DIn5 und Parametrierschnittstelle“ nach dem Ausschalten trotz SAVE!-Kommando. Per USB-Paketschnüffler wurde das zugehörige undokumentierte Kommando-Objekt 0314x herausgefunden, was während DIn5 = LOW auf 00000001 gesetzt werden muss.
Der Umrichter verlangt undokumentierte Vorhaltezeiten für Din5 und Din4, bevor pegelabhängige Kommandos erwartungsgemäß funktionieren, hier das Quittieren von Fehlern (DIn5 = LOW) und die Reglerfreigabe (DIn5 = HIGH). 50 ms scheinen zu genügen.
Das Lesen des Lagesollwertes OR:01AA liefert nicht die Zielposition, sondern annähernd den Istwert. Istposition OR:01AB funktioniert.
| Nummer | Zustand | Ereignis | Aktion | Übergang zu |
|---|---|---|---|---|
| 0 | Einschaltzustand | |||
| Automatische Lageerkennung | → je nach Lage | |||
| 1 | Tür geöffnet | Zielanforderung = Istposition | Timeout zurücksetzen Zielanforderung := NaN Tasten-LED ausschalten | → 1 |
| Timeout | Tür schließen | → 2 | ||
| Zielanforderung ≠ NaN | ||||
| 2 | Tür schließt | X-Endschalter 1 erreicht | Tür Halt | → 3 |
| Zielanforderung = Istposition | → 5 | |||
| Kollision (Lichtschranke o.ä.) | ||||
| Timeout | → 255 | |||
| 3 | Tür geschlossen, Fahrkorb steht | Zielanforderung = Istposition | Tür öffnen | → 5 |
| Zielanforderung ≠ NaN | Fahrkorb Zielfahrt | → 4 | ||
| 4 | Fahrkorb in Bewegung | Zielanforderung = Istposition | Tür öffnen | → 5 |
| Timeout | Fahrkorb Halt | → 255 | ||
| Z-Endschalter betätigt | ||||
| 5 | Tür öffnet | X-Endschalter 2 erreicht | Tür Halt | → 1 |
| Timeout | → 255 | |||
| 255 | Fehler | Benutzereingriff | → je nach Benutzer | |
| Nummer | Fahrtrichtung | Setze Zielanforderung auf | Neue Fahrtrichtung |
|---|---|---|---|
| 0 | keine | Nächstgelegenes Ziel von Istposition | Keine Ziele → 0 Ziel = Istposition → Ziel setzen, 0 (öffnet Tür) Ziel > Istposition → Ziel setzen, 1 Ziel < Istposition → Ziel setzen, 2 |
| 1 | aufwärts | Kleinstes Ziel ≥ Istposition + Bremsweg | Keine Ziele → 0 Kein geeignetes Ziel → 2 → Ziel setzen, 1 |
| 2 | abwärts | Größtes Ziel ≤ Istposition - Bremsweg | Keine Ziele → 0 Kein geeignetes Ziel → 1 → Ziel setzen, 2 |
Die LabVIEW-Funktion „Maximum + Minimum suchen“ bei Double-Vektor als Eingang liefert beim Vektor komplett aus NaN den Wert 0. (Als Minimum, sicherlich auch als Maximum.)
LabVIEW 2010 unterstützt nicht das asynchrone Starten von typisierten VIs. Sondern nur (immerhin) untypisiert. Hätte ich mal wissen müssen, aber der Umstieg zu LabVIEW 2017 ist eh' fällig.
Das war für das Unterprogramm Liftboy.vi vorgesehen, welches parallel instantiiert werden sollte. Zur gegenseitigen Synchronisierung der beiden Threads beim Hardware-Zugriff spielt die in LabVIEW normalerweise aktivierte Funktion „Synchroner VI-Aufruf“ eine wichtige Rolle! Mit „Reentrantes VI“ müssten alle Hardware-Zugriffe mühevoll per Semaphore serialisiert werden, damit das Hauptprogramm weiterhin Statuswerte auslesen kann.
Da (Kommando-)Schreiben zu und (Status-)Lesen von einer Schnittstelle logisch zusammengehören (Transaktions-Prinzip), sind genau jene VIs nicht-reentrant. Die verschiedenen Schnittstellen könnten jeweils parallel arbeiten (1 Thread pro Schnittstelle), programmatisch ergibt sich hier allerdings kein Vorteil.
Das Unterprogramm Liftboy.vi arbeitet via zyklischem Aufruf im Timeout-Ereignis des Hauptprogramms.
Im Gegensatz zu echten Aufzügen verlischt die Tasten-Lampe erst nach dem vollständigen Öffnen der Tür. Das ist derzeit so im Programmkode eingebaut und eine Verhaltensänderung ist mit einigen Konsequenzen bei der Ereignisverarbeitung verbunden.
Die Etagenruftasten kann man sich im Fahrkorb mit denen an den Türen (außen) parallelgeschaltet vorstellen. Dies wird so bei einfachen Aufzügen praktiziert, häufig in Wohngebäuden.
Bei Aufzügen im gewerblichen Umfeld, wie etwa hier in der Universität, befinden sich an jeder Tür (außer im Keller und in der obersten Etage) zwei Tasten, mit dem die gewünschte Fahrtrichtung angegeben werden kann bzw. muss. Dann hält der Fahrkorb nur dann, wenn es in der gewünschten Fahrtrichtung weitergeht, sonst fährt er durch. Eine Parallelschaltung ist dann nicht mehr möglich.
Noch komplexer sind kombinierte Aufzugssteuerungen, also mehrere Fahrkörbe mit gemeinsamer Ruffunktion. Siehe Zwillings-Aufzüge im Weinhold-Bau sowie in den Studentenwohnheimen.
Richtungsgebundene Anforderungen lassen sich in das LabVIEW-Programm noch recht einfach einbauen, indem pro Etage zwei Rufknöpfe vorgesehen werden (2D-Array statt Vektor). Mit etwas Logik lassen sich die Zielknöpfe im Fahrkorb mit den Außentasten verknüpfen. Klar, im Keller und im Penthouse gibt's nur einen Knopf.
| Richtung | Z-Lage | Ereignis | Reaktion |
|---|---|---|---|
| keine | Auf gleicher Etage | Knopf aufwärts | Tür öffnen, Knopflicht aus (beide) |
| keine | Auf tieferer Etage | Knopf aufwärts | Aufwärtsfahrt aktivieren, Fahrkorb holen, Tür öffnen, Knopflicht aus (beide) wenn inzwischen keine weitere Anforderung |
| aufwärts | Auf höherer Etage | Knopf aufwärts | Nichts passiert! Nur das Knopflicht geht an |
| abwärts | Auf höherer Etage | Knopf aufwärts | Nichts passiert! Nur das Knopflicht geht an |
| aufwärts | Auf tieferer Etage | Knopf aufwärts | Zwischenhalt einschieben oder weiter fahren als bisher |
| aufwärts | Auf tieferer Etage | Knopf im Fahrkorb | Zwischenhalt einschieben oder weiter fahren als bisher |
| aufwärts | Auf höherer Etage | Knopf im Fahrkorb | Nichts passiert! Nur das Knopflicht geht an |
Analogievorstellung (als Gedankenstütze zur Programmierung): Ein Bus fährt eine Straße rauf und runter. Ich als Fahrgast kann mich nur auf eine Seite der Straße an eine Bushaltestelle stellen. Sieht mich der Busfahrer früh genug (Analogie: Bremsweg), kann er anhalten und mich mitnehmen. Auf diese Weise würde der Bus unzählige Leerfahrten machen, immer bis ans Streckenende (wie im richtigen Linienverkehr und beim Paternoster). Um diese Leerfahrten zu vermeiden, „sieht“ der Busfahrer zusätzlich „aus der Ferne“, ob überhaupt Fahrgäste voraus sind. Er muss nur dann weiter vorwärts fahren, wenn noch jemand da ist oder jemand im Bus sitzt mit einem Ziel voraus. Ansonsten wendet er und „sieht“ in der anderen Richtung. Ist auch dort niemand, bleibt er stehen und sieht in beide Richtungen. Erst wenn jemand auftaucht, setzt er sich in Bewegung. In diesem Fall nach dem Prinzip „Wer zuerst kommt wird zuerst bedient“ auch wenn die Strecke weiter ist. Bei zweien in verschiedenen Richtungen gleichzeitig orientiert sich die derzeitige Implementierung nach der kürzesten Entfernung. Viele Aufzüge und auch Busfahrer fahren nach langem Nichtstun zu ihrem Heimathafen. Beim Aufzug ist das meist das Erdgeschoss.
Busfahrer, jedoch (IMHO) nicht Aufzüge fahren an Haltestellen mit Wartenden durch, wenn der Bus voll ist und niemand aussteigen will (also Platz machen kann).
Bisher nicht gesehen aber sinnvoll ist es, Anforderungen aufzukündigen.
Da die sehr lange Vertikalspindel zum unangenehmen Schlackern neigt, wurde diese durch einen Zahnriemen ersetzt, der von einem zweistufigen Untersetzungsgetriebe angetrieben wird. Es hat immer noch genügend Selbsthemmung, um den Absturz des Fahrkorbs zu verhindern. Auch die Führung wurde ersetzt; diese erfolgt nun mithilfe der Nuten des Boschprofils.
