problems of running two while loops in one VI

[Batistuta002]

Hi forum,

I am developing a project for continuous data acqusition purpose for two types of signals (voltage and temperature), each consisting of 20 channels. The sampling frequency is different therefore I used two timed loops of different period to adjust for the sampling frequency. This is within the VI which is deployed onto the target device. On the host VI, I put two while loops each containing a write_to_measurement express VI so I can log the data into two different filepaths. However when i execute the program, only one signal is recorded correctly while the remaining signal would only have one line of data. It seems like one of the while loop only performs on iteration while the other is running smoothly. Is this an example of memory starvation ? How can I solve this problem!! Any help in greatly appreciated!!! Thanks!

Vincent

[MoReese]

Can you post your code?  Are you sure the while loops are running in parallel?

[Batistuta002]

Hi MoReese,

I have attached the whole project. Inside the project, it also contains a lvm file showing what my problem is (only one line of data).

Honestly, I am not entirely sure how to define "parallel while loops" but they were meant to execute simultaneously to write data onto two different text files.

THanks!

[RavensFan]

Why are you using shared variables to communicate between your loops?

My guess is that the Stop shared variable is still set at True from a previous run at the time your loops start iterating.  So the 2nd loop only runs once.  Only once the 1st loop runs and the new False value is written to the shared variable does it get reset, but by then it is too late for the other loop.  A race condition caused by the shared variable.

I don't understand why you have both loops writing different data to the same file.  Isn't the data getting mixed up in the file?

[shoubeilee]

Thanks very much！

[Batistuta002]

Hi Ravens Fan,

The stop button is there so that I can stop both VI's (cRIO.vi and computer.vi) in one push of the button, which is also why I wired the Stop variable onto both loops terminal.

The two loops are actually writing data into two different files in two different folders, sorry it was confusing because both files have the same name but if you look at the filepath closely you will realise that they are indeed different.

I think you might be right with the stop variable True/False value. What can I do to fix this problem but at the same time have the two loops stop in one button?

Thanks!

[MoReese · Accepted solution]

What Ravens Fan was asking is why are you using shared variables to stop the loop?  Are you doing something remotely?  Just use a local variable in your second while loop to stop it.  You will have to change the mechanical action of the stop button, but this would be the way to do it.  Stop buttons are great for debugging and development, but I typically will rely on another mechanism for stopping the program if it is running outside of the LV environement.

[Batistuta002]

If I use a local variable to stop the loop, can I still shut down two VIs (computer.vi + cRIO.vi) in one press of the stop button? Sorry I am quite new to Labview so I thought shared variables can communicate through two seperate VIs while local variable cannot. What do you exactly mean when you said that I will have to change the mechanical action of the stop button?? Thanks for your time.

[Batistuta002]

Thanks for the help guys!! Now I have used a local variable to stop the two loops and it's working fine so far.

But I am still keeping the shared variables so that I can stop the other VI at the same time as well. So far its working smoothly but I am wondering if there may be a better way to stop two VI's at the same time? Because I was told that shared variables contain overheads and if possible I should avoid using too many shared variables. Thanks!

[RavensFan]

I would continue to use the shared variable to communicate between the VI's on different targets.  The only other ways would be through TCP/IP communication schemes that you'd have to set up yourself.  I don't see any benefit to that.

I would just make sure that you set the Stop shared variable to false sometime before you restart your remote VI's so that they are stopping immediately once they are restarted because of an old, stale, true value remaining in the shared variable.