LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Race condition(?) between Main VI and SubVI in Subpanel and othe

Solved!
Go to solution

Did you try tossing that OpenG VI in your sub-VI?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 11 of 30
(608 Views)

Yes I did, the Fit to Largest Decoration one

0 Kudos
Message 12 of 30
(580 Views)

@Ben wrote:

Did you try tossing that OpenG VI in your sub-VI?

 

Ben


Are you saying that's what's causing the error of the Subvi's controls not responding when loaded into the Subpanel of the main vi?

 

Really, the fitting of the subvi into the subpanel is the least of my problems right now and I keep getting solutions to questions I did not ask....

0 Kudos
Message 13 of 30
(557 Views)

@nikvl wrote:

Really, the fitting of the subvi into the subpanel is the least of my problems right now and I keep getting solutions to questions I did not ask....


Well, at least you get solutions Smiley Wink.

 

These are answers to the question you asked, they are just not what you want to hear.

 

I had a look, but it won't run though (I never install DAQmx).

 

Where are some more suggestion you didn't ask for:

 

Why is stop true in the time out event in the sub VI?

Why is there a time out event at all in the sub VI? It's not used, so remove it.

Remove the 200 ms wait, it doesn't do any good. The event structure does the waiting much better. Why wait 200 ms parallel to the event structure that waits until an event?

Remove the 200 ms wait, from the main loop too. 

Why not simply put the main TO Event stuff before the loop, and remove the TO?

Why not use a static VI reference to get a regerence to the sub VI?

 

These issues are still very relevant. Bugs hide in clutter. Remove the clutter, the bugs appear.

 

Anyway... So the problem that remains is how to get a reference to the stop button in the main, right?

 

Pass a control reference DVR (or control reference queue or even a control reference to a control reference (Smiley Very Happy)) to the sub VI. When it runs, set the control reference to the stop button in the DVR (or queue or control reference). Now the main can get the stop control reference from the DVR (or queue or control reference control).

 

Better solutions to this have been suggested, I'm sure there are some examples (shipped with LabVIEW) covering user events.

 

Yet another option is to register the sub VI event structure to the Main VIs stop button value change event. Pass the control reference of the main VIs stop button to the sub VI. Use a dynamic event registration, and add an event for it. Now the sub VI stops when the main stop is pressed.

Message 14 of 30
(546 Views)

Why is stop true in the time out event in the sub VI? 

Why is there a time out event at all in the sub VI? It's not used, so remove it.

The timeout event and true boolean shouldn't be there in the real Sub vi. I admit this simplified Sub vi was made very hastily, hence the mistakes.

 

Remove the 200 ms wait, it doesn't do any good. The event structure does the waiting much better. Why wait 200 ms parallel to the event structure that waits until an event?

Remove the 200 ms wait, from the main loop too. 

That was part my troubleshooting. There was no wait in the begnning.  When Highlight Execution was switched on, they seem to work find and clicking the OK/Stop of the Subvi through the Subpanel worked. This did NOT happen when Highlight Execution was switched off, whereby after the Sub vi was loaded into the Subpanel, clicking the Sub Vi controls through the Subpanel didn't work anymore i.e the controls were unresponsive. Which brings us back to my original inquiry if it was a timing problem hence me just putting wait times around to see if it solved the problem. But it did not....

 

Why not simply put the main TO Event stuff before the loop, and remove the TO?

Well at first the idea was to initalize the DAQ first when Main is run (and I got the idea of placing it in the Timeout while I browsing the forum), have an indicator to show it's 'Online' and then the user can proceed to choosing which Subvi to place in the Subpanel; such that I didn't have to reinitialize everytime the Subvi is loaded. Since the original program involved configuration files (which is accessed and/or altered by user through the Main vi) and whatnot, I simply dumped everything into the Subvi for this example.

 

Why not use a static VI reference to get a regerence to the sub VI?

Isn't the reference I have in the Main already a static VI Reference? Otherwise, how do I check if it is?

 

These issues are still very relevant. Bugs hide in clutter. Remove the clutter, the bugs appear.

 

Anyway... So the problem that remains is how to get a reference to the stop button in the main, right?

 

Pass a control reference DVR (or control reference queue or even a control reference to a control reference (Smiley Very Happy)) to the sub VI. When it runs, set the control reference to the stop button in the DVR (or queue or control reference). Now the main can get the stop control reference from the DVR (or queue or control reference control).

 

Noobie question but what is DVR?

 

Better solutions to this have been suggested, I'm sure there are some examples (shipped with LabVIEW) covering user events.

I've looked at them but they're mostly simple examples that I'm having a hard time figuring out when it's more complex. Even the Subpanel example just has 'Abort Vi' to stop the Subvi which Smiley Frustrated

 

Yet another option is to register the sub VI event structure to the Main VIs stop button value change event. Pass the control reference of the main VIs stop button to the sub VI. Use a dynamic event registration, and add an event for it. Now the sub VI stops when the main stop is pressed.

This seems like a viable option... would the dynamic event registration be in for the Main vi Event structure or the Sub vi event structure?

 

Frankly one workaround is to just ensure the user press the Stop button of the Sub vi first and then only the Stop in the main (which could be used to just remove the sub vi). But if the Sub vi controls are not responding when running in the Subpanel....which brings us back to the first and main problem... Smiley Wink

 

