Calling Multiple (and parallel) ActiveX instances

[Nadav_Chernin]

I'm having a problem of running multiple activeX instances using LabVIEW (apparently the problem occurs with more than 4 instances). This problem doesn't happen when I do the same thing in C (Visual Studio). I can create as many instances as I wish, but when I run methods that hang or run for a long period of time, only 4 are able to run at each moment. If I stop any one of the methods, the next one starts running.

I attached an example (in LabVIEW 8.5.1) of using the excel activeX automation, but it happens with all of the activeX's I tried so far. It even happens when using several different activeXs.

Please notice, that the problem is not with creating the instances, but when running methods of the activeX in parallel at the same time (If you run short methods that finish executing fast, you won't notice the problem).

[Sappster]

Hi Nadav,

The problem with the VI you provided is not the activex instances, it is the number of open file dialog. if you run the same example without calling the open file dialog, you will have 6 open excel instances. I'm not sure how you did it in c but did you have 6 open file dialogs?

[Jarrod_S.]

I think you're running into the max number of threads LabVIEW allocates per execution system (4 by default). All of this code is running in one VI and hence one execution system. You can do a quick test to confirm this. Select one or more of your parallel instances and create separate subVIs from them. Then go into those subVI properties and go to the Execution category. Select various execution systems for the VIs. Make one DAQ, for instance, another Instrument I/O, and another Other 1 or whatever. When you rerun your test after that you'll see all six File IO dialogs pop up simultaneously.

Even though LabVIEW is using only four threads in each execution system, it will still multitask between various things to achieve as much parallelism as possible. This is what you saw when you said that as soon as one method finished, another one would start up.

I'm not too familiar with dealing with execution systems to achieve highly scalable applications, unfortunately. Most of the time LabVIEW gives you something really good out of the box without having to think about execution systems. And when you run applications on Timed Loops, that helps LabVIEW divide up application threads better as well.

But you could start by seeing if you can divide up your ActiveX routines somehow and then duplicate the code into subVIs that run in different execution systems.

Another option is to manipulate the TreadConfig VI that ships with LabVIEW. Check out the following VI:
<LabVIEW>\vi.lib\Utility\sysinfo.llb\threadconfig.vi

You can increase the number of threads LabVIEW will allocate for each execution system to up to 8.

Here's a help topic with more info.

Message Edited by Jarrod S. on 05-12-2008 09:30 PM

[amiramke]

Thanks Jarrod.

That helped us a lot (I work with Nadav on this problem). We saw that using threadconfig.vi created the following in the labview.ini file:

ESys.Normal=100
ESys.instrument.Normal=100
ESys.DAQ.Normal=100
ESys.other1.Normal=100
ESys.other2.Normal=100
ESys.StdNParallel=-1

(The 100 was put there by us. The original was 4).

Now, this seems to work when we use LabVIEW (we can run a 100 different threads. It doesn't seem to be limited to 8), but when we created an executable file (and of course did the same changes to the exe ini file), the default went back to 4 threads.

Does anyone know how to do the same in the executable?

Thanks for the help,

Ami

P.S.

Mark, the example you provided works only because you used an asynchronous function (It runs in the background). The file dialog actually waits for the user to respond and therefore hangs the thread (that's why we gave it as an example).

[Jarrod_S.]

When you create or run a LV-built executable, it always creates an ini file next to the exe with the same name. This is where application settings such as the Web Server, VI Server access, and so on are stored. Try putting those same ini tokens into that file next to your executable and see if you get the desired response.

[amiramke]

Hi Jarrod,

We did that. It doesn't work. I need to know if there is anything else that needs to be done in order for it to work using the exe file.

Ami

[Matthew_Kelton]

What does your INI file look like?

If your EXE is named MyProg.exe, then in the same directory you should have a MyProg.ini.

In MyProg.ini, you need a section named [MyProg].  In that section, you need ot put all of the custom LabVIEW INI settings.

[amiramke]

That's exactly what we did. That's why I'm asking if anything else needs to be done in this case.

[amiramke]

Hi guys.

I switched to a different PC, tried everything again and it works even with the executable.

Thanks again,

Ami