Putting a timed loop in a sub-vi

[AlexDubya]

Hi ThSa, I believe I am still confused. The equivalent excerpt PNG you provided appears to differ from my subvi.vi file only in that the control for the timed loop is placed outside the loop. It makes sense to me that if this control is placed outside the loop then the loop will never by able to be stopped by clicking the control (because the loop will never test the value again). However, the top-level.vi never changes values as I would expect it to. I fully understand why nested timed-loops are not support/a bad idea but my end goal here would be to have a while-loop nested in a timed-loop BUT the inner loop (the while loop) would be inside a subVI. That is the functionality I cannot seem to make work. The loop continuing "forever" is not ideal behavior (I would like to have a "soft stop" option) but I do not think that is the fundamental misunderstanding I'm having.Could you provide any method for having the top-level VI's data "update", either the final value or the intermediate?Thank you very much,-Alex-

[ThSa]

Alex, my picture above is simply the equivalent BD of your top level VI and sub VI.Anyway, to establish online monitoring and controlling of a subVI there are several options available. The following list is a ranking - ascending order - of the preferred methods which should be used for RT:- Global Variable (++++) [shared ressource]
- Functional Global Variable (FGV) (+++) [might be a shared ressource]

- Queues (++)
- Shared Variable with RT FIFO enabled (++++)
- RT FIFO (built-in function of LabVIEW RT) (+)
Legend:++++: very easy to use;+++: easy to use; ++/+:  might get complicated,  depending on the complexity and the data type Additional information on queues and RT FIFOs:Queues: Same procedure like under windows. Depending on the
variety, it might become difficult to handle; pitfall can be the
timeout which is default "-1".RT FIFO: Nearly the same procedure like for queues, with the restriction on specific data types and the default timeout of "0".The correct catchword for the above quoted methods is "inter-thread communication". Depending on the required performance and all the other peripheral stuff you should use one of the above mentioned.If you have specific questions, please come by.ThSa

[Jimmie A.]

Hello,
Look at the attached example that showcase basic RT FIFO functionality. You need LV 8.5 since it is saved in that version.Message Edited by Jimmie A. on 11-28-2007 07:55 AM


RT FIFO.zip:
http://forums.ni.com/attachments/ni/170/286921/1/RT FIFO.zip

[Jimmie A.]

Hello,
If you are using tunnels the following applies: tunnel in = each value is the same, the value passed in, tunnel out = takes on the value of the last iteration
When using shift-registers the following applies: shift R in = first iteration takes on the value passed in, nth iteration takes on nth-1 value shift R out = same as tunnel out.
I typically use shift-registers in order to have modular code that can be reused on other targets. For an example if you program an Embedded target and you pass a large array through a loop tunnel, the original value must be copied into the array location at the beginning of each iteration which can be rather costly. A shift register on the other hand doesn't perform this copy iteration.
See this document:
<a href="http://zone.ni.com/devzone/cda/tut/p/id/3747" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/3747</a>