From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to transfer value from within while loop?

Hi, I'm a new user who is confused about transferring a value from within a while loop to another code out of it so that both codes can run parallelly.

In the time switch VI I have programmed an automated switch to turn on/off at a desired timing. The output, either 0 or 1, will be the input for "Amplitude" in the func gen VI. I have tried combining both VIs, placing time switch while loop within the func gen loop, but the function generator would not run because it could not read any input for Amplitude.

Thanks.

Download All
0 Kudos
Message 1 of 5
(2,907 Views)

If you only care about the latest value, just use a global variable.


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 2 of 5
(2,901 Views)

There are many ways to pass data between two loops. Some of the more common are:

 

  1. Use a global variable. This does not allow you to have any sort of synchronization between the two loops and opens up all sorts of race conditions. However, if you have a single value that you do not care about timing and nothing should happen immediately if it changes (e.g. a lookup table), this is a good way to go. It is very fast. I, personally, avoid them due to the race condition issue.
  2. Use a local varialbe. This has most of the problems of the global, and most of the advantages. You can only read and write it on the VI it is created in. It is slower than a global. I only use locals to update and initialize GUIs, which is their intended use.
  3. Use a queue. This is a standard method for getting data from one loop to another during execution. It is point to point, so no broadcast. It is very fast and memory efficient. This is my "go to" method for point to point communication.
  4. Use an event structure and user events. This is a standard method for broadcasting data from one loop to multiple other loops. It is lossless, so every data packet will be received by every listener. This is much slower than the queue.

There are other data passing mechanisms, but they have fairly specialized use cases that do not come up very often. I would recommend option 3, the queue. A global or local might get you partially there quickly, but the lack of timing and synchronization will probably cause you issues in the future.

 

Message 3 of 5
(2,865 Views)

As option, i would also add FGV/AE as it is very useful to know the concept.

 

Norbert

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 4 of 5
(2,853 Views)

I agree that the functional global / action engine design pattern is useful to know, but have come to not use it very often. It is good for data encapsulation, but not messaging (which was the original question). It is also very easy for new users to misuse and create race conditions and inefficient code. Generally, I have found that if you have a problem that can be solved with functional globals, you can get a better solution using actors1 (not necessarily Actor Framework). Functional globals are great for quick solutions, but actors give you a more maintainable, scalable, long-term solution. LabVIEW lends itself to the actor model of software development, since it is inherently concurrent / parallel.

 

1 An actor is a free-running piece of code that has communication lines and responsibilities. In UNIX based operating systems, they are often called daemons. In LabVIEW, actors are usually implemented as a free-running, top-level VI which uses queues or events for commands and responds with queues or events. However, they can just as easily be another free running loop in the same VI (also using queues and/or events).

0 Kudos
Message 5 of 5
(2,802 Views)