asychronous control

[jdendil]

Do DLLs face the same restrictions as CINs with regard to synchronous control?
When I use call member function, the VI that it's called from, and any other
VIs seem to stop. I don't know if this is due to a poorly coded DLL, or
that LabVIEW when calling a DLL behaves the same way as when it is using
a CIN.

If it is the latter, are there any ways to force LabVIEW to run asynchronously?
At least with respect to a different VI?

Thanks in advance.

[Greg_McKaskle2]

> Do DLLs face the same restrictions as CINs with regard to synchronous control?
> When I use call member function, the VI that it's called from, and any other
> VIs seem to stop. I don't know if this is due to a poorly coded DLL, or
> that LabVIEW when calling a DLL behaves the same way as when it is using
> a CIN.
>
> If it is the latter, are there any ways to force LabVIEW to run asynchronously?
> At least with respect to a different VI?

DLLs and CINs are both nodes to the LV diagram and follow all of the
rules that
nodes do. The calling diagram is finished until the node finishes, and
this is
the same as subVI calls, array transpose, or any other node. The biggest
difference is the way that most DLLs are implemented. They typically don't
process events or
rest/calls sleep. Most DLL and CIN calls just keep their
head down and run to completion. This means that they may not release control
as often as something written in LV.

Since LV5 though, they can run in parallel with other things in LV if threading
is enabled, and if something else is available to run on another thread
or at
another priority. If this is the case, then the DLL will be suspended
by the
OS, and the other task will run, then return to the DLL.

If you are lucky enough to have a dual processor (or more) machine, then the
DLL and other parallel tasks can run at the same time. Otherwise, they get
to take turns on the single processor.

So, if you want to force something to run in spite of the DLL that is executing,
then set it to a somewhat higher priority, and set it to go off on a
timer or
an occurrence. You can also set the VI that calls the DLL to be in another
execution system, like Other.

Greg McKaskle