LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TOO MANY Parallel Loops in Main VI

Hi,

 

I have heard that all vi should fit on one screen.  I have a main vi that have multiple parallel loops.  The first loop is to detect the user request, the second loop is to perform the request, the third loop is to control my samples with digital out and analog out, the forth loop is to display analog in data on the screen, the fifth loop is to empty the daq buffer continuously, and the sixth loop is to log data into a file.  If I have 6 loops in parallel, it is impossible for this vi to fit on one screen.  Is there a better way to organize this?  BTW, this is a multiple producers and multiple consumers architecture.  Thanks!

------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 1 of 6
(3,746 Views)
You should be able to fit all of this on one screen.  Create Subvis for all of the parallel functions so that the while loops can be smaller.
Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
0 Kudos
Message 2 of 6
(3,744 Views)

I agree with VADave.  All my parallel loops except the loop containing the GUI handler/event structure are typically in subVIs which either do not connect via wires to anything or which may have inputs such as queue references only.  The icons for these independent subVIs are placed along the bottom of the diagram below the GUI loop.

 

Lynn 

0 Kudos
Message 3 of 6
(3,731 Views)

"jyang72211" <x@no.email> wrote in message
news:1235655606987-860875@exchange.ni.com...
> Hi,&nbsp;I have heard that all vi should fit on one screen.&nbsp; I have a
main vi that have multiple parallel loops.&nbsp; The first loop is to detect
the user request, the second loop is to perform the request, the third loop
is to control my samples with digital out and analog out, the forth loop is
to display analog in data on the screen, the fifth loop is to empty the daq
buffer continuously, and the&nbsp;sixth loop is to log data into a
file.&nbsp; If I have&nbsp;6 loops in parallel, it is impossible for this vi
to fit on one screen.&nbsp; Is there a better way to organize this?&nbsp;
BTW, this is a multiple producers and multiple consumers architecture.&nbsp;
Thanks!

An ideal Vi should fit on screen, because it provides more overview.

One way to "hide" the parallel loops, is but putting them in sub VI's. This
is only useful if only one loop deals with UI stuff. If one loop does one
type of DAQ, it's easy to put this in a sub VI. I'd start this sub VI
dynamically in the UI loop, but you might as well keep it as a normal VI
running parallel of the UI loops.

But I wouldn't force this. There is absolutely nothing wrong with a few
parallel loops, where each loop takes the full width, and 60% of the height
of the screen! The reason this became a rule, is to avoid diagrams with: one
big sequence. In it, four steps. In each step, a nested case, while loop,
two parallel for loops and in there again two or three sequence structures
with 8 steps, and 40 nodes kludged together. But shrinking something like
this (with a few more sequence structures) is not helpful.

I think there is nothing wrong with a few (perhaps un to 5 or 6) parallel
loops, as long as there is a logic behind there existence. I often make a
DAQ VI. In it, there are perhaps 10 loops that read data from serial, tcp/ip
and fieldpoint devices. So, would it be helpful if I put them in subVI's? I
think, in this case, not. The reason for the rule is it provides a better
overview, and this solution would give *less* overview, so, not a good
idea...

I'd say: if there is a good reason, and you keep it structured, it is just
as good as hiding the same stuff behind (dynamic) sub vi's...

There are some benefits in keeping your diagrams small. It forces you to
separate your code, and those peaces are more likely to be simpler (thus
less errors), and more reusable. In the above example of the DAQ loop,
putting the loops in seperate subVI's, would result in reusable DAQ VI's. So
it's a delicate issue, don't follow the rules blindly, try to see why they
are there.

Regards,

Wiebe.




0 Kudos
Message 4 of 6
(3,703 Views)
Thanks for the great input!  On a side note, what did you mean by dynamically starting a subvi in the user interface loop?  Are you talking about the dynamic event in the event case structure?  I don't see how they are related.  Can you explain?  Thanks!
------------------------------------------------------------------

Kudos and Accepted as Solution are welcome!
0 Kudos
Message 5 of 6
(3,681 Views)

"jyang72211" <x@no.email> wrote in message
news:1235673607926-861202@exchange.ni.com...
> Thanks for the great input!&nbsp; On a side note, what did you mean by
dynamically starting a subvi in the user interface loop?&nbsp; Are you
talking about the dynamic event in the event case structure?&nbsp; I don't
see how they are related.&nbsp; Can you explain?&nbsp; Thanks!

Instead of putting a VI on your diagram, you can use VI Server to control
VI's (start them, end them, open front panel, etc.). Search the help and
forum for VI Server, and you'll learn more about it. There are some
benifits, but if you search the forum for "dynamic VI", you probably find
out soon enough.

The only relation between dynamic events and dynamic vi's is that you can
work with them at un time, in stead of edit time, hence the term dynamic. As
a side note, in a dynamic VI system, dynamic events are very practical to
use, mostly for intercommunication with user events.

If you'd ask me, VI server is one of the most important things to master, if
you want to become an LabVIEW expert. Right next to state machine, type
defs, and a few others...

Regards,

Wiebe.


Message 6 of 6
(3,653 Views)