Struktur verbesserungswürdig?

Guten Morgen GerdW,
Ja die nutze ich sehr gerne. Ich habe versucht sie gering zu halten aber dabei traten dann verstärkt Fehler auf, welche ich mit Propertynodes beseitigen konnte.
Die Buttons sind da ein gutes Beispiel. Die werden soweit ich das verstanden habe abgefragt, wenn die Schleife startet. alles was danach kommt muss dann direkt verbunden werden. Möchte ich den Zustand Ändern von true auf fals oder andersherum geht das mit den Shiftregistern problemlos.
Will ich aber in ner anderen Eventstrucktur die Buttons abfragen, um die aktivierten Buttons herauszufinden, geht es nicht. Er fragt die Buttons nicht ab, obwohl zum linken Shiftregister eine Verbindung besteht.
Kaum hatte ich hier ein Propertynode gesetzt war das Problem gelöst.
Das hatte ich an super vielen Stellen.

Das Raceconditionproblem sehe ich und habe keine gute Lösung dafür. Es handelt sich um einen Indicator, dessen Wert ich abfragen möchte.
Mir fällt hier nur eine Enumerierte Casestruktur ein, die sich vermutlich Statemachine schimpft.
Das verschachtelt das Programm immer weiter. Das wollte ich vermeiden, sollte es möglich sein.

Das ist was ich meinte mit, ich habe keine Ahnung wie man hier Strukturiert sinnvoll aufbaut.

Zitat:Und die STOP-Funktion mitten im Programm ist auch ein Zeichen einer eher schlechten Programm-Struktur…

Sind damit die ganzen Stop-Value-Propertynodes in den For-loops gemeint?
Das ist ein verzweifelter Versuch die Stopfunktion ans laufen zu bekommen. Das Programm soll die Messung ordentlich abbrechen können ohne das sie noch nachläuft.
Jetzt geht es nur nicht so schnell, weil das Klimaschrank vi so lange braucht. Das wundert mich aber auch überhaupt nicht... Das sieht schlimmer aus als bei mir. Vielleicht gibt es nen neuen Treiber dafür. Ich hab das Alte von meinem Kollegen übernommen. Oder ich muss da selber ran, sobald das Programm erstmal läuft. Auslernen tu ich hier sich nicht so schnell.


Danke schon mal. ich weiß, dass es mit Bildern mehr als ungünstig ist.

Gibt es eigentlich irgendwo ein Beispiel für größere Programme? Wo man mal sinnvolle Struktur sehen kann? Sowas würde mich helfen. Mini Beispiele reichen mir oft nicht.

Anzeige

Hallo Minako,

Zitat:Das Raceconditionproblem sehe ich und habe keine gute Lösung dafür.

Wie in meiner letzten Message schon geschrieben: nimm mehr Draht!

Zitat:Sind damit die ganzen Stop-Value-Propertynodes in den For-loops gemeint?

Nein, ich meine die STOP-Funktion unten mittig im Bild…

Zitat:Gibt es eigentlich irgendwo ein Beispiel für größere Programme? Wo man mal sinnvolle Struktur sehen kann?

LabVIEW bringt Beispiel-VIs mit - und auch Beispiel-Projekte. Und dort sind dann auch Beispiele für diverse Programmstrukturen (Statemachine, Producer-Consumer, etc.) dabei…

Moin GerdW,

Zitat:Wie in meiner letzten Message schon geschrieben: nimm mehr Draht!

   
Wie im neuen Bild zu sehen, habe ich bissi was geändert. Die Palette an propertynodes an der Stelle kann ich glaube ich nicht ändern aber sie sind um die Hälfte reduziert, weil ich sie aus der Casestruktur rausgezogen habe. Da geht es um die Bearbeitbarkeit von Frontpanelelementen. Das geht soweit ich weiß nur über die Propertynodes.

Ich habs noch nicht im Feld getestet aber ich denke es geht so wie es jetzt verdrahtet ist mit dem EIngang der Casestruktur. Immerhin gibt die Ungleichfunktion das Gleiche Ergebnis raus wie "DAQ970A ausgewählt".

Zitat:Nein, ich meine die STOP-Funktion unten mittig im Bild…

   
Das gelb markierte?
Geht es nur darum, dass es von der Position her mittig ist oder was ist das Problem hierbei?
Immerhin wird es ausschließlich bei Betätigung des "Stop" Buttons aktiviert. Von alleine wird es nicht angesprochen.
Es soll ein besserer Ersatz zum roten Knopf von Labview selbst sein, weil ich hier festlegen kann, was vorher noch ausgeschaltet werden muss, wenn die Messung abgebrochen werden soll.

Zitat:LabVIEW bringt Beispiel-VIs mit - und auch Beispiel-Projekte. Und dort sind dann auch Beispiele für diverse Programmstrukturen (Statemachine, Producer-Consumer, etc.) dabei…

Dann suche cih das mal. Ich dachte es sei immer nur ein Beispiel für ein bestimmtes Element und nichts für größere Projekte.

Danke.

(23.05.2024 13:41 )Minako schrieb:  Jetzt ist noch die Geräte suchen Funktion enthalten, welche auch ein paar Sekunden dauert.
Die müsste auch noch raus. Dafür ne neue Schleife zu öffnen sehe ich irgendwie als blöd an.
...
Also: Wenn ich ein Event über den Button starte und dieses zu lange dauert, wie mache ich das?

Queued Message Handler Aufbau, meist baue ich mir einfach eine Queue auf mit nem Cluster als Eingang: Befehlsstring und Datenvariant, lässt sich einfach aufsplitten (hab ich von DQMH abgeguckt). Du kannst auch eine Messerfassung in eine weitere Schleife machen und von dort die Daten dann (per Queue) in die MHL schicken und verarbeiten.
Ich hab dir mal nen Miniprogramm als Beispiel angehängt, versuche doch mal eine Zufallszahl in einer (gebremsten) Schleife zu generieren, an die MHL zu schicken und mit 'laden' den aktuellen Wert anzuzeigen, das geht alles ohne eine einzige Lokale Variable.

Zitat:Der Stopbutton funktioniert zwar aber braucht recht lange, wenn der Klimaschrank genutzt wird. Das führt leider gern zur ungedult von Kollegen, die dann versuchen erneut drauf zu klicken. Da hängt sich dann gern das Programm auf. Das Gleiche bei Geräte suchen. Wenn man zu schnell versucht andere Einstellungen vorzunehmen, hängt es sich auf. Liegt bestimmt an der Struktur.

LabVIEW arbeitet alles ab was es kann, sprich überall wo dein Stop schon ausgefüht ist, das funktioniert nicht mehr, deine Suche läuft aber noch, diese akzeptiert aber keine Eingabe.
Eine einfache Lösung blende ein Indicator ein, der die info gibt, es wird beendet.. Das musst du aber da machen, was auch abgearbeitet wird (meist in der Eventstruktur)

Zitat:Es geht nicht darum mein Programm im speziellen zu debuggen. Es geht um eine allgemeine Erklärung zum ordentlichen und platzsparenden Aufbau von größeren Programmen, wenn man zu viele Eingabe Variablen an, welche man an den unterschiedlichsten Stellen benötigt. (Mein Lieblingsbaustein ist der Propertynode)

Passende Programmstruktur, auf die Aufgebaut wird von vornherein. Vorhandene Strukturen verwenden (Beispiele) und anpassen, man muss sich auch zwingen die Struktur beizubehalten. Kann aber auch mal nach hinten losgehen, wenn man halb Fertig ist und dann die Struktur nicht mehr passt -.-' Vieles kommt aber mit der Zeit, am meisten habe ich gelernt von Delacor QMH, was ich immer noch sehr gerne verwende, nimmt einem die Arbeit drumherum ab.

MfG Timo

Hi TPunktN,

vielen Dank. Das ist jetzt wieder sehr viel Neues. Ich habe noch nie eine Grün/rote Case struktur gesehen oder etwas mit Variant zu tun gehabt.
Da werde ich erstmal bissi was zu lesen müssen, bevor ich deinen Aufbau auf mein Projekt beziehen kann.

Das mit dem Anzeige schalten kann ich auch einfach an den Beginn der Stopschleife setzen. Das wird dann durch den Abbruch wieder entfernt. Kann ich sich auch noch verkomplizieren durch Anzeigespielereien wie ein sich füllender Balken für jede Abgeschlossene Aktion. So lerne ich die ganze Zeit Bauteile kennen.

Ich hab mir mal den Example finder angeschaut und der is nicht so easy wie ich gehofft hatte. Super viele Beispiele und auch eines zu einer guten Struktur war dabei.
Aber mir reichts noch nicht. Muss mal weiter suchen.
Bzw. mich jetzt mal mit Abfragen und Variants beschäftigen.
Danke.

Mir stellen sich aber noch zwei Fragen.
Wenn ich alle Elemente des Frontpanels in ein Cluster setze, kann ich diese dann frei anordnen wie es mir spaß macht? Ich muss das mal ausprobieren! Hier brauche ich also keine Antwort. Das finde ich in nicht allzuferner Zukunft raus.

Zweitens habe ich viele Positionen die ich abspeichern und wieder aufrufen können möchte. Aktuell löse ich das wie im Bild:
   
Das nimmt unglaublich viel Platz ein. Das ist aktuell mein größter Posten in der Eventstruktur. Hätte ich ein Cluster, könnte ich das bestimmt noch bissi zusammenschieben.
Noch besser wäre, wenn ich aus dem Cluster ein Array machen könnte und das Bautteil "Write Key" sowie seinen Kollegen nur einmal in eine Schleife setzen müsste.
Gibt es dafür eine einfache Lösung oder muss ich da einfach ausprobieren was machbar ist?
Dank GerdW ist da schon eine Schleife, die mir ewig viel Platz gespart hat.

(24.05.2024 11:26 )Minako schrieb:  Ich habe noch nie eine Grün/rote Case struktur gesehen

Das ist nichts anderes als eine Case Struktur, nur optisch (von LabVIEW) hervorgehoben)

Zitat:oder etwas mit Variant zu tun gehabt.
Da werde ich erstmal bissi was zu lesen müssen, bevor ich deinen Aufbau auf mein Projekt beziehen kann.

Wir hier nur dafür verwendet um verschiedene Datentypen über eine Leitung zu schicken, das andere Ende muss dann aber wissen was drin ist, sonst gibts Fehler.

Zitat:Wenn ich alle Elemente des Frontpanels in ein Cluster setze, kann ich diese dann frei anordnen wie es mir spaß macht? Ich muss das mal ausprobieren! Hier brauche ich also keine Antwort. Das finde ich in nicht allzuferner Zukunft raus.

Gebe ich dir trotzdem, weil ich dich davon abhalten will Also es würde schon gehen, aber wozu? Was du auch imemr machen willst, es gibt eine bessere Lösung.

Zitat:Das nimmt unglaublich viel Platz ein. Das ist aktuell mein größter Posten in der Eventstruktur. Hätte ich ein Cluster, könnte ich das bestimmt noch bissi zusammenschieben.
Noch besser wäre, wenn ich aus dem Cluster ein Array machen könnte und das Bautteil "Write Key" sowie seinen Kollegen nur einmal in eine Schleife setzen müsste.
..
Dank GerdW ist da schon eine Schleife, die mir ewig viel Platz gespart hat.

Zum Beispie die linke for-Schleife kann in ein SubVI, 3 Eingänge und 2 Ausgänge und du hast es um 1/3 verkleinert.
Dies kannst du als Beispiel nehmen und auf den Rest anwenden.

Zitat:..Hätte ich ein Cluster..

Du bist der Programmierer -> mach ein Cluster

MfG Timo

Zitat:Gebe ich dir trotzdem, weil ich dich davon abhalten will Big Grin Also es würde schon gehen, aber wozu? Was du auch imemr machen willst, es gibt eine bessere Lösung.

Zu spät. Ich habs ausprobiert und es geht aber es ist nicht schön am FP. Ich kann Indikator und Controls nicht mischen also isses nicht perfekt.
Super das es ne bessere Lösung gibt. Wie soll die aussehen? Oder ist es das was du mir schon in dem VI geschickt hast?

Zitat:Zum Beispie die linke for-Schleife kann in ein SubVI, 3 Eingänge und 2 Ausgänge und du hast es um 1/3 verkleinert.
Dies kannst du als Beispiel nehmen und auf den Rest anwenden.

Das mit dem SubVI hatte ich verworfen, weil ich 15 Eingänge und einen Ausgang hätte. bzw, das auch noch mal andersherum. Erweiterbar ist das kaum bis gar nicht.
Wobei ich ja hergehen könnte in dem VI mache ich ein Cluster aus den ganzen Eingängen und dieses zerlege ich dann im Hauptprogramm in seine Einzelteile. Das ist dann ohne Ende erweiterbar.
Ha! das probier ich aus.

Zitat:Du bist der Programmierer -> mach ein Cluster

Das is ja die Variante von der du mir abrätst.
Zumindest in diesem Fall und an der Stelle wo ich als ersten dran dachte.
Die Sätze vor dem letzten Zitat sind eine neue Idee und da mache ich jetzt ein Cluster xD

Danke schön.