+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: Application Builder (/Forum-Application-Builder)
+---- Thema: Einfrieren der GUI bei Eventcase (/Thread-Einfrieren-der-GUI-bei-Eventcase)
Einfrieren der GUI bei Eventcase - ThommyTomTom - 22.06.2020 16:01
Hallo Labview-Forumsmitglieder,
im Rahmen eines Praktikums programmiere ích die Ansteureung eine Prüftisches mit einem Asynchronmotor. Für die Umsetzung habe ich mit einer Eventstruktur gearbeitet.
Ich habe das Problem, dass ich einen programmierten Dauertest wobei der Motor unterschiedliche Drehzahlen anfährt nicht anhalten kann.
Sobald ein Event ausgeführt wird ist die GUI für die Eingabe eingefroren bis das Event abgearbeitet ist.
Ich verwende keine Queues und bin mir unsicher ob ein Anhalten des Dauertest ohne überhaupt möglich ist.
Über Tipps und Anregungen würde ich mich freuen.
Grüße
Thommy
RE: Einfrieren der GUI bei Eventcase - GerdW - 22.06.2020 19:27
Hallo Thommy,
herzlich willkommen im Forum!
Zitat:Ich habe das Problem, dass ich einen programmierten Dauertest wobei der Motor unterschiedliche Drehzahlen anfährt nicht anhalten kann.Es gibt eine klare Grundregel für die Nutzung der Event-Struktur: ein Eventcase sollte so schnell wie möglich abgearbeitet sein. Und unter "schnell" sollte man hier "Millisekunden" verstehen!
Sobald ein Event ausgeführt wird ist die GUI für die Eingabe eingefroren bis das Event abgearbeitet ist.
Ich verwende keine Queues und bin mir unsicher ob ein Anhalten des Dauertest ohne überhaupt möglich ist.
Über Tipps und Anregungen würde ich mich freuen.
Deine Bilder zeigen dagegen etwas anderes: viel Code in den Eventcases, inkl. Schleifen und anscheinend Kommunikation mit externer Messtechnik. Alles Dinge, die nicht "schnell" ablaufen…
Nun könnte man auf die "clevere" Idee kommen, in der Eventcase-Definition das Häkchen bei "block GUI" zu entfernen. Das ist aber leider auch nicht sinnvoll, da dank THINK DATAFLOW! andere Events erst dann abgearbeitet werden können, wenn der aktuelle Case beendet wurde. Du verschlimmbessert auf diese Weise nur das Verhalten deines Programms: Events werden registriert, aber stark zeitverzögert abgearbeitet - das hört man den User jetzt schon fluchen…
Lösung:
Programm neu erstellen - und sich vorher Gedanken um eine sinnvolle Programmstruktur machen!
Warum verwendest du denn keine Queues? Oder sinnvoll strukturierte Statemachines oder QMH?
Anmerkungen zu den Bildern:
Generell sehr "komprimierter" Code, da könnte man mal aufräumen und z.B. mehr gerade Drähte verwenden! Lies mal den Styleguide in der LabVIEW-Hilfe!
Was genau sollen FOR-Loops bewirken, die exakt einmal iterieren? Das ist quasi ein NOP! Warum nutzt du nicht den ErrorWire für den DATAFLOW?
Schleifen in Schleifen (Dauertest): das geht mit einer Statemachine schöner…
RE: Einfrieren der GUI bei Eventcase - ThommyTomTom - 29.06.2020 14:43
Hallo Gerd, vielen Dank für dein Kommentar.
Das ist mein erstes Labview-Projekt. Ich dachte nach dem Belesen, dass der Event-Case eine geeignete Möglichkeit ist die Aufgabe umzusetzen.
Auf Queues bin ich erst aufmerksam geworden als ich die Probleme im Program bemerkt habe. So ganz verstehe ich auch noch nicht wie ich diese anwenden muss um z.B. einen Dauertest vorzeitig zu beenden bzw. im besten Fall zu pausieren.
Soweit ich die Queues verstanden habe wird die nächste Eingabe erst abgearbeitet, wenn die aktuelle beendet wurde?
Ich weiß das es einen Weg geben wird nur leider fehlt mir bis jetzt noch das Verständniss.
RE: Einfrieren der GUI bei Eventcase - NoWay - 30.06.2020 10:02
Die Eventcases sind eine gute Möglichkeit um Eingaben vom Benutzer abzufangen und zu verarbeiten. Wie Gerd jedoch richtigerweise erwähnte, darf das dein Programm idealerweise nicht blockieren, indem die Abarbeitung eines einzelnen Eventcases zuviel Zeit in Anspruch nimmt.
Die Verwendung von Queues an der Stelle hat durchaus praktische Vorteile. Einfaches Beispiel:
Du erzeugst zwei While Schleifen. Deine obere beinhaltet deine Eventstruktur und jeder Case wiederrum ein Enqueue Element in Kombination mit einem Enum (unbedingt TypeDef!) oder String.
Deine untere While Schleife beinhaltet dann eine Case Struktur. Jeder Case entspricht einem Enum bzw String Eintrag, wie du sie in der oberen Schleifen verwendet hast. Dazu packst du noch einen Case, wenn der Fall Eintritt, dass die Queue leer gelaufen ist (Timeout): Idle
Du prüfst "unten" nun deine Queue auf neue Einträge und gibst sie an deine Casestruktur weiter. Sind keine Vorhanden, wartest du einfach auf neue.
Nun hast du ein Konstrukt, mit dem du beliebig Kommandos aus der Eventstruktur weiterverarbeiten kannst, ohne diese zu blockieren.
Das heißt natürlich nicht, dass das Event auch zwingend bearbeitet wird. Blockiert deine untere Schleife nun, weil ein VI noch läuft, dann wird das Folgeevent nur ausgeführt, wenn das entsprechende VI mit seiner Arbeit fertig ist. Dir steht es natürlich frei, Queues, Notifier und Co. an entsprechende VIs zu übergeben. So lassen sich dann auch Benutzereingaben aus der zuvor erwähnten Eventstruktur in einem laufenden VI behandeln (z.B. die Verwendung eines Stopknopfes in Verbindung mit einem Notifier).
Gerade wenn man mit den Sachen nicht vertraut ist, hilft es enorm, einfach mal wild auf einem leeren Blockdiagramm diverse Dinge auszuprobieren. Was soll schon kaputt gehen? Wenn es dann immer noch hakt, bekommst du hier kompetente Hilfe im Forum.
RE: Einfrieren der GUI bei Eventcase - ThommyTomTom - 01.07.2020 14:42
Hallo NoWay,
vielen Dank für deine Tips.
Ich konnte heute gute Vortschritte machen und die Queues sind mir ein nicht mehr ganz so großes Rätzel.
Durch eine geringe Wochenarbeitszeit wird sich die Fertigstellung des Programms aber sicherlich noch etwas hinziehen.
Gruße
Thommy