Putting a timed loop in a sub-vi

[AlexDubya]

We have multiple people working on one project and it is becomming difficult to manage versions between each other developing labview code.

Normally, I'd put code into subvis and modularize the problem in that manner. However, in this project we're using multiple timed loops and some of them share data. This means that frequency and priority of the timed loops are important to keep track of but with multiple people adding and removing loops AND the fact that we can only work in one file its becomming a hazard.

I tried to fix this by putting a timed loop inside a subVI but it gives me a warning about front panel indicators. How then can I pass data "back" to my higher level VI?

Maybe there is a more prescribed way of handling this kind of development with LabVIEW that I am unaware of. I'm open to any thoughts or suggestions anyone has.

(My project is running on LVRT on a 8196-PXI. We're asking the box for a pretty high level of performance so I'm having to keep that in mind when I decide what to put in a subVI and how finely grained I want the subvis).

[Amanda_H]

Hi Alex,

Which version of the LabVIEW Real-Time Module are you using in your application? This KnowledgeBase article describes that a bug fix in LabVIEW Real-Time 8.5 fixed the problem of front panel updates stopping several subVIs were open or called at once.

I've also included a few other KnowledgeBase articles here and here that specifically address front-panel subVI issues. One mentions FPGA hardware, but is applicable to other Real-Time hardware as well.

I hope this helps!

[AlexDubya]

Hi Amanda,

I'm using Labview 8.5 and the 8.5 RT module.

Here are two very tiny VIs. I tested the VI at 500ms loop time and 100 priority. I don't think these values affect this problem (500ms it easy for a desktop PC with Windows).

When I run the top-level.vi the value indicator does not update. I realize that this value is updating from within the inner loop but when i have a second indicator outside the time loop as an output of the subvi I also see nothing.

So it seems to indicate to me that the timed loop isn't really executing when it is ran as a subvi.

I read the pages you linked me. I initially hoped that setting the sub-vi's execution to be reentrant (in Vi Properties) would help/solve the issue but the behavior is identical with it set to reentrant or not.

Even more curious, if you click stop on the top-level vi, it clearly isn't sending that command to the sub-vi because top-level.vi never exits of its own accord (I have to use Abort Execution).

I don't know if this qualifies as a bug but it seems helpful to document it.

[Amanda_H]

Hi Alex,

I would recommend moving the loop outside of the sub-VI in order to see this update. I don't think this is an issue with real-time programming (timed loops), as I recreated it with a while loop. Let me know how this works.

[ThSa]

Alex,
good joke 🙂
Your problem is neither related to RT nor to LabVIEW or TLs or whatever.
This issue is simply a programming mistake.

"A node (in your case SubVI) is executed when all inputs do have a valid value. The outputs of a node are available when the execution of the node is finished."
Your example may have two states: Run once or infinite.

Attached please find an equivalent excerpt of your SubVI when running it as top level VI:



To have a modularized application with TLs ensure that you never ever use nested TLs.
Under RT you may use up to 128 TLs (preferable with different priority levels) which are running in the same thread.

To establish a high-performance communication between the TLs or between several SubVIs either use LL RT FIFOs or the Shared Variable with RT FIFO enabled.

Pojundery,
ThSa


Message Edited by ThSa on 11-20-2007 09:13 AM

[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

[Devin_K]

Alex,

I just wanted to expand on what ThSa was saying.  Due to the nature of LabVIEW's dataflow model, your sub-vi will execute when it has received all of its inputs (including period, priority, and stop).  These inputs are only read when the sub-vi starts its execution, and do not continue to read if the values change.  In your example, a value of false is passed as the initial value of the "stop" control in your sub-vi.  Pressing the stop button on your top-level vi after this point will not update the value of the stop control in your sub-vi.  You can see this behavior for yourself by changing the stop button on your top-level vi to a true boolean.  Notice that when this happens, the input value of the stop button in your sub-vi is "true", so the loop runs once and returns the appropriate values.

The same behavior applies for the outputs of your sub-vi.  Although your "value2" control is updated in every iteration of the loop, it will not return a value to the top-level vi until execution of the sub-vi has finished.

In order to pass data between VIs in your application, you will need to use one of the methods suggested by ThSa.  As he mentioned, RT FIFOs and Shared Variables with RT FIFO enabled are the preferred method of doing this.
The following link explains how to use RT FIFOs:
Real-Time FIFO for Deterministic Data Transfer Between VIs

Shared variables are explained in the following link.  See the Single-Process Shared Variables section for information regarding shared variables with RT FIFO.
Using the LabVIEW Shared Variable

[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

[AlexDubya]

Thanks for the example Jimmy. At this point I've become quite familar with RT fifos but I had one question about your implementation - I see you use shift regsiters to pass the reference to the RT fifo between loop iterations. Currently all my implementations simply use a tunnel to pass the reference to the fifo. Does a shift register improve performance over a tunnel?