LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Two sub VI's inside a VI collecting data simultaneously

Back to the original post:

 

Don't make them sub vi's, make each one a seperate loop. You would have one producer for user events and two consumer loops for your data aquisition & stuff

0 Kudos
Message 11 of 17
(1,391 Views)

Hi there, i have a similar question to the first one. i have a VI that acquires data and i want to simultaneously run another VI with it that graphs the data. i dont want to graph the data on the same data polling VI, but instead use a button on data polling VI and when cliked would pop up another window with all the graphs. the graphs can be opened and closed as many times as possible. problem im having is that when i pop up another window for graph, data polling stops and when i close graphs, data polling starts again. help is really apprecited.

 

0 Kudos
Message 12 of 17
(1,305 Views)

Why don't you have 2 vi operating at the same time. One is doing the data collection and another waiting for you to click the button to initiate the graphing of the program. You can you a producer consumer loop to send the data or you can use a global variable variable that stores the data on a round robin fashion (that way memory comsumption is reduced but timing of data becomes more critical).

 

I use the latter because my timing and data requirements are not too critical, I do temperature plots of data every minute but collect every 5 seconds. If it messes up a bit it is not a large problem.

Message 13 of 17
(1,300 Views)

Joseph Loo wrote:

Why don't you have 2 vi operating at the same time. One is doing the data collection and another waiting for you to click the button to initiate the graphing of the program. You can you a producer consumer loop to send the data or you can use a global variable variable that stores the data on a round robin fashion (that way memory comsumption is reduced but timing of data becomes more critical).

 

I use the latter because my timing and data requirements are not too critical, I do temperature plots of data every minute but collect every 5 seconds. If it messes up a bit it is not a large problem.


Please do not use the global variable approach. Unless you are very, very careful this type of solution will end up causing you problems. Use either a shared variable (which IS different than global variable), an action engine/functional global or pass the data (which will result in memory copies and possible memory issues depending on the size of the data) using either queues or notifiers. There is NO protection when using global variables and you can easily run into race conditions.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 14 of 17
(1,293 Views)

If you read my comment, I said that my requirements basically does not have any race condition. I don't care if the data is over written or not. The information being display is basically so slow that the results will not be affected.

 

I had couched my answer to say that carefully.

 

I also program my VI so that there is only one vi that does the write and another does the read. Since the read VI is not reentrant, it should require a maximum of 1 copy. This is a very standard method in programming when dealing with global variable where a semaphore is not required to prevent any race or overwrite condition but to control the writes.

Message 15 of 17
(1,288 Views)

Joseph Loo wrote:

If you read my comment, I said that my requirements basically does not have any race condition. I don't care if the data is over written or not. The information being display is basically so slow that the results will not be affected.

 

I had couched my answer to say that carefully.

 

I also program my VI so that there is only one vi that does the write and another does the read. Since the read VI is not reentrant, it should require a maximum of 1 copy. This is a very standard method in programming when dealing with global variable where a semaphore is not required to prevent any race or overwrite condition but to control the writes.


With all the caveats you listed (which are accurate and will allow the global variable to work in this situation) I still think it is better to steer new folks away from using global variables. While you were careful to mention a few of these things in your reposes you were not as detailed as the explanation above. With a good design you can avoid global variables and in the end the design will be more stable. It is far too easy for new people to see "use a global variable" and run with that and fall into bad habits than too grasp all of the nuances of using globals in a safe manner. I have been able to avoid using globals for many years without any problems or issues. They certainly don't need to be part of your standard toolkit for buliding applications.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 16 of 17
(1,282 Views)
thanks alot guys 🙂
0 Kudos
Message 17 of 17
(1,238 Views)