(10.09.2012 08:36 )FelixG schrieb: [ -> ]Hast du das so gemeint mit Zahlen anschliessen?
Ja, und Entschuldigung, ich hatte das nicht bemerkt, dass Du das in etlichen Cases schon so gemacht hattest.
Es wurde ja hier schon gesagt: Das Programm schreit nach einer State-Machine statt der jetzt verwendeten Vielfach-Verschachtelung Das ist nichts Kompliziertes, die Umstellung wäre in weniger als einem Tag gemacht, und an dem Ergebnis würdest auch Du deine Freude haben.
Hallo Lucki,
kein Problem.
Ich werde mich jetzt an die Umstellung zur State-Machine machen. Ich melde mich wieder falls ein Problem auftaucht oder wenn ich fertig bin.
Gruss Felix
Hallo Lucki,
ist das Programm deiner Meinung nach jetzt besser?
Ich hoffe ich habe das mit der State-Machine richtig verstanden. Über Verbesserungsvorschläge wäre ich auf jeden Fall dankbar
Gruss Felix
Hallo Felix,
Zitat:ist das Programm deiner Meinung nach jetzt besser? Ich hoffe ich habe das mit der State-Machine richtig verstanden. Über Verbesserungsvorschläge wäre ich auf jeden Fall dankbar
Na ja.
Folgendes:
- viel zu viele lokale Variablen. Nutze Drähte stattdessen!
- viel zu viel kopierte Strukturen. Diese ganzen duplizierten Case-Strukturen... Warum die Unterscheidung in "Rauf" und "Runter"-Case, wenn der einzige Unterschied in einem "+1" oder "-1" besteht?
- man sollte den State einer Statemachine überall durchverdrahten. Wenn man zwischendurch auf "default"-Werte zurücksetzt, stürzt plötzlich der Lift ab...
- nimm (typdefinierte) Enums statt Strings zur State-Auswahl. Dann kannst du prima auf (leere) "Voreinstellung"-Cases verzichten...
- RubeGoldberg: es gibt fertige Funktionen wie "+1" und "-1".
Siehe Anhang für ein paar Veränderungen. Es gibt noch viel mehr zu vereinfachen...
Guck dir die Eventstruktur an, wie dort die Schalter ausgewertet werden!
Hallo GerdW,
Vielen Dank für die vielen Verbesserungsvorschläge.
Ich habe das Programm jetzt nach bestem Wissen und Gewissen angepasst und wollte jetzt noch fragen ob ich das mit den Enums richtig realisiert habe. Ich habe vorher noch nie mit Enums gearbeitet und bin mir daher nicht sicher ob ich es richtig verstanden habe.
Gruss Felix
Hallo Felix,
das sieht doch schon deutlich besser aus. Das mit den Enum hast du gut gemacht, du solltest nur noch eine Typdefinition dafür anlegen.
Nächster Schritt:
Die aktuellen State-Daten (aktuelle Position, Zielposition(en), etc.) würde ich auch noch ein einem (typdefinierten) Cluster zusammenfassen. Dann könnte man nämlich die ganzen einzelnen Cases (für jede Etage extra) zusammenfassen: man fährt dann einfach von aktueller Position zur Zielposition.
Dann brauchst du nämlich nur noch 2 subVIs statt der ganzen Cases:
- ein subVI fährt den Lift zur Zielposition
- ein subVI generiert die Anzeigedaten: aktuelle Position, Etagenname, "Etagenlämpchen"
Hallo,
Ich komme gerade beim anlegen der Typdefinition des Enum nicht weiter.
Wie funktioniert das genau?
Als erstes drücke ich auf Datei -> Neu. Danach auf Benutzerdefiniertes Element und schalte dann von Element auf Typ-Def. um.
Was ich danach machen muss ist mir ein Rätsel
Was ist überhaupt der Vorteil bei Typdefinierten Enum, Cluster usw.?
Gruss Felix
Hallo Felix,
Zitat:Was ist überhaupt der Vorteil bei Typdefinierten Enum, Cluster usw.?
Du legst einmal eine Typdefinition an. Wenn du diese Typdefinition später einmal anpassen musst, wird dies automatisch an jeder Stelle im BD, wo du diese Typdefinition verwendest, übernommen.
Jetzt stell dir mal vor, du hast einen Cluster mit mehreren Einzelwerten. Dieser wird durch mehrere subVIs durchgeschliffen. Jetzt fällt dir auf, dass du noch ein/zwei Werte im Cluster nachtragen musst. Du wirst dich dann freuen, in wievielen subVIs du die gleiche stupide Anpassung des Clusters vornehmen darfst, weil du vorher zu faul warst eine Typdefinition anzulegen und zu verwenden...
Hallo zusammen,
erstmal danke für die schnellen Antworten.
Jetzt verstehe ich auch für was das ganze gut ist und werde jetzt mal meine Faulheit besiegen und die Typdefinitionen anlegen.
Danke nochmal und Gruss
Felix