LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multitasking VIs

The best I can tell, LabView will NOT multitask. I have a VI that goes into
a DLL for than a minute. During that time, any other VI running seems to
freeze until the other VI returns from the DLL. Is this true?

Bruce Kingsley
brucek@wolfenet.com
0 Kudos
Message 1 of 3
(3,447 Views)
I had the same situation when using only 1 data acquisition bd. When I went
to multiple boards, I could then multitask as long as each vi was using a
different bd. My end result for my system uses 2 acquisition bds, a GPIB
card, and a digital I/O bd.
It is a lot of equipment but I can do some complex testing with this layout.
-Shannon King, Mfg. Engineer
sking@itis.com


Bruce Kingsley wrote in message
news:387d5b27@newsgroups.ni.com...
> The best I can tell, LabView will NOT multitask. I have a VI that goes
into
> a DLL for than a minute. During that time, any other VI running seems to
> freeze until the other VI returns from the DLL. Is this true?
>
> Bruce Kingsley
> brucek@wolfenet.com
>
>
>
0 Kudos
Message 2 of 3
(3,447 Views)
> The best I can tell, LabView will NOT multitask. I have a VI that goes into
> a DLL for than a minute. During that time, any other VI running seems to
> freeze until the other VI returns from the DLL. Is this true?
>

This is a complicated subject. LV compiles VI diagrams into
multiple pieces we call clumps, that allow for execution to
switch back and forth between clumps. These clumps are as
small as one node, and as large as a whole diagram. DLLs
calls are always a part of a clump, and cannot be broken into
multiple clumps because they are already compiled, and LV can
just call into them.

On single threaded systems, LV has one thread, and it takes
turns calling into the clumps. The thread executes a clump
until it is finished or until the clump releases control.
Since LV compiles the clumps it is able to make them check
a clock and return when enough time has elapsed. A DLL
doesn't know anything about that, and always runs to
completion.

So, is LV ever able to multitask? Sure. In a single-threaded
system it multitasks whenever the generated code allows. In
a multi-threaded system, it can multitask in the same way, plus
it multitasks between different threads whenever the OS decides
to.

The default configuration of LV uses one thread to execute the
user interface, and one thread per processor for each priority
for each execution system. When you have a typical computer and
VI, that typically means one additional thread. This means the
user interface is independent of the diagram, and the diagram
runs pretty much the way it did in previous LV versions on a
single CPU computer. You can add additional threads for multi-
tasking by -- adding another CPU, moving some VIs to another
priority, moving some VIs to another execution system, or
adding additional threads to the execution systems that you are
already using.

Adding the additional CPU obviously throws some CPU muscle at
the problem and can carry out a parallel task as long as the
VI has parallelism. In the simple example above, it allows
the UI and standard thread to each live on a processor.

You can change the execution system or priority in the VI
setup dialog. At the lower left of the dialog are rings for
changing these settings.

To change the threads per execution system and priority, you
can use the VI in vi.lib/utility/sysinfo.llb/thread???
I don't remember the exact name, but anyway it will let you
add more threads to any of the combination of priority and
execution system.

So if you have a DLL in a VI, and that DLL will take alot of
time to finish, then additional threads will allow for more
multitasking, but even the original case will keep the UI
pretty alive while the DLL completes.

Greg McKaskle
0 Kudos
Message 3 of 3
(3,447 Views)