Multi-Tasking

[Bruce Kingsley]

I have a VI that calls a MFC/C++ Dynamic Link Library (DLL) that performs a
time critical function and doesn't return for many minutes. The problem is
while Labview is in my DLL function, no other Labview form will operate. You
can't even move Labview windows. I thought Labview used a different thread
for GUI.

Is there a way to allow an other Labview window to continue to operate
while the other DLL VI window is busy doing its thing?

--


Regards;

Bruce Kingsley

[Ben]

If you know the .DLL is thread-safe, you can configure it to run in a thread other that the UI thread.

If your cin is orange it will run in the user interface thread. This is the default if I remeber correctly. LV defaults to the UI thread just to play thing safe.

If you can ensure the same dll is not going to be called elsewhere by something else, you may get away with setting a non-thread safe dll to run in another thread but nobody can predict if it will work or not.

You should ensure that it is not the CPU that is locked-up because changing threads will not with that situation. Can you do other non-LV related taks while the is going on?

Ben

[Bruce Kingsley]

Other Labview windows will try to call the same DLL, just not the same
function in the DLL.

The computer is not locked-up, just other Labview forms. In fact, other
windows applications, that use the same DLL, continue to operate normally.
It's like Labview can only do one thing at a time. I tried put this Labview
form in another execution system, like "Other 1", but other Labview windows
still lock-up.

--


Regards;

Bruce Kingsley


"Ben" wrote in message
news:5065000000050000008F9A0000-1027480788000@exchange.ni.com...
> If you know the .DLL is thread-safe, you can configure it to run in a
> thread other that the UI thread.
>
> If your cin is orange it will run in the user interface thread. This
> is the default if I remeber correctly.
LV defaults to the UI thread
> just to play thing safe.
>
> If you can ensure the same dll is not going to be called elsewhere by
> something else, you may get away with setting a non-thread safe dll to
> run in another thread but nobody can predict if it will work or not.
>
> You should ensure that it is not the CPU that is locked-up because
> changing threads will not with that situation. Can you do other non-LV
> related taks while the is going on?
>
> Ben

[Rolf]

"Bruce Kingsley" wrote in message
news:akhgbd$829$1@slb3.atl.mindspring.net...
> Other Labview windows will try to call the same DLL, just not the same
> function in the DLL.

Then it may be a problem or not! It all depends on the programmer of the
DLL. If the
function you call does not share any resources such as devices, global
variables, or files
with any of the other functions or the OS itself, it should be save to call
it in a different
thread. If it uses shared resources which are properly protected with
semaphores or
critical sections it should be save too.

Otherwise setting the Call Libary Node to a different thread than UI will
most likely
result in crashes or data corruption after some time. It does not need to be
fa
tal
immediately but can suddenly fail after several seconds, minutes, hours,
months or
years of execution 😉

> The computer is not locked-up, just other Labview forms. In fact, other
> windows applications, that use the same DLL, continue to operate normally.
> It's like Labview can only do one thing at a time. I tried put this
Labview
> form in another execution system, like "Other 1", but other Labview
windows
> still lock-up.

You did something wrong! The Call Library Node has it's own setting which
for
safety reasons by default is set to UI Thread no matter in which thread the
VI
itself is running. Configure the Call Library Node to be reentrant and it
will execute
in whatever thread the VI itself is executing.

By the way in LabVIEW you use VIs (Virtual Instruments) and not forms 😉

Rolf

[Bruce Kingsley]

The DLL is properly designed to be called by many different applications, at
the same time, without conflict. Only Labview is halting execution of its
other forms while in the DLL.

--


Regards;

Bruce Kingsley




"Rolf" wrote in message
news:akidi4$jiq$1@reader12.wxs.nl...
>
> "Bruce Kingsley" wrote in message
> news:akhgbd$829$1@slb3.atl.mindspring.net...
> > Other Labview windows will try to call the same DLL, just not the same
> > function in the DLL.
>
> Then it may be a problem or not! It all depends on the programmer of the
> DLL. If the
> function you call does not share any resources such as devices, global
> variables, or files
> with any of the other functions or the OS
itself, it should be save to
call
> it in a different
> thread. If it uses shared resources which are properly protected with
> semaphores or
> critical sections it should be save too.
>
> Otherwise setting the Call Libary Node to a different thread than UI will
> most likely
> result in crashes or data corruption after some time. It does not need to
be
> fatal
> immediately but can suddenly fail after several seconds, minutes, hours,
> months or
> years of execution 😉
>
> > The computer is not locked-up, just other Labview forms. In fact, other
> > windows applications, that use the same DLL, continue to operate
normally.
> > It's like Labview can only do one thing at a time. I tried put this
> Labview
> > form in another execution system, like "Other 1", but other Labview
> windows
> > still lock-up.
>
> You did something wrong! The Call Library Node has it's own setting which
> for
> safety reasons by default is set to UI Thread no matter in which thread
the
> VI
> itself is runn
ing. Configure the Call Library Node to be reentrant and it
> will execute
> in whatever thread the VI itself is executing.
>
> By the way in LabVIEW you use VIs (Virtual Instruments) and not forms 😉
>
> Rolf
>
>

[Greg_McKaskle2]

> The DLL is properly designed to be called by many different applications, at
> the same time, without conflict. Only Labview is halting execution of its
> other forms while in the DLL.
>


The original suggestion is right on the money. Since LV is a
multithreaded environment, it defaults to only call imported DLLs in the
UI thread. The DLL node will transition to the UI thread since that
protects DLLs that are not protected or reentrant. Such Call Library
nodes will appear to have an orange header. Double click the node and
in the configuration inform LV that the node is reentrant. LV will now
call this DLL in whatever thread is running the diagram -- standard
should work fine, but other1 will work if that is w
hat you like.

One other thing to make sure of is to go to the LV Tools Options dialog.
go to the diagram execution page and make sure that multithreading is
enabled. LV can run with only one execution thread, and this would also
cause the problem symptom.

Greg McKaskle

[Ben]

Hi Guys,

Bruce, check the point made by Rolf and Greg. Either the dll call configuration or the LV option should fix the problem you are seeing.

Rolf, Greg, Thank you for teaching me this stuff in the first palce.

Ben