INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

mehrere Events schlecht



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

18.12.2012, 14:49 (Dieser Beitrag wurde zuletzt bearbeitet: 18.12.2012 14:50 von Hasenfuss.)
Beitrag #1

Hasenfuss Offline
LVF-Stammgast
***


Beiträge: 331
Registriert seit: Dec 2012

2012
2012
DE



mehrere Events schlecht
Ich habe im Lehrbuch gelesen, dass zwei Event-Strukturen parallel "schlecht" sind, sondern alles wenn möglich in eine gepackt werden sollte.

So schön - so gut. Was hab ich getan? Ich habe mir mehrere Menuefolgen definiert und einge davon auch als typdef-Dateien abgespeichert. Darunter habe ich einen Bereich mit Optionsfeldern. LabView hat mir dazu den Rahmen Optionsfelder bereitgestellt und ich habe vier Optionsfelder eingefügt.

Folgendes möchte ich tun

Ich habe drei Schalter, nennen wir sie

Signal erzeugen
Messung starten
Beenden

Diese drei Schalter kann ich mit der Eventstruktur abfangen und weiter reagieren. Beispielsweise soll das Optionsfeld erscheinen, denn ich Einstellungen betätige. Dass geht auch mit dem Eigenschaftsknoten-sichtbar - alles schön.

Jetzt kann ich bei den Events auch Operationsfelder-Wertänderungen erfassen, aber nicht die Wertänderungen im einzelnen. Je nach angeklicktem Wert sollen verschiedene Einstellmöglichkeiten sein.

Bei den Operationsfeldern ist immer nur eins auswählbar:

Sinus
Sägezahn
DC

aber zu jedem Operationsfeld gibt es noch unterschiedliche Einstellmöglichkeiten, die also noch ein drittes Menü erzeugen.

Jetzt könnt ich innerhalb vom Ereignis Optionsfeld-Wertänderung eine case-Struktur einbauen, die die Operationsfelder auswertet und dazu die nächste Menüebene einblendet. Dazu muss ich aber immer die einen Eigenschaftsknoten von den weiteren Untermenüs - z.B. Einstellungen_Sinus auch ein- und ausblenden, dass heisst, ich muss jeden Eigenschaftsknoten von Sinus_einstellungen, DC_einstellungen ... an den case dranhängen und den jeweiligen Wert True/False rausführen. Es gibt zwar auch die Möglichkeit - "Standard verwenden, wenn nicht verbunden", aber so hab ich an dem case für die Auswertung von Optionsfeldern-Werteänderung schon mal drei Schleifentunnel dran und wenn noch weitere Optionsfelder hinzukommen, dann erhöt sich da die Anzahl.

Ist das problematisch, wenn ich mehr und mehr Schleifentunnel daran setzen? Es macht auch keinen Sinn, wenn ich die jeweilge Aktion in das case reinsetze, ich muss ja beim Wechsel z.b. von Sinus auf Sägezahn das eine Fenster ausblenden und das andere einblenden.

gibt es vielleicht noch eien Tipp, wie man mehrfach verschachtelte Menues geeignet erstellen kann?


Angehängte Datei(en) Thumbnail(s)
   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
18.12.2012, 21:21
Beitrag #2

GerdW Offline
______________
LVF-Team

Beiträge: 17.398
Registriert seit: May 2009

LV2021
1995
DE_EN

10×××
Deutschland
RE: mehrere Events schlecht
Hallo Hasenfuss,

Tipp: Verwende doch ein Tab-Element.
Damit schlägst du gleich zwei Fliegen mit einer Klappe: Der User muss sich (wie bei deinem Optionsfeld) für einen Signaltyp entscheiden, hier durch Auswahl eines Tabs. Und da der User sich einen Tab auswählt, bekommt er automatisch die dazu passenden Einstellelemente zu sehen...

Zitat:Ist das problematisch, wenn ich mehr und mehr Schleifentunnel daran setzen?
Zusammengehörende Dinge sollte man in (typdefinierten) Clustern bündeln...

