Nested and Parallel loops timing

[VeeJay]

Also, on a totally different aspect. If you create a vi and use it at different places at the same time, Will LabVIEW be able to distinguish them separately with correcponding data? Like will it create clones at runtime?

BEcause this is what I noticed. I have a program that basically gets an array in and each iteration I add an element at 0th position and calculate 5 sample runtime average. I use this 5 sample runtime average program at two different locations. When I open the front panel of this program, I see data overlap from the both the programs that use it. But this doesn't happen when we use LabVIEW defined functions at different placees like daqmx read or daqmx start etc.

[Been bitten by LabVIEW]

---

@altenbach wrote:

It is all in the dataflow. 🙂

Have you tried running your mock up using execution highlithing?

• A wait is just like any other code that takes a certain amount to finish. It runs in parallel to other code in the same structure, and since it is typically the slowest part, it will determine the loop timing. If some other parts takes longer, it's presence is nearly irrelevant.
• Any structure that does not depend on any data or has received data on all inputs will execute as soon as possible.
• A structure (loop, case, etc.) cannot complete or go to the next iteration until everything in it has completed.

In your particular case, 

• When the program starts, loops A and B will start immediately, while loop C must wait for data from the ring constant, which is nearly instantaneous.
• Loop A and B will run unhindered individually for the duration of the program. Once they stop they cannot restart until the program is started again from the beginning.
• Loop C cannot loop unless a case is encountered that does not have any interactive code and can finish on its own. If the visible case "1" executes at any iteration of loop C, loops D, E, F, and G will start executing. Only if ALL FOUR INNER LOOPS complete, the case frame H is able to complete. Only if case H completes, loop C can go to the next iteration.
• For the program to stop, all loops must complete and stop.

(Sorry, without seeing the code, I can only comment on the visible cases. There is no telling what else is there!)

(Your ring is at "" and since it is a diagram constant and also outside the loop, it will get read exactly once at the start of the program and hten never again. You show case "1", which therefore never executes. I assume that the case selector will be in a shift register so it can actually vary as a function of state)

In any case, you program is poorly designed in general. Don't stack interactive loops!

---

One other thing.  Because of the outer loop C does it's test on the value of the stop button in the manner shown, it will be TESTED FIRST before the loops (or possibly at the same time).  This means that when the inner loops complete due to a stop, loop C will loop one more time because the value would persumably have been false before running the VI.  Use a sequence structure to stop this from happening.

A

[Been bitten by LabVIEW]

It won't create clones unless the VI is marked as reentrent.  It basicly blocks untill a call to that VI has completed and then allows the next caller to proceed.  If you are looking for speed and there is no external location that you are writing to in that VI, mark it as reentrent and such blocking will not occur, potentially speeding it up.

A

[VeeJay]

Ok This is how my actual VI looks like,. Just a screen shot of main and one case of State machine. The parallel loops are subvis.

@ been biiten,

I looked. Where would I hhave to mark the vi as reentrant?

VJ

[altenbach]

You only seem to have one instance of each subVI, so reentrancy is irrelevant.

I don't like it that some of your subVI inputs are on the right side of the icon.

Except for latch action booleans, your terminals probably don't need to be in the loop.

Your inner subVI are still blocking the big loop if they are interactive.

Why are you doing it this way?

[VeeJay]

---

@altenbach wrote:

You only seem to have one instance of each subVI, so reentrancy is irrelevant.

I don't like it that some of your subVI inputs are on the right side of the icon.

Except for latch action booleans, your terminals probably don't need to be in the loop.

Your inner subVI are still blocking the big loop if they are interactive.

Why are you doing it this way?

---

To make the program fit in one screen size, I had to move some subvi inputs to the right. If I stack them all to the left, the screen size increases.

I want those subvi's in the "Start Protocol" case to run when that case is selected. The only way it will come out of this case is when Start=False or some error has been detected in which case I am again making START=FALSE. Once that state is done, I send the "Wait" state value to the big loop to wait for further user interaction. The program is working perfectly btw, I just want to do more and use better programming principles and build this software to be robust and reliable.

Screenshot shows the start stop subvi in the "Start Protocol" case that sends the State machine value once test is stopped.

OH and regarding re-entrancy, each of these subvi's have smaller programs to do some calculations etc, which are used multiple times. And that is why I had asked my earlier question regarding clones because I see data overlap from 2 programs using the same functionl.

[Been bitten by LabVIEW]

Well, this looks like a dogs breakfast, which is poor as it makes readability and maintenance an issue.  Having inputs on right is counter intuitive given the LV paradigm, but if it is never to be looked at again (ie a one off) I guess it is ok.  How does the screen size increase if you have all inputs to the leftish side?

Reentrantcy can be set on the VI's property panel.  Ctrl-I (or just right click on the VI icon and go to Properties) then to Execution.

The 100ms wait will be done in parallel with everything else, so it will probably have no effect if your other VIs take longer.

As altenbach stated, terminals (except for latch terminals) need not be put inside the loop and can actually decrease performance as they have to be read unnecessarily.  Latch terminals are reset to their original state when read.

If you want to make it look tidier, there are alignment tools in the toolbar.

In Start_Stop.vi does Acc-PI have the ability to change from momenet to moment?  If not, it would be more efficient to have it outside the loop.

Hope this helps

A

[VeeJay]

---

As altenbach stated, terminals (except for latch terminals) need not be put inside the loop and can actually decrease performance as they have to be read unnecessarily.  Latch terminals are reset to their original state when read.

In Start_Stop.vi does Acc-PI have the ability to change from momenet to moment?  If not, it would be more efficient to have it outside the loop.

---

THank you for your reply. What terminals are you referring to? I am assuming the tonnes of contols and indicators inside the loop.

Acc-PI has a constant value through out the program. So, I will bring it outside the loop.

[altenbach]

None of these terminals need to be in the loop except for any latch action boolean (but it might nore really make a difference, not sure). I would also strongly recommend to place all references outside the main structure instead of possibly multiple instances in various cases of a case structure. If you have that many references (there has to be a better way!), you might want to make arrays or clusters of references to keep the terminals simpler.

Still, your execution order is a bit clumsy.

You don't need the comparison with "test end" and the value signaling property at all. Just place a "true" bolean constant inside the "test end" case and wire to the termination condition. Make the tunnel "use default if unwired" so the loop does not stop for other cases. Is there a reference to "test end" used anywhere?

Where is the event structure that listens for "test end"?

What is in the other cases of the case structure? 

Where is the "STOP" boolean terminal that has a reference in the upper left?

Why don't you attach your VI? It is very difficult to judge a VI by an image of the diagram.

[VeeJay]

Hi Altenbach,

Thank you for your comments. I have made some changes and have also attached the zip file with the whole vi. The dependent subvi's should be in the zipped folder as well.

Reg. Test End, I had initially used it for some purpose and then removed it. I forgot to take the terminal out. It serves no purpose currently. Thanks for pointing that out.

I will make the diagram more cleaner as an when I make changes.

The other cases of the structure can be seen in the main program titled "SM main vi 11_29_2010 old CSLV method" . that is the main vi.

I never know we could make use of "arrays or clusters of references" I will look into that. Makes the program more cleaner and easier to read.

The STOP boolean in the "Wait" case of the State machine.

ANY CRITICISM is welcome. This program works but I want it to be flawless. I have also been trying to get this into a Producer/Consumer architecture with queues but unsuccessful. Hence, settled with references for now.

Thanks!

VJ