LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

front panel calls a subvi that calls other subvi's

Solved!
Go to solution

@Mark_Yedinak wrote:

can be the right method for passing data under certain circumstances.


That's why right there. For a novice to intermediate developer, getting those circumstances correct can be very troublesome.

Charles Chickering
Architecture is art with rules.

...and the rules are more like guidelines
0 Kudos
Message 11 of 17
(641 Views)

I was suspecting that something was wrong with those watches when I was testing it with highlight execution but I couldn't think what the solution is! Great solution thanks! Smiley Happy 

Why doesn't it update the meter on the MAIN vi even though it is referenced?

 

0 Kudos
Message 12 of 17
(622 Views)
It is updating. Note that sub vi 1 & 2 only have a reference to main sub vi. They only update main subvi in the loop. Main is only updated from main subvi when subvi 1&2 finish. If you want subvi 1&2 to update main, then you need to pass main's reference to those subvi's.
Charles Chickering
Architecture is art with rules.

...and the rules are more like guidelines
0 Kudos
Message 13 of 17
(597 Views)

What I did is that I dragged the reference of the meter from the MAIN to the front panel of every subvi so that a knob refnum (strict) is created, but nothing changed..

Is there any point of doing it with this way I'm trying to do it? I mean by having a main with a subvi in it that has other two subvi's in it. Because I could simply do it by placing the code of the two subvi's in the main SUBvi and don't have to worry about references.

0 Kudos
Message 14 of 17
(572 Views)

Did it! now it updates to the main vi as I wanted!! Thanks for the help! Below is how I did it. 

0 Kudos
Message 15 of 17
(558 Views)
Solution
Accepted by topic author chis20

I made a couple of modifications to your solution to point out a  couple ways to reduce complexity. I also spent more time thinking about the auto reset issue and why it didn't work. Here's my attempt at an explanation:

1. Program starts, descends into the for loop in main SUBvi

2. Elapsed time (SubVI1) starts (automatically logs start time, we'll call this T0)

3. We loop until elapsed returns True (time is now T4), Auto Reset has now internally set the start time to T4

4. Elapsed time (SubVI2) starts (logs start time as T4)

5. Loop until True, (time is now T8), Auto Reset has now internally set the start time to T8

6. For loop in main SUBvi iterates to second iteration

7. Elapsed time (SubVI1) returns true on first iteration BECAUSE auto reset set the start time to T4, we are now beyond T8, hence time has elapsed

8. Elapsed time (SubVI2) appears to run as expected because we are only a few processor cycles away from T8, hence it runs until T12 and then execution is finished

 

So, in short, my suggestion of using iteration = 0 was the correct way to solve your issue.

 

Attached is the updated main SUBvi with my modifications.

Charles Chickering
Architecture is art with rules.

...and the rules are more like guidelines
Message 16 of 17
(542 Views)

Thanks Charles for the help! You have right about your comments. Also I would agree about your thought on auto reset. It sounds very logical and explains everything. Smiley Happy

0 Kudos
Message 17 of 17
(534 Views)