LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Firing events from inside event structures

Solved!
Go to solution

Hi all - I got a weird idea I want to run past the motley mob.  I need an "Execution Loop", "task loop", whatever that responds to events from a user interface loop and a DAQ loop.  But I also need to be able to iterate in a loop.  I've always used queue-driven state machines for this, but this scheme seemed like it might be a bit easier to implement.  To iterate in a loop, it needs to be able to "fire its own events" from inside the event structure.  I like the fact that it's trivially easy to add a new event source - and each event can carry its own appropriate data type, I'm not stuck with one queue.  So - is this crazy or stupid?  Thanks for looking, folks - paul

 

{I saved in LV2 version, hope y'all can open it}

0 Kudos
Message 1 of 7
(283 Views)
0 Kudos
Message 2 of 7
(257 Views)

Thanks Oscar, I didn't know about the LabVIEW Tools Network - will check it out when I get this error resolved - Package Manager errors out with "unknown command line arguments blah blah - Unknown Command: then the .vip filename".  I'll have to fiddle with it - paul

0 Kudos
Message 3 of 7
(227 Views)

I'm not sure, but it sounds more or less like you're describing the Actor Framework...

Might be worth also taking a look at that (but I hear lots of good things about the DQMH).

 

If you want to try the Actor Framework and have lots of UI-updating based events, it might also be worth looking at the work Allen C Smith and Sam Taggart have done recently here: Events for UI Actor Indicators. There's a video in that post.


GCentral
0 Kudos
Message 4 of 7
(174 Views)
Solution
Accepted by topic author pauloelora

No it's not stupid. But you do need to be careful.

 

I disagree that DQMH or Actors are in any way required of even recommended based purely on what you have posted. I would first spend some time trying it out with Events as you already have before switching to a completely different way of doing things.

 

The problem with having a loop feed itself is the problem of infinite loops occurring. This is a similar problem to infinite recursion.  If handling Event X fires Event Y which then also fires Event X, you have an infinite loop and you will have problems. This gets really complicated and problematic when it's a conditional relationship, if it only happens under certain circumstances, it can cause ont of those horrible (impossible to reproduce) problems.

 

  • Make sure the number of events you want to fire is bounded (Autoindexing FOR Loop for example)
  • Make sure the Event you are calling does not itself create a loop with other events
  • If things get complicated, you can also create a helper loop which receives a signal (Loop these items) which then actually send the events back to the actual handler loop. What does this bring? It separates out the control and allows additional methods of debugging if things go weird.
  • If you want to get really weird, you can actually have an Event defined with the datatype "Event Registration Refnum" which in turn contains the Events you want to queue up.  this gets really weird really quick, but it can be a really cool way to achieve what you want while side-stepping some of the awkward problems which can come along with it.

The fourth point is not to be generally recommended if you're not really comfortable with how Events work.

Message 5 of 7
(150 Views)

Check out the following links

 

https://decibel.ni.com/content/docs/DOC-12159

 

https://forums.ni.com/t5/LabVIEW/Community-Nugget-2009-03-13-An-Event-based-messageing-framework/m-p...

 

I have used the ideas in those links to make a template where I use Events to pass messages around, along with the JKI State Machine which has an event structure built in.

 

mcduff

Message 6 of 7
(112 Views)

Fantastic help guys - thanks so much for sharing your experience and insights!  This old brain is definitely growing - paul

0 Kudos
Message 7 of 7
(102 Views)