But maybe I should ask a better question... since there are two Event structures (in the Main vi AND Sub vi), how does Labview wait for events for them both or do I have to do something (I have no prior experience to registering for events or dynamic events, only the usual single queued producer/consumer)

0 Kudos
Message 15 of 30
(520 Views)
Solution
Accepted by topic author nikvl

I see you create a queue in the sub-vi. Why not create it outside in the Main and send it to the sub-vi as an input, that way you have the queue in the main to use for commands!

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 16 of 30
(511 Views)

@nikvl wrote:

@Ben wrote:

Did you try tossing that OpenG VI in your sub-VI?

 

Ben


Are you saying that's what's causing the error of the Subvi's controls not responding when loaded into the Subpanel of the main vi?

 

Really, the fitting of the subvi into the subpanel is the least of my problems right now and I keep getting solutions to questions I did not ask....


Scatter some "Error Cluster" indictors about in the inserted VI. If there is an error happening you could get a clue what the error is and where it is happening.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 17 of 30
(501 Views)

@nikvl wrote:

But maybe I should ask a better question... since there are two Event structures (in the Main vi AND Sub vi), how does Labview wait for events for them both or do I have to do something (I have no prior experience to registering for events or dynamic events, only the usual single queued producer/consumer)


Each Event Structure has its own event queue.  An event only goes on the queue if the structure is registered for it.  So you can right-click on the Event Structure and choose an option to "Show Dynamic Event Terminals".  You will now see new tunnels.  Now if you go into the Dialog & User Interface->Events palette, you will see a Register For Events node.  Put that on your diagram.  You can wire a control reference to the property and choose which related event you want to register for.  The output of the node will be the registration that you can wire up to the event terminals on the Event Structure.  You can now make an event case to handle that event you registered for.

 

Look in the Example Finder (Help->Find Examples) for Dynamic Event Generation for an example.


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 18 of 30
(497 Views)

@crossrulz wrote:

...a Register For Events node.  Put that on your diagram.  You can wire a control reference to the property and choose which related event you want to register for.  The output of the node will be the registration that you can wire up to the event terminals on the Event Structure.  You can now make an event case to handle that event you registered for.

 

Look in the Example Finder (Help->Find Examples) for Dynamic Event Generation for an example.


Adding to the above...

 

That is where the option to "lock front panel..." for dynamic events can be found.

 

Also note that dynamic events allow for re-registering at run time if you want to turn on and off events (see here).

 

Ben

 

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 19 of 30
(490 Views)

@nikvl wrote:

Why not use a static VI reference to get a regerence to the sub VI?

Isn't the reference I have in the Main already a static VI Reference? Otherwise, how do I check if it is?


You're opening a reference with Open VI Reference. That is a dynamic way to open a reference, as the referred VI can change dynamically (by changing the input path\name). A static VI reference (use quick drop) accepts a single VI by dropping the VI on the static VI reference, and it won't be able to change during run time. Added benefit is that the VI gets included in an executable, while the dynamically opened VI will not.

 


@nikvl wrote:

Pass a control reference DVR (or control reference queue or even a control reference to a control reference (Smiley Very Happy)) to the sub VI. When it runs, set the control reference to the stop button in the DVR (or queue or control reference). Now the main can get the stop control reference from the DVR (or queue or control reference control).

 

Noobie question but what is DVR?

A data value reference. Often compared to a C\C++ pointer, as it has similar features. It allows shared data, but (and this distinguishes it from a C\C++ pointer) also provides safe asynchronous access.

 


@nikvl wrote:

Better solutions to this have been suggested, I'm sure there are some examples (shipped with LabVIEW) covering user events.

I've looked at them but they're mostly simple examples that I'm having a hard time figuring out when it's more complex. Even the Subpanel example just has 'Abort Vi' to stop the Subvi which Smiley Frustrated

There's not that much you need to know. You need to be able to:

+ Use "Create User Event".

+ Pass the reference to the caller and the user of the event.

+ Use "Register For Events" to register the event structure for events (use show dynamic events terminal).

+ Use "Generate User Event" to trigger the event.

 

In this scenario it's really not that different from a queue, conceptually (create, read, send).

 


@nikvl wrote:

Yet another option is to register the sub VI event structure to the Main VIs stop button value change event. Pass the control reference of the main VIs stop button to the sub VI. Use a dynamic event registration, and add an event for it. Now the sub VI stops when the main stop is pressed.

This seems like a viable option... would the dynamic event registration be in for the Main vi Event structure or the Sub vi event structure?

That doesn't matter. It's both possible. Register and pass the registration reference, or pass the control reference and register in the sub VI. I'd prefer the latter.

 


@nikvl wrote:

But maybe I should ask a better question... since there are two Event structures (in the Main vi AND Sub vi), how does Labview wait for events for them both or do I have to do something (I have no prior experience to registering for events or dynamic events, only the usual single queued producer/consumer)


This works in ways that you usually don't have to worry about it.

 

All event structures (except in the same VI, don't do that!) that register for an event get the event.

 

The moment the registration takes place, the events are buffered. This could in fact cause problems when you never 'consume' the events in an event structure. For instance when you register for events in a sub VI, and not always use the events. Of course closing the registration also stops the queueing of events. That's why I usually prefer to register close to the event structure.

0 Kudos
Message 20 of 30
(458 Views)