LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to use a event structure in a subVI

Solved!
Go to solution

I am trying to use an event structure inside a subVI.  The subVI has an array builder that builds arrays, and the event structure is used so that when the program is running, it allows you to change the elements of the array.  It works, but when I implement it inside a subVI, it does not work properly.  This is going into a subVI, because it will be a part of a much larger progrram, so it needs to be modular.

Download All
0 Kudos
Message 1 of 10
(8,290 Views)

@fghfghgfhfhg wrote:

This is going into a subVI, because it will be a part of a much larger progrram, so it needs to be modular.


That is not exactly a good reason in itself to make this a subVI.  Event Structures that work on the front panel objects of a VI should exist in that VI.

 

And I am greatly concerned about your blatent use of local variables.  You might want to rethink this architecture and just use wires.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 10
(8,267 Views)
Solution
Accepted by topic author fghfghgfhfhg

If you're using an event structure, it's not a subVI.  if you're worried about modularity, you shouldn't be using the event structure.

 

You seem to have a fundamental misunderstanding of modularity.  An event structure should be placed within a while loop.  If you have a while loop within a subVI, you've handed over control of your program to the subVI.  You're not modular at this point.  Your top level GUI has no control.  You'd have to create some asinine system of variables to pass data down to that loop to stop the loop and return to your main VI.  That's not a good design decision.

 

Instead of looking for a way to do something broken, you should spend effort trying to understand what you actually want to accomplish.  You should also spend some time learning how event structures work.

 

This application is small right now and it's already on the path to unreadable.  That's a terrible thing to do to yourself.  Break these habits now.  se variables only when absolutely necessary.  Use subVIs to accomplish individual tasks, not run the entire application.  With event structures, use a stop button value change event to not be held hostage by the timeout.  If your variable has "2" in it, you're doing something wrong.  There has to be something different between the setpoints, put that in the name.  If you want to make subVIs, create an icon.

 

But first and foremost, invest time in understanding dataflow

Message 3 of 10
(8,141 Views)

natasftw wrote: With event structures, use a stop button value change event to not be held hostage by the timeout.

All very good points.  But I actually prefer not having a stop button.  Why?  Because every single user of my applications instantly go to close the window to shut down the program.  Therefore I use the Panel Close event (usually the filter event).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 10
(8,098 Views)

@natasftw wrote:

If you're using an event structure, it's not a subVI.  if you're worried about modularity, you shouldn't be using the event structure.


I agree with most of what you are saying, but not this first statement.  I've used event structures in subVIs, but not in the way OP is.  Using an event structure in a subVI with user events is basically the same thing as having a queue in a subVI, and allows for a publisher subscriber design, which is more difficult to do with queues.  And a subVI that is a dialog will most often have an event structure.prompting for some input, and waiting for the user to enter data before being returned to the main VI calling it.

 

I've also seen subVIs that can help augment a main VI by registering for events on the main VI, and performing actions based on things happening elsewhere.  I'm not a big fan of this because it can sometimes be hard to know why a UI is behaving in a way, if some random subVI is causing things to do stuff via references, but it is a neat trick.

0 Kudos
Message 5 of 10
(8,086 Views)

I have used the "but it is a neat trick" when it was appropriate. I will ry to wave my ahnds and try to describe when it helped out.

 

Imagine you have an application with 100's of control and indicators. Those control/indicators are used in two different modes, configuration and run.

 

While in the configuration mode the GUI requirments are intense and need 50 or more events to support. By moving the configuratino related events to a sub-VI that uses dynamic event registration the nasty details of the keeping the GUI updated are sliced off from the rest of the applcation. Any changes or issues while in Config mode ... you know where to look... the configuration support sub-VI.

 

Yes there is very tight coupling between the sub-VI and the main VI and the sub-VI would hardly be very re-usable.

 

The sub-VI can register for the top level VI closing if you want.

 

So plese do not dismiss moving events into a sub-VI off hand. You may actually like it.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 10
(8,025 Views)

Hi there,

 

"You seem to have a fundamental misunderstanding of modularity.  An event structure should be placed within a while loop.  If you have a while loop within a subVI, you've handed over control of your program to the subVI.  You're not modular at this point.  Your top level GUI has no control.  You'd have to create some asinine system of variables to pass data down to that loop to stop the loop and return to your main VI.  That's not a good design decision."

 

I think I have an exception to this rule.  I have an event structure which only uses key events to send commands to a motor (e.g. up = increase speed, down = decrease speed, etc).  I'd like to have this manual control of the motor as an option for multiple VIs (but have the behavior controlled from one VI).  How can I accomplish this unless I'm putting an event loop in a subVI?

 

This is actually part of a more general query.  Sometimes I want a subVI to run a while loop.  I'd like to set up an architecture where my main VI is sending commands to a queue, and a subVI is dequeueing the commands and executing them.  Essentially a producer-consumer where the consumer (or producer) does not have to be written into the main VI.  This would let me create an architecture where I can write a main VI to send commands to the motor controller, without having to worry about defining the commands in my main VI.  The command definition would be separate and would be consistent across multiple applications.  Do you see what I'm getting at?  Any advice?

 

Thank you!

 

Edit: after thinking a bit more, the most general statement of my question is - how do I spawn a process in a subVI and return control to the main VI?

0 Kudos
Message 7 of 10
(5,795 Views)

@ben_psc wrote:

... Do you see what I'm getting at?  Any advice?

 

Thank you!

 

Edit: after thinking a bit more, the most general statement of my question is - how do I spawn a process in a subVI and return control to the main VI?


Maybe.

 

Take a look at the zip I posted in this thread many years ago.

 

It is most likely dated and not exactly what you are after but it may give you some ideas.

 

I uses dynamic event registration in a sub-VI that monitors button on the FP of the GUI to Dock/Undock a VI from a sub-panel.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 10
(5,784 Views)

Thanks for the link.  That's... a little advanced for me.  It looks like the secret is the Run VI method?

 

Take a look at this simple architecture and let me know what you think (I'll be honest I'm not even sure if it's working).  Is there any reason why I shouldn't write producer consumer loops like this?  If I asynchronously call a VI with an event loop looking for key inputs, will they register?

 

Thanks again for your time and advice.

 

To expand a bit:

 

My goal is to create a layer over the top of my motor controller so that other developers (mechanical engineers) can easily write applications.  I would like to make an object which includes the VISA reference as well as the command queue.  The methods of the object would correspond to the various commands accepted by the controller, but they simply add a command to the queue.  (I.e. the "set speed" sub VI would require the motor controller object input and a speed value input.  It would add a "set speed, X" command to the queue).  An asynchronous consumer dequeues the commands and actually sends them to the controller. 

 

In this way, the queue buffers VISA communication. The implementation details are hidden from other users who want to build applications with the controller.  They simply use the "create object" method to get a "motor controller" object, then wire it to the "set speed" vi to set a speed.  They don't need to worry about building a consumer loop into their application because it's already running in the background - the "create object" subVI kicks off an asynchronous consumer.

 

An offshoot of this is making the manual motor control subVI.  I'd like users to be able to simply drag in a VI and have basic manual control of the motor controller available to them.

Download All
0 Kudos
Message 9 of 10
(5,778 Views)

After more research, I think I'm just describing the actor framework.  It doesn't really work for my keyboard events, but it should for the rest of my tasks.

 

If anyone comes looking:

 

https://forums.ni.com/t5/LabVIEW/Actor-Framework-for-Dummies/td-p/3637691

0 Kudos
Message 10 of 10
(5,740 Views)