Probleme bei Eventcase!!!

' schrieb:Wenn du mich fragst...haben (While-)-Schleifen in einem Eventcase nix verloren.

So absolut würde ich das aber nicht sagen denn

1. gibt es viele mögliche Szenarien, daß ein Ereignis nicht sofort nach dessen Eintreffen abgearbeitet werden kann. Da passiert doch weiter nichts, als das eben etwas gewartet wird, aber jedenfalls ist das nicht gleichbedeutend mit einer Katastrophe.

2. wird eine while-Schleife ja nicht unbedingt durch Bedienung beendet. Dir Ausführungszeit für eine while Schleife muß nicht länger sein als die jeden andere Codes im Eventcase.

2. Hier zieht das Argument mit mehreren Ereignissen sowieso nicht, da es wegen fehlender äußerer while-Schleife nur ein einziges Ereignis gibt.

Es wäre aber nicht sehr komfortabel - und das hattest Du wohl im Auge - wenn ein Stop-Event erst dann wirksam wird, nachdem eine Schleife in einem anderen Case per Bedienung beendet wird. Das muß dann bei der Programmierung bedacht werdenm (Stichwort: lokale Variable).

Anzeige

' schrieb:Das Häckhen sagt nur aus ob neue FP Events in die Windows Message Queue aufgenommen werden, während ein Event abgearbeitet wird. Die Ausführung des aktuellen Events wird allerdings nicht abgebrochen.
eg

In dem Fall aber doch. Die Schleife - und damit der Eventcase - wird mit dem Button OK beendet, der sich direkt in dieser Schleife befindet und bei jedem Schleifendurchlauf abgefragt wird. (Wenn der sich nicht bedienen lässt, läßt sich die Schleife überhaupt nicht beenden). Für die anderen Knöpfe hast Du aber recht, die können das Ereignis nicht beenden und bewirken im Moment nichts, auch wenn sie sich bedienen lassen.

' schrieb:1. gibt es viele mögliche Szenarien, daß ein Ereignis nicht sofort nach dessen Eintreffen abgearbeitet werden kann. Da passiert doch weiter nichts, als das eben etwas gewartet wird, aber jedenfalls ist das nicht gleichbedeutend mit einer Katastrophe.

Ja, aber dann müsste man dem User zumindest irgendeine Rückmeldung geben...z.B. ne Uhr die weiterläuft oder ein Fortschrittsbalken o.ä.. Außerdem müsste in der While-Schleife auf jeden Fall ein Timeout implementiert sein, damit die Schleife nicht ewig weiterläuft. Das alles ist sehr viel einfacher, wenn man sich While-Schleifen in nem Event-Case komplett spart!

' schrieb:Es wäre aber nicht sehr komfortabel - und das hattest Du wohl im Auge - wenn ein Stop-Event erst dann wirksam wird, nachdem eine Schleife in einem anderen Case per Bedienung beendet wird. Das muß dann bei der Programmierung bedacht werdenm (Stichwort: lokale Variable).

Was ich hier im Auge hatte ist folgendes: Es ist nicht nur unkomfortabel, sondern auch unflexibel!

Natürlich kann man prinzipiell jede Art von Code im Eventcase platzieren (z.B. irgend ne Suche per While-Schleife in nem String)...ich halte es aber für sinnvoller, dort nur "kurze" Bearbeitungen etc. auszuführen...und "längere" in einem "State" in der gleichnamigen "Machine" durchzuführen.

' schrieb:Du wirst auch durch das Deaktivieren des "Lock FP" keinen Erfolg haben, so wie ich schon sagte! Die zweite Schleife wird nicht starten, bis die erste beendet ist! Deine Anwendung schreit wieder mal nach ner State Machine...dazu gibts hier und in LV genügend Beispiele...

Gruss
Achim

Ich hab mich mal im Forum und im Internet schlau gemacht, was State Machines angeht! Aber ich bin nicht schlauer geworden, zumindest weiß ich nicht, wie es mir hälfen soll, mein Programm einfacher ("einfach ist relativ") zu erstellen. Mein Anliegen ist es ein Programm zu programmieren, bei dem der User eine Messung starten kann und diese wird in einem Diagramm wiedergegeben. Diese Messung braucht ziehmlich lange, bis sie zu ende ist. Nachdem die Messung beendet wurde, kann er einen Knopf betätigen und das Spectrum aus der MEssung errechnen. Mein anligen war mit diesem Testprogramm zu testen, was passiert, wenn ich die Steuerung über eine Eventcase mache. Ob es zu konflikten kommt, wenn die Messung noch nicht zu ende ist aber der User schon das Spektrum errechnen will.

