passing data from a subvi to the top level with continuously running loops

[bennymacca]

Hi All,

This is a very simple question, for some reason the data available at a subvi indicator is not making it to the top level vi. I think it might be something to do with the while loop I am using but I cant figure it out, any help will be appreciated. I don't think I fully understand how the data gets out of a continuously running loop.

GPSdisplay runs a driver called GPS.vi (im not worried about my event structure just yet which might be wrong, but I am yet to test that bit yet) Probe 1 should have the values from GPSCluster

Loop within GPS.vi. GPSCluster (Probe 2) is being updated correctly

I cant work out why the data is not being passed to GPSCluster in the top vi

[P@Anand]

---

@bennymacca wrote:

Hi All,

This is a very simple question, for some reason the data available at a subvi indicator is not making it to the top level vi. I think it might be something to do with the while loop I am using but I cant figure it out, any help will be appreciated. I don't think I fully understand how the data gets out of a continuously running loop.

GPSdisplay runs a driver called GPS.vi (im not worried about my event structure just yet which might be wrong, but I am yet to test that bit yet) Probe 1 should have the values from GPSCluster

---

You cannot create a Value change event for an indicator unless you are using the Value(signaling) property to trigger the event. 

Unless the stop condition for the GPS.vi is True in any one of the case your probe 1 never going to have the data. Just enable the Highlight Execution and visualize what is happening, you might see that the execution is trapped inside the GPS.vi. Even in your probe you got the clear information that it is not executed. Try to follow some standard design pattern and fit in your requirement to get a better result. 

As a quick solution remove the while loop inside the GPS.vi and test it.

[bennymacca]

thanks for your reply. 

inside GPS.vi, the other cases have a True conditional to quit out of the loop, except for the read case - I want it to continually read in strings until i tell it to stop or quit. I realise execution is getting trapped inside the read case of gps.vi, but how do i stop this? there has to be a way to have multiple running while loops and get data from all of them, correct?

[P@Anand]

Yes. Then don't take the Output of the VI instead use an LV2G or a global variable to pass the data between VIs. Execute the "Read" operation seperately and remove the Sequence structure and force the data flow through error wire.

[bennymacca]

im pretty sure functional global variables are what I need, ill go back and brush up on them, thanks.

[David_NMRSA · Accepted solution]

Hi bennymacca,

I think you are on the right track with an FGV. You can do this fairly easily with the GPS vi that you have.

Before I go any further, your GPS while loop will only return the last reading, and because the "Read" boolean output state is FALSE, it will not stop. Do you see it exit at all? From the logic I read, once entering this while loop it won't stop until told to.

There are a 3 options you can try.

1) Use an FGV, as you are looking into. To do this you will need to change the state boolean to TRUE and put shift registers in for the GPSCluster - to parse the information around, holding it each time the vi is called and exited. Outside the while loop you will wire up the Cluster to the indicator that you wish to collect (OR, you could have it inside the case statement where it is read - be careful here, though). 

2) in the main code, above the sequence frame you can place the GPS vi while loop (the "Read" one), having the state boolean wired to a Stop button local variable. This while loop will start depending on how LV feels, so wire an error line to both the While loop and Frame start (indicating that both are to run in a parallel fashion), OR you can put it in a case statement and say 'go' when you want to start reading. With this while loop, you can then output the Read data directly into your Cluster variable as it is generated.

But, with (2) you are moving yourself away from the purpose of the GPS vi, which would be to bring all functionality of the GPS functionality into one sub vi - which is a good idea.

3) put a condition on the "Read" case statement boolean state - only make it TRUE when you wish to stop reading data (do you have a time or condition you can refer to here?). Even doing so, you would/may still need shift registers on your while loop to retain data for each iteration.

I hope all of that helps. Cheers. David.

[bennymacca]

Thanks a lot David - I think an FGV is the way to go - I think as a new programmer they have been the concept that it has been hardest to get my head around!

[David_NMRSA]

Depending on your background there are a number of ways to describe what is going on.

For example, the FGV is called with a function in mind, such as "Run", "Read" or "Stop". When called, the FGV will perform its action and then return to the main program (it has to). Before it returns it 'saves' all information placed into the shift registers for the next time it is called; by placing them in the shift register at the start of the loop (on the left). In other words, they 'latch' the information for the next time you call it.

Once you get your head around them you'll start to see just how powerful they are, and enjoyable! They can really keep your code clean and organised. They act nicely as that, 'go and get me that, slave!' approach. 😄

good luck.

[bennymacca]

Figured it out, as mentioned by David_NMRSA and P@Anand my problem was that I was trying to use GPS.vi as a GFV for all cases except read, but then have a continuously running loop for the read case, so the vi would then get stuck in there.

To pass data to the display loop I have also implemented a user event, as this will suit my needs as the program scales with other sources.

Thanks for your help everyone!

Top Level tester vi - GPS.vi also generates user events

GPS read - complete with brand new true constant

Display Code - registers for my user event and then passes the data (with some formatting) to the GPSmonitor control.

[David_NMRSA]

very good - well done! There are always different ways to do things, but you'll see where improvements can be made in time.