Da du schon die Hilfe/Kommentare zu Eventstrukturen gelesen hast, noch folgendes: Terminals der Bedienelemente, deren (ValueChange-)Event ausgewertet wird, sollten im Eventcase liegen. Damit wird bei Schaltern die Latch-Operation (durch das Lesen der Terminals) ausgeführt!

Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.12.2012, 13:23
Beitrag #3

Hasenfuss Offline
LVF-Stammgast
***


Beiträge: 331
Registriert seit: Dec 2012

2012
2012
DE



RE: mehrere Events schlecht
Ich wollte jetzt keinen neuen Thread erstellen, sondern stell meine Frage einfach nochmal hier mit rein, weil es auch mit Events zu tun hat.

Wenn ich Bedienelemente erstelle, an die nichts anschließe, die aber mit Events verbinde - ist es dann egal, wo die Bedienelemente innerhalb des Blockdiagramms positioniert werden? Sollten die eher in die Haupt-Schleife mit rein, falls man mit einer while-Schleife arbeitetet ? Oder koennen die auch ausserhalb des Fehlercases liegen?


Angehängte Datei(en) Thumbnail(s)
   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.12.2012, 13:47 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2012 14:48 von Lucki.)
Beitrag #4

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: mehrere Events schlecht
Bei den meisten Bedienelementen ist es egal. Man kann sie außerhalb der aller Schleifen positionieren. Wenn man allerdings den Wert noch irgendwo anders im Programm lesen will, verwende ich lieber dort das Bedienelemet als daß ich eine lokale Veriable erstelle.

Ein wichtige Ausnahme sind boolsche Elenete mit Latch-Verhalten. Die müssen gelesen werden, damit sie von selbst wieder herausspringen. Also müssen sie sich z.B im Eeignsicase befinden.
Hierzu noch zwei Tips:
1. Manchmal wird überflüssigerweise in den Ereigniscase ein false/true case zur Knopfbehandlung platziert. Das ist redundant, denn der Bediener setzt immer nur auf true. Das Rücksetzen erfolgt programmgesteurert und löst kein Ereignis aus.
2, Beim Latch-Verhalten hat man die Wahl zwischen "Latch beim Drücken" und "Latch beim Loslassen". Beides ist möglich, allerdings fehlt bei "Latch beim Drücken" meist das "Bedienerlebnis": Der Knopf springt so schnell wieder heraus, das man nicht wahrnimmt, dass er überhaupt gedrückt wurde. Deshalb ist "Latch beim Loslassen" im allgemeinen die besere Variante.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.12.2012, 14:02 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2012 14:05 von Hasenfuss.)
Beitrag #5

Hasenfuss Offline
LVF-Stammgast
***


Beiträge: 331
Registriert seit: Dec 2012

2012
2012
DE



RE: mehrere Events schlecht
Ich habe noch eine Frage - vielleicht eine blöde Frage - aber ich hab die Antwort noch nicht gefunden:

Ich definiere ein Ereigniscase mit mehreren Ereignissen. Wird ein case ausgelöst - wird dann das Ereignis erst abgearbeitet und so lange werden keine anderen cases bearbeitet? Oder gibt es einen Speicher - ähnlich einer Queue, wo die Ereignisse hintereinander gepuffert werden und dann der Reihe nach wie sie hereinkommen abgearbeitet werden?

Ich denke daran an die uC-Programmierung und den Interrupts - so stelle ich mir von der Funktion einen Ereignis-Case vor. Dabei gilt bei der Mikrocontrollerprogrammierung, dass man die Aufgaben in den Interrupts so kurz und knapp wie möglich halten soll, damit keine Ereignisse verloren gehen - z.B. wenn man Daten einliest und parallel noch eine Speicheroperation mit den Interrupts in Gang setzt. Natürlich könnte man hier nun argumentieren, die Rechner, wo LabView heute drauf läuft, sind um eine 1000er Potenz schneller als ein Mikrokontroller mit vielleicht 10-20 MHz Taktfrequenz, dabei könnte man das vielleicht bei LabView vernachlässigen, aber ich frag einfach dennoch mal Euch Spezialisten hier in dem Forum und freue mich auf Eure Antwort.
(21.12.2012 13:47 )Lucki schrieb:  ...

