LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does an ActiveX call tie up LabVIEW 6.0?

I have a vi that opens a class in an ActiveX executable, calls a method, and then closes the class reference. While the ActiveX method is running (it takes about 30 seconds to complete), no other LabVIEW vi will run. This pertains to not only the original vi (which called the "Invoke Node", but also to any other vi's that I start independently.
When LabVIEW does an ActiveX call, do I have to wait for that call to finish before the code will proceed?
0 Kudos
Message 1 of 6
(2,593 Views)
This doc may be useful ... 'Why Do Applications Appear to Hang When Trying to Run a VI Using LabVIEW's ActiveX Automation Server?' (http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/30da650d55340f7886256a2a004e9d0a?OpenDocument)
0 Kudos
Message 2 of 6
(2,593 Views)
> I have a vi that opens a class in an ActiveX executable, calls a
> method, and then closes the class reference. While the ActiveX method
> is running (it takes about 30 seconds to complete), no other LabVIEW
> vi will run. This pertains to not only the original vi (which called
> the "Invoke Node", but also to any other vi's that I start
> independently.
> When LabVIEW does an ActiveX call, do I have to wait for that call to
> finish before the code will proceed?

This probably has to do with threading. The ActiveX call is being
made from the standard diagram execution thread. The ActiveX Server
is probably messaging the LV UI thread and tying it up as well.

This sort of thread swapping is very very common with ActiveX. ActiveX
makes is easy to pret
end threads aren't an issue, but ultimately, they
make everything complicated underneath.

To resolve this, you should probably wrap your Calls to the ActiveX
server into another subVI. Mark the subVI to execute in another
execution system like Other 1. This will isolate it somewhat from
the rest of the LV EXE leaving the Standard execution thread to do
diagram execution.

Unfortunately, if the ActiveX Server does execute in the UI thread,
this will still interrupt the UI a bit. Hopefully this isolation
will only tie up the Other 1 thread.

If you do have the source to the automation server, you might look
into making it be what is called an MTA server rather than STA.

Greg McKaskle
Message 3 of 6
(2,593 Views)
This subVI wrapper worked for me. However, my ActiveX server was already an MTA (multithreaded apartment) and that didn't solve the problem. It appears that all the code in a VI runs in the one thread and that to make your VI multithreaded you have to use subVIs (as suggested) which noticably hinders performance. The discussion of multithreading in the labview documentation almost suggests that multithreading does occur automatically in a single VI without subVIs (And maybe it does). It's unfortunate that there isn't a discussion of exactly what and how separate threads are trigger to be created.
0 Kudos
Message 4 of 6
(2,593 Views)
> This subVI wrapper worked for me. However, my ActiveX server was
> already an MTA (multithreaded apartment) and that didn't solve the
> problem. It appears that all the code in a VI runs in the one thread
> and that to make your VI multithreaded you have to use subVIs (as
> suggested) which noticably hinders performance. The discussion of
> multithreading in the labview documentation almost suggests that
> multithreading does occur automatically in a single VI without subVIs
> (And maybe it does). It's unfortunate that there isn't a discussion
> of exactly what and how separate threads are trigger to be created.

I'm not sure if I understand the first statement. An MTA server is
part of the solution since it will allow itself to be called from
multiple threads, but that doesn't affect the client -- LV code.

Similarly, you can have as many client threads as you like, but if
the server is STA, it will not matter. Each call will go back to
a single thread and things that access the server will serialize.

So, both things are necessary, the client needs more than one thread
and the server needs to be MTA.

By default, on a single processor computer, a VI diagram runs in one
thread, the thread belonging to the standard execution system, and
the UI runs in the UI thread. Additionally, all of the code that
LV generates will multi-task cooperatively using the standard and
UI execution systems.

You can make sure that the ActiveX calls run in a different execution
system by wrapping them in a subVI. Yes, a subVI does add a small
amount of overhead, but assuming the subVI panel isn't open, the amount
is quite small, especially when compared to the overhead that COM and
data conversions can add. Of course if you are going to make millions
of calls to the subVI, this will add up, and it is usually quite easy to
move some of the looping code down into the subVI call as well to reduce
the number of subVI calls drastically.

There is a second technique for making additional threads available,
it involves changing the .ini file to make an execution system have
additional threads. A dual processor machine automatically allocates
two threads instead of one. You can set this to any amount you like,
but it is pretty rare that this is needed.

One last piece of info. The goal of the LV execution system is to avoid
allocating lots of OS threads. It takes quite a bit of time for the OS
to allocate or destroy a thread. Similarly, it takes quite a bit of time
for the OS to stop one thread, swap in another, and swap back, so LV tries
to avoid this as well. LV does lots of multi-tasking, it always has, even
on single threaded OSes. LV tries to balance efficient operation with
parallel execution, and it allows for several ways of controlling this.

If you have other questions, fire away.

Greg McKaskle
0 Kudos
Message 5 of 6
(2,593 Views)
Thanks Greg. I mistakenly thought that you were suggesting a MTA as an alternative to a subVI that runs in a different thread. Your point is well taken. Both are necessary.

I'm relatively new both Labview and ActiveX. Your discussion was very helpful in getting a better grasp of the subject.
0 Kudos
Message 6 of 6
(2,593 Views)