LabVIEWForum.de

Hallo Minako,

Zitat:Ich habe das Programm noch etwas erweitert und so gefällt mir die Funktionsweise doch am besten.
Darf ich das so benutzen? Immerhin war es deine Arbeit, welche ich da großteils kopiert habe.

Die MessageBox gehört in den FALSE-Case der ersten Case-Struktur: dort weißt du doch schon (durch das OrAll davor), ob mindestens ein Kanal gewählt wurde oder eben keiner…
Damit entfällt dann auch der Vergleich auf leerer String (wofür es übrigens eine extra Funktion gibt!)

- Rube-Goldberg: wenn du in deiner zweiten Case_Struktur ein TRUE ausgibst, obwohl du im TRUE-Case bist! Nimm doch einfach den boolschen Draht zum Selektor der Case-Struktur…
- Es fehlt eine Wartezeit in deiner Version, wenn du da eine Schleife drumherum packst. Der User wird nicht in der Lage sein, die Buttons im µs-Bereich zu ändern…

Ja klar darfst du das benutzen, das ist hier ein öffentliches Forum!

Zur Online-LabVIEW-Hilfe: das Menü ist so geblieben!
Hilfe->LabVIEW-Prinzipien->Übersicht…->Blockdiagramm in LabVIEW->Datenfluss…

Hallo GerdW,
ich habe mit deiner Variante das VI Buttons Auslesen2 mal erneuert und angehängtes VI erstellt.
Der rechte Teil wird noch zum SubVI gewandelt. Der linke wird auch ein Sub VI, da ich beide Parts voneinander trennen muss im weiteren Verlauf.
Gibts dazu noch Verbesserungsvorschläge?

Funktionieren tut es jedenfalls sehr gut.

Zitat:Es fehlt eine Wartezeit in deiner Version, wenn du da eine Schleife drumherum packst. Der User wird nicht in der Lage sein, die Buttons im µs-Bereich zu ändern…

Die Schleife musste ich wieder entfernen. Das Programm alleine hat funktioniert, jedoch im weiteren Verlauf wurde wegen der Schleife der String nicht übertragen.....

Danke schön.

Hallo Minako,

Zitat:Das Programm alleine hat funktioniert, jedoch im weiteren Verlauf wurde wegen der Schleife der String nicht übertragen.....

Auch das fällt unter das gleiche Mantra "THINK DATAFLOW!"…

DATAFLOW:
- Eine Struktur/Node/Funktion wird abgearbeitet, wenn alle Inputs bereitstehen.
- Eine Struktur wird verlassen/kann iterieren, wenn alle enthaltenen Code-Teile abgearbeitet sind.

Zitat:Gibts dazu noch Verbesserungsvorschläge?

Ja:
[attachment=62710]
Ich habe ein paar Dinge direkt geändert, bei anderen meinen Code-Vorschlag daneben gestellt…

Du kannst in LabVIEW viele Dinge direkt mit Arrays erledigen, kein Grund ein Schleife 512mal über einen String zu iterieren oder einen String über ein Schieberegister zusammenzubauen…

Guten Tag GerdW,
das mit dem DataFlow wird mir mit dem ganzen Probieren und den auftauchenden Fehlern immer klarer.
Habe mal alles zusammen gepackt, was ich inzwischen gelernt habe und ein vollständiges Programm zum Auslesen des DAQ970 mit Modul 909 ohne eigene SubVI zusammengestellt.
Es fehlt nur das Close VI. Dieses brauchte ich zum testen nicht und wird im Hauptprogramm enthalten sein.

Gibt es hierzu noch Vorschläge? [attachment=62711]

Ich mache mich jetzt mal an das Hauptprogramm ran. Hier wird es äußerst interessant in wie weit ich jetzt wirklich das Gelernt anwenden kann und wie klein das Programm am Ende wird.
Die Größenreduktion beim DAQ auslesen ist schon wahnsinnig toll.

Vielen Dank hier für.