Ein wichtige Ausnahme sind boolsche Elenete mit Latch-Verhalten. Die müssen gelesen werden, damit sie von selbst wieder herausspringen. Also müssen sie sich z.B im Eeignsicase befinden.
Hierzu noch zwei Tips:
...

Meine Frage dazu - gelesen werden bedeutet, dass ich das Element mit einer Datenleitung verbinden muss, damit ein Schalter mit Latch-Verhalten "gelesen" wird? Müsste ich dann z.b. den Schalter ProgrammStopp zum Beenden der while-Schleife in den Ereignis-case reinsetzen und dann nicht eine TRUE-Konstante nach aussen (in den Tunnel) schicken, sondern dierekt den Schalter mit dem Datentunnel verbinden? Oder reicht es einfach nur aus - wie dort beschrieben, den in den Ereignis-case einzufügen, damit er "gelesen" wird ohne eine Datenanbindung?
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
21.12.2012, 14:57 (Dieser Beitrag wurde zuletzt bearbeitet: 21.12.2012 15:12 von Lucki.)
Beitrag #6

Lucki Offline
Tech.Exp.2.Klasse
LVF-Team

Beiträge: 7.699
Registriert seit: Mar 2006

LV 2016-18 prof.
1995
DE

01108
Deutschland
RE: mehrere Events schlecht
Das Letzgenannte ist richtig: Der Knopf muss nicht wirklich gelesen werden, man braucht kein Datenanbindung durch einen Draht. Es reicht aus, dass er im Falle eines Drahtes gelesen werden würde.
Aber so etwas ist ja in 5 min jederzeit mit einem einfachen Test feststellbar. Ich verstehe immer nicht, warum Viele lieber umständlich das Forum befragen anstatt schnell mal selbst etwas zu testen.

Zitat:Wird ein case ausgelöst - wird dann das Ereignis erst abgearbeitet und so lange werden keine anderen cases bearbeitet? Oder gibt es einen Speicher
Nicht "Oder", sondern "Und". Ein Ereigniscase wird nicht unterbrochen, solange er abgearbeitet wird, und es gibt eine (fast unbegrenzt große) Queue, in der die noch anstehenden und neu hinzukommenden Ereignisse gespeichert werden. Es geht kein Ereignis verloren.
Ereignisse sind allerdings kein Interrupts. Oder nur insofern, dass beim Eintreten eines Ereignisses das Programm zwar sofort unterbrochen wird, aber nur, um den Eintrag in der Queue zu erstellen.
Wann und inwieweit das dann tatsächlich abgearbeitet wird, hängt davon ab, dass die Ereignisstruktur vom Programm ab und zu tatsächlich angesteuert wird.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Frage zur Architektur: Statemachine und Wait for Events tuhpon 6 1.602 18.03.2024 16:14
Letzter Beitrag: tuhpon
  Bedienelemente bündeln zum Auslösen eines Events Marcusius 12 7.204 03.09.2019 17:24
Letzter Beitrag: Marcusius
  Mausrad bei Events/Casestrukturen Schwand 1 3.250 20.09.2016 08:30
Letzter Beitrag: Schwand
  Dynamische Events programmatisch auslösen AMueller 6 6.194 22.04.2016 07:43
Letzter Beitrag: GerdW
  Eventstruktur mit 2 Events Großer_Stein 3 3.682 11.06.2015 10:11
Letzter Beitrag: Großer_Stein
  "rentrant" SubVI zum Triggern von Events Oli_N 5 3.788 28.04.2015 12:02
Letzter Beitrag: GerdW

Gehe zu: