LabVIEW
Multiple While Loops. Multithreading
@lolobosco wrote:The problem is that my subVI is an infinite while loop and when a make an asynchronous call to it, I can´t collect its results.
Have a look at my example posted above. You need "call and forget" and get the data in other ways.
In your original example, each loop did the same thing and I thought they would only differ in loop rate.
Are some of your subVIs reentrant or is only a single copy in memory at all times.
If you have many different subVIs, you could just place them all on the toplevel diagram. You could create an appropriate DVR that contains a cluster with data from all processes and each process just operates on the appropriate subset. Now add a while loop that reads out the DVR occasionally to display the information. It can even be bidirectional, where the main VI updates certain settings contained in the DVR and the subVIs read them at each iteration.
There are many, many ways to do this. Here's something that builds on my previous suggestion. Here we have process B and C doing different things at different rates.
Now I'm more confused. Sorry I didn't respond sooner, but I'm "out of town" with a slow WiFi connection and other things going on. My particular example was actually a pair of sub-VIs being called reentrantly -- 24 of the loops controlled 24 sets of VISA hardware that produced data we used to time/trigger the saving of video images, while the other 24 loops controlled 24 video camera that saved 5 second videos associated with the corresponding VISA event recorded in the first set of loops.
I'll try to explain, in broad strokes, how this works. I'm showing selected images, not Snippets, as there are too many sub-VIs (and the code is pretty involved), but will try to explain how this works. Keep in mind that this was developed about 4 years ago, works quite well, but hasn't been "updated" (I think the code base is still LabVIEW 2012, up from 2010).
The Front Panel of Clone Camera, referenced by the strictlhy-type (red star) Static VI Reference in the center of the image above, is shown below. Session Info contains, among other things, the root path to a folder for saving Video and Balance results (unique File Names are created on-the-fly from the unique Station ID, 1 .. 24, and time of event). The Clones are configured as Queued Message Handlers, with the Message for the Camera Clone (which the Balance Clone needs to call) being the second input parameter. The final parameter, the Station Info, contains the hardware pointers to the selected Camera and Balance.
We use an Action Engine to manage the Asynchronous Calls (in part to avoid having to run the Clone Reference wires all over the place when we do the final Wait and Collect operations (they are maintained inside this non-reentrant VI. The Start Async Action is shown below. You can see the various steps I use to go from a Strictly-Type Static VI Reference (brought in by Async Ref In) to get its Name (you can also get its Path, but Name might be safer) and Type, both needed by Open VI Ref, then use the Ref to drive Start Asynchronous Call, using Option 0x100 for Call and Collect, and saving the VI Reference for the Wait Async Action. We don't actually return data when we close everything down, but we do wait for all of the Clones to stop to avoid exiting the Main routine and leaving a detached Clone still running (the Main can't exit until all of the Clones say they've stopped).
When I got involved with this project, my colleague had a single VI that "did everything" and took about 5 large monitor screens across by about 4 vertical to contain everything. There were wires running everywhere, and the logic was very difficult to follow. As you can see, one of my contributions was to make (almost) all VI Block Diagram fit on a single screen, largely by creating a lot of sub-VIs that all did "one thing" (and, if that "one thing" could be broken down into several sub-things, that meant more sub-VIs). I was also a "nut" about neat wiring. It took a little extra time when initially coding each sub-VI, but we ended up with (a) something we could look at and quickly understand and explain, (b) something we could debug fairly easily, and (c) something that actually worked!
Bob Schor
Hello Guys,
I need an help here! I am using while loops, which the last while is used for state machine. I created one E (emergency) Stop button then made from this Estop button a 3 local variables. Which when I stop the button the measurement should stop directly or when the measurement is finished (the timer and DAQ and everything) just assig to one of the Estop Boolean False command, the measurement should be stopped. However, when I click Estop or when the measurement is finished my program get stuck in in the red circles where I noted. I can observe that with PROBE WATCH WINDOW that the program after shift registers doesn't move on to the last part. It tells me that after shift registers it is not executed.
Thanks in advance and looking forward for your recommendations.
HR
As you can see, in the following snip, this is the last while loop which is used as a state machine. When the measurement is finished, it goes to the last state and I tell here to give the True (Boolean) to ESTOP so that it stops. I dont know if you mean by that telling LV to exit the loops.
Pictures of parts of your code are not enough to determine the issue. One thing that I immediately see is a race condition, and you probably have more of those. Find a better way than local variables to stop your loops. It's difficult to recommend a solution without seeing your code. There is something else in your loops that is not exiting.