Hallo Minako,

Zitat:Gibt es hierzu noch Vorschläge?

- Wieso musst du zweimal dein Kanal-Array filtern? Das könnte man mit einer FOR-Loop und zwei Output-Tunnels erledigen.
- Wenn kein Kanal gewählt wird, dann macht ALLES (Kanalauswahl + DAQ-Code) danach keinen Sinn: die Case-Struktur sollte also ALLES danach in den TRUE-Case packen!
- Das "/512" kann man auch aus der FOR-Loop herausziehen und auf das Array nach der Loop anwenden.
- Die ComboBox-Stringkonstante finde ich hier ungünstig: die Items sollten alle vernünftige Text haben. Außerdem weiß ich nicht, ob dein Gerät mit dem leeren Item zurechtkommt...
- Das Maximieren der Fenster (FP/BD) ist ungünstig, insbesondere bei viel Hintergrundfläche...
- Ja, da sollten sinnvolle subVIs angelegt werden: Ein VI pro Funktion, eine Funktion pro VI...

Guten Morgen GerdW,

Punkt eins und zwei sollte ich umgesetzt haben.
Punkt drei jammert das Programm, dass zwei arrays miteinander verbunden sind, welche unterschiedlich sind. Egal wie ich es raus ziehe (ganz oder nur einzelne Teile).

Punkt vier weiß ich nicht genau was du meinst. [attachment=62712]
Meinst du das im Bild? Das hatte ich aus den VIs des Herstellers übernommen und passend abgeändert.
Bisher hatte ich damit keine Probleme und ein leeres Feld gibt es da doch nicht?
Wenn ich DEF eingebe ist das kein Problem für das Gerät.
Wenn die Auswahlfelder leer bleiben, gibt das Gerät eine Fehlermeldung aus und die Messung geht nicht.

Wie kann das denn aussehen, wenn das Gerät nicht zurechtkommt?

Bei Punkt fünf hätte ich gern eine Erklärung dazu. Wieso ist das Maximieren ungünstig?
Ich mache das ja ständig. Das FP versuche ich möglichst klein zu halten, weil nicht jeder Bildschirm gleich groß ist. Beim BP ist das doch gar nicht soooo relevant nur schön, wenns auf einen Bildschirm passt.

Hallo Minako,

Zitat:Punkt drei jammert das Programm, dass zwei arrays miteinander verbunden sind, welche unterschiedlich sind. Egal wie ich es raus ziehe (ganz oder nur einzelne Teile).

Was genau meinst du:
[attachment=62717]

Zitat:Wenn ich DEF eingebe ist das kein Problem für das Gerät.
Wenn die Auswahlfelder leer bleiben, gibt das Gerät eine Fehlermeldung aus und die Messung geht nicht.

Wenn "DEF" kein Problem ist, dann ist es ok.
Wenn dein Device bei "leeren Auswahlfeldern" eine Fehlermeldung gibt, dann halte ich ein mögliches leeres Auswahlfeld für ein Problem: Warum willst du dem User die Möglichkeit geben, dein Device absichtlich in einen Fehler zu schicken???

Zitat:Bei Punkt fünf hätte ich gern eine Erklärung dazu. Wieso ist das Maximieren ungünstig?
Ich mache das ja ständig. Das FP versuche ich möglichst klein zu halten, weil nicht jeder Bildschirm gleich groß ist.

Weil Maximieren die Möglichkeit vermindert, mehrere Fenster gleichzeitig anzuschauen/zu bearbeiten.
Wenn du im FP mal AutoCleanup benutzt, bekommst du einen Eindruck für die benötigte FP-Fenstergröße…

Hi GerdW,

Zitat:Was genau meinst du:

Ich habe den Fehler dank deines Bildes gefunden. Ich habe den Ausgang nicht auf Indexing gesetzt. Da verstehe ich es noch nicht ganz wann ich was dort machen muss. Jetzt klappt das.

Zitat:Wenn "DEF" kein Problem ist, dann ist es ok.
Wenn dein Device bei "leeren Auswahlfeldern" eine Fehlermeldung gibt, dann halte ich ein mögliches leeres Auswahlfeld für ein Problem: Warum willst du dem User die Möglichkeit geben, dein Device absichtlich in einen Fehler zu schicken???

Jetzt weiß ich was du mit leeren Auswahlfeldern meinst. Habe diese entfernt und achte in Zukunft besser darauf. Danke.

Zitat:Weil Maximieren die Möglichkeit vermindert, mehrere Fenster gleichzeitig anzuschauen/zu bearbeiten.
Wenn du im FP mal AutoCleanup benutzt, bekommst du einen Eindruck für die benötigte FP-Fenstergröße…

Ich habe zwei Bildschirme und nutze den Einen fürs FP und den Anderen für BP. Bei Bedarf mache ich das FP auf Nutzergröße und setze das BP daneben, damit ich den zweiten Bildschirm für etwas anderes frei habe.

An diesem Punkt werde ich bei diesem Thema kurz pausieren.
Ich muss erst mit dem Hauptprogramm weiter kommen und das gelernte einsetzen. Das dauert ein wenig, da ich noch andere Dinge nebenbei zu tun habe.
Sobald ich da wieder Brocken habe nehme ich etwaige Vorschläge an.

Sollte das nicht Regelkonform sein sagt mir das bitte.
Wir können das Thema auch gern als gelöst ansehen und ich mache bei Bedarf ein Neues auf?!

Halloooooo,
ich bin soweit, dass ich behaupten kann, dass das Programm fast fehlerfrei läuft.
Leider nur fast fehlerfrei.
Da arbeite ich noch dran. Es würde mich nicht wundern, wenn das teils Struktur probleme sind.
Desshalb jetzt noch mal ne Beschreibung inkl. Frage/n.
Ich habe mein VI mit Hilfe von Eventstrukturen und Enum erstellt.
Ich habe hier im Forum gelernt, dass die Eventstruktur nichts enthalten darf, was länger als ein paar milisekunden dauert.
Also habe ich die Hauptmessung rausgezogen in eine eigene Whileloop.
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.
Ich verstehe also einfach nicht, wie das aufgebaut sein soll und wofür die Eventstruktur gut sein soll, wenn ich damit keine Ordnung schaffen kann, weil alles ausserhalb sein soll.
Mein Chef ist leider im Urlaub. Meine Kollegen sind sich unsicher in wie weit das schon Firmeninterna sein könnten, wesshalb ich das Programm nicht hochladen kann.
Der Screen als Überblick muss wohl erstmal reichen.

Also: Wenn ich ein Event über den Button starte und dieses zu lange dauert, wie mache ich das?
Ich hab es jetzt gelöst indem ich einen zweiten Startbutton in das Eventcase gegeben habe, diesen auf true setze und damit eine Casestruktur in einer anderen Whileloop auf true setze.
Das Ganze is auch so groß, dass ich die Scrollfähigkeit nutzen muss, um alles zu sehen....
Auf Grund von seeeeeehr vielen Variablen fällt es mir schwer mehr subvis zu machen.

Die untere rechte kleine Whileloop dient nur zur regelmäßigen Abfrage und Anzeige der aktuellen Temperatur im Klimaschrank. Das soll auch dann passieren, während die Messung weiter läuft.

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.
Ich hoffe mir kann das mal jemand erklären ohne das hochgeladene VI.

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)

Danke.

Hallo Minako,

leider erkennt man auf diesen komisch skalierten Bildern nicht sehr viel…

Was man aber sieht: viel zu viele lokale Variablen/Propertynodes!
Warum hast du im Bild "Geräte suchen" einen Indicator "DAQ970 ausgewählt" und direkt daneben eine Value-Property eben dieses Indicators!? Das ist eine klassische Race-Condition, die man mit nur wenig Draht entfern kann!

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