Using Dynamic User Events "across" VIs

[Evan]

Don,

I have modified your VI to now use a user event to accomplish your goals.  Notice that I send the user event and it stops.  Because I only create a single stop user event, any number of VIs can register to look at the one and they will all respond to the user event.

I placed the reference in the cluster just to make it easier to pass around.  As a side note, the VI Refnum that you are passing to the SubVI is un-needed.  The subVI already has its own reference, so if you drop a property node on its diagram it will assume to act on itself, unless another refnum is wired in.  I left it as is, but thought I would let you know.

In regards to passing data and references etc between VIs there are a lot of ways to do it.  You can use the set control like we did, but then the data is not dynamic.  One method that can work really well is the LabVIEW 2 style globals or databases.  You have a loop that only runs once with the data in shift registers.  Then any VI can call that subVI and get the data out of the shift registers.  Another faster solution that I like is to have a 1 element Queue.  The element is your data cluster and you enqueue it.  Then when ever you want to read or set a value you dequeue the element, do your action and requeue it.  In this way you are guaranteed that you will note have multiple VIs attempting to ever write each other.  If a VI has dequeued the element then everyone else must wait until it is re-queued.  This is also nice because you can name the Queue and then any VI can easily grab onto it.  So your subVIs simply call create with that name and they will all share the Queue and therefore data.

To remotely fire events it depends on the event.  You can user user events to fire any event you want.  See my example with the stop button.  If all you want is to fire a Value Changed then you can do that with the value signaling property.  So in your code you would need a reference to the SubVIs stop control in the main VI.  You could then set the value signaling prorperty on it and the SubVI would process the value changed event.

Let me know if that clears it up.  I am working on another example, but have been really busy and in the end yours turned out better then mine :).

[DonRoth]

Well it looks like we have come full circle.  I was hoping NOT to mix user events with the queuing strategy but what you have done makes perfect sense and it executes beautifully.

I first thought about the value signaling property strategy but I thought that might only work from within a VI and not remotely; I never did test it but when I have a chance I will.

I don't know if you noticed, I do use a LV2 style global here (not needed for the example per se but used to transfer the file position for a dummy waveform read after the mouse coordinates have been obtained).

Thanks again.  It is good to have ideas to bounce off of folks.  I am still curious about the first point --> how to use a named queue in within several parallel running VIs, all having producer - consumer architecture with dequeing occurring in all consumer loops.   Can't see that this is possible without using several named queues (but we could still use the same strict type def enum having the global set of actions).

Sincerely,

Don

[Rashid]

Evan, are you sure that your stop event is really working?

I came across the same task - to stop subVI from the main VI and took your example as the start point.

When doing the same scheme in my VI I got nothing: my subVI is not stopping when getting the stop event.

I studied your example more carefully and came to conclusion that your subVI stops not due to stop event but due to VI.FP.Close method you call in stop case (see main VI). You've attached handler to subVI.Panel Close event and due to this your subVI stops. I put the breakpoint in stop event handler to see if LV runs the code there and it never get there.

Couldn't you check your solution, though maybe I'm wrong and don't get something.

By the way, later I tried to remove generating user event from your stop case in main VI to see effect and it worked perfectly without it.

I'd be appreciating your comments.

Best regards,
Rashid.

[Rashid]

Sorry, Evan, I was wrong.

User stop event is processed in event handler. My mistake was that I placed stop event and user stop event under

one handler. You wrote you couldn't place them together, and I thought it can't be done at all (i.e. there's no way to do it)

and was surprised when I did it without any problem. But another problem aroused - user stop event was being ignored after that 🙂

When I ran your vi as is - all became ok.

Best regards,

Rashid.

[VI_Guy]

Evan,

The code you attached is really neat and I am sure many of us will find it to be a very useful design pattern.  I do have one concern as sending FP event from subVI to the main VI using the queues as in your code.  That is the main VI loop must constant polling the queue.  For my application it is preferred to have the main VI loop idle and waiting for the event coming from subVI.   But I also found it was easy to implement sending an UI event from main VI to the subVI, but hard to implement it from subVI to main VI using User Events.  I wonder if you or anyone has a sample code that demonstrate this capability?

Thanks.

[tst]

The loop isn't polling. The dequeue primitive has a timeout input, which is -1 by default, meaning it stops and waits if the queue is empty.

To pass a user event created in the subVI to the main VI, you will need to use some global means of communication, like a global variable, a LV2-style global, a notifier or a queue to pass the reference to the main VI, which can then fire it. In Evan's code, there's a VI called I32_Global which demonstrates how to pass data using a LV2 global.

Of course, in that case, you need to make sure you fire the event only after you have the reference.

You can see some more example of dynamic event handling in this thread.

[VI_Guy]

Thanks tst for pointing out the behavior of dequeue function wired to the case structure in the loop.  Meanwhile I modified Evan's code by also registering the user event in the main VI loop and was able to send a user event from the subVI to the main VI.  So far it seems worked out nicely with user events goes both ways.