' schrieb:Ich hab mich mal im Forum und im Internet schlau gemacht, was State Machines angeht! Aber ich bin nicht schlauer geworden, zumindest weiß ich nicht, wie es mir hälfen soll, mein Programm einfacher ("einfach ist relativ") zu erstellen. Mein Anliegen ist es ein Programm zu programmieren, bei dem der User eine Messung starten kann und diese wird in einem Diagramm wiedergegeben. Diese Messung braucht ziehmlich lange, bis sie zu ende ist. Nachdem die Messung beendet wurde, kann er einen Knopf betätigen und das Spectrum aus der MEssung errechnen. Mein anligen war mit diesem Testprogramm zu testen, was passiert, wenn ich die Steuerung über eine Eventcase mache. Ob es zu konflikten kommt, wenn die Messung noch nicht zu ende ist aber der User schon das Spektrum errechnen will.

Also ich würde wie folgt vorgehen.

Im HauptVI wird dein MessungVI in einem der Events gestartet. Dein Messung.vi besteht aus einer While-Schleife mit dem Stop-Button und poppt beim Start auf. Der User kann jederzeit die Messung abbrechen (weil sie so lange braucht) und du kommst zurück in dein HauptVI.

eg

' schrieb:Also ich würde wie folgt vorgehen.

Im HauptVI wird dein MessungVI in einem der Events gestartet. Dein Messung.vi besteht aus einer While-Schleife mit dem Stop-Button und poppt beim Start auf. Der User kann jederzeit die Messung abbrechen (weil sie so lange braucht) und du kommst zurück in dein HauptVI.

eg

Ich stelle mal ein Bild hoch, wie das FP aussieht.
   
Es lässt sich folgendes sagen. Linker Bereich zeigt den Teil, welcher für die Messung relevant ist. Der rechter Teil ist das Spektrum.

Ich hab mir jetzt überlegt gehabt (dabei hat mich dein Beitrag Eugen inspiriert), ein subVI zu programmieren, welches eine Art funktionale globale Variable ist. Die Vorteile dabei sind, dass ich eine bessere Übersicht, über den Code hab, und das ich mir die verschiedenen Sequenz-Struckturen, wie beim folgenden Beispiel sparen:

  eventcase.vi (Größe: 20,09 KB / Downloads: 170)


Naja. Ich bin noch zu unerfahren, ob ein Nachteil entsteht, doch ich könnte mir vorstellen, dass es die Ressourcen des Rechners belget!!!

' schrieb:I
Naja. Ich bin noch zu unerfahren, ob ein Nachteil entsteht, doch ich könnte mir vorstellen, dass es die Ressourcen des Rechners belget!!!

Mehrere Sequnenzstrukturen in einem VI sind immer kritisch, da sollte man vermeiden. und funktionieren kann das überhaupt nur, wenn in beiden ein Timeout vorgesehen ist. Das ist bei Dir nicht der Fall.
So wie es hier ist "funktioniert" es so: das Programm wartet bei einer der beiden Ereignisstrukturen auf ein Ereignis. Die andere Ereignsistruktur ist nicht dran, diese Ereignise werden nicht ausgeführt. Welche der beiden Strukturen das ist, ist nicht vorhersagbar. Wenn dann das Ereignis ausgeführt ist, wartet das Programm bei der zweiten Struktur auf ein Ereignis, bei der ersten Struktur wird nichts angenommen. Wenn das Ereignis kommt, wir das Programm beendet, da keine while-Schleife vorhanden ist

Merke auch: Es gibt zwar Ausnahmen, z.B wenn sich ein Sub.VI dann erledigt hat, wenn ein Wert eingegeben wurde. Aber für jedes normale Programm gilt: Um ein Ereignsistruktur gehört immer ein while-Schleife (Wobei das auch die Hautschleife das ganzen Programms sein kann)

' schrieb:Merke auch: Es gibt zwar Ausnahmen, z.B wenn sich ein Sub.VI dann erledigt hat, wenn ein Wert eingegeben wurde. Aber für jedes normale Programm gilt: Um ein Ereignsistruktur gehört immer ein while-Schleife (Wobei das auch die Hautschleife das ganzen Programms sein kann)

Merk ich mir!!! Danke.

' schrieb:Merk ich mir!!!

Hier das VI so abgeändert, daß es funktioniert. Damit die Bediener nicht mit der Bedienung durcheinanderkommt, ist jeweils nur das aktiviert, was sinnvoll ist zu bedienen. Aber die ganze Struktur ist auch so nicht ideal. Die Hauptfrage ist z.B ob beide Zahler auch gleichzeitig laufen sollen oder wie jetzt immer nur einer der beiden.

' schrieb:Hier das VI so abgeändert, daß es funktioniert. Damit die Bediener nicht mit der Bedienung durcheinanderkommt, ist jeweils nur das aktiviert, was sinnvoll ist zu bedienen. Aber die ganze Struktur ist auch so nicht ideal. Die Hauptfrage ist z.B ob beide Zahler auch gleichzeitig laufen sollen oder wie jetzt immer nur einer der beiden.

Vielen dankt. Das Ding bau ich in mein Programm rein. Ist auf jedenfall Benutzer freundlich und saugeil.