Event B automatisch starten lassen, nachdem Event A eingetreten ist ?

Ich habe auch schnell mal ein Bsp. zusammengeklickt. Dort wird die Reihenfolge beschrieben, die wie ich finde in dem anderen Bsp. nicht zur Geltung kommt.
Du solltest immer so vorgehen:
Event erzeugen --> Event registrieren --> Event verwenden --> Event von der Registrierung aufheben --> Event löschen.

Anzeige

Danke Euch beiden für die Beispiele. Habe mir auch Beispiele in der LV-Hilfe angeschaut.
Was mir dabei auffiel:
a) Dynamische Ereignisse und Benutzerereignisse lassen sich ja auch dynamisch, d.h. während des Programmablaufs, wieder löschen. Wenn aber das gesamte Programm sowieso beendet wird, dann scheint die Löschung nicht wichtig zu sein, wahrscheinlich besorgt das LV von sich aus. Also im Gegensatz etwa zur einer Datei, die man nicht vergessen sollte bei Programmende zu schließen.
b) Bei Benutzerereignissen lassen sich ja auch Daten an den Ereigniscase mit übergeben. Das geht aber nicht mehr, wenn der betreffende Ereigniscase außerdem noch für andere Ereignisse konfiguriert ist. Im Beispiel von Dimitry ist das der Fall. (Die Daten werden aber in beiden Beispielen nicht benutzt)

Edit: Habe mal das Beispiel von Dimitri dahingehend verschlimmbessert, daß man die Daten des Benutzereeigniasses "Trigger" (also den boolschen Wert von "Trigger") auswerten kann. (Motto: "Man vergilt seinem Lehrer schlecht, wenn man immer nur der Schüler bleibt" [Nietzsche]):

  Dynamisches_Event.vi (Größe: 16,44 KB / Downloads: 234)

' schrieb:Das geht aber nicht mehr, wenn der betreffende Ereigniscase außerdem noch für andere Ereignisse konfiguriert ist.

Jo, da hab ich gerstern auch erstmal kurz gucken müssen, wo die Anschlüsse der Ereignisdaten geblieben sind.

Zitat:Edit: Habe mal das Beispiel von Dimitri dahingehend verschlimmbessert, daß man die Daten des Benutzereeigniasses "Trigger" (also den boolschen Wert von "Trigger") auswerten kann.

Schau' ich mir <strike>Daheim (8.6)</strike> gerne an.

Ich muss mir noch überlegen, ob das mit den Dummys irgendein Nachteil für mich hat. Zur Zeit finde ich das hier vollkommen ausreichend:
   
Den Vorteil den ich sehe ist, dass man so nichtmal eine einzige Gehirnwindung braucht.

Ok, nun ist der Fall gekommen, wo ich das Ganze brauche

Leider weicht die Theorie nun wieder ma von der Praxis ab. Ich hab Methode B von Lucki verwendet, weil das irgendwie am einfachsten geht - dachte ich. Also über Signalisierende Wertänderung das ganze Auslösen lassen.

Das klappt aber nur, wenn der Control kein "Latch"-Verhalten hat.

Hier bei diesem sinnfreien Beispiel hätte ich gerne, dass der Stopbutton "Latch"-Verhalten zeigt, dann funktioniert das Ganze allerdings nicht mehr.
Es klappt nur mit Switch-Verhalten

  ereignis_erzwingen.vi (Größe: 9,06 KB / Downloads: 215)


Da kann man nix machen oder?

Abhilfe wäre also auf den ersten Blick ein solches benutzerdefiniertes Event oder halt wirklich dieses "Schalter-Verhalten" verwenden. Da müsste man halt über die Eigenschaften den "Knopf-wieder-los-lassen" - also dafür sorgen, dass er nicht gedrückt bleibt - des is aber nervig.

Da kommst du nicht raus, von einem Latch-Button lässt sich keine lokale Variable erstellen und auch die PropertyNode Value oder Value(Signaling) geht im Schreibmodus nicht.

Aber wenn so nicht geht, dann halt anders:

  ereignis_erzwingen2.vi (Größe: 8,13 KB / Downloads: 318)


Gruß, Jens

Zitat:Da kommst du nicht raus

mist

Danke für deine Erweiterung. Wie ich sehe hast du einen Fake-Stop Knopf eingebaut, der nur dazu dient das Event zu triggern. Raffiniert
Danke Jens.