Running parallel ActiveX methods

[rsouky]

I am trying to upload a .hex file in parallel in different chips using different programmers.

I am using an ActiveX method of the programmer's maker. Even though, I configured the .vi to be a preallocated reentrant .vi, when I run the code in parallel, LabVIEW crashes a few seconds after the execution of the methods starts. I don't have this problem with methods that require less time to execute.

So, I created an executable and made copies of it. Now I can upload the .hex files in parallel in different chips using different programmers.

I dislike very much this solution. Do you have any idea why this is happening? And do you know a way to perform this same operation with a .vi called multiple times?

I do not know if its a memory issue or some kind of entity is juggling its time between the calls when I run the vi.

[rolfk · Accepted solution]

Most likely a bug in the ActiveX component. ActiveX knows different threading modes.

- Single threaded

- Apartement threaded

- Multithreading

The first means that the component can only be called from the main thread that initialized the ActiveX COM environment.

The second one is a bit special as it means that a process should always call a particular object from the same thread in which it was created. It is in principle single threaded too, but doesn't have the restriction that the component can only be called from the main thread in a process.

The third one is very rare in the wild as most ActiveX components are NOT written to work in multithreading mode.

For LabVIEW Single threaded and Apartement threaded are treated the same in that LabVIEW calls them from the only thread it can guarantee to serialize any calls to the ActiveX component, which is the UI thread. Either your ActiveX component claims to be multithreading and isn't really that way or it can not deal with the special consideration of being called multiple times from the message handling thread (root loop) in LabVIEW, which happens to be the UI thread too.

Whatever of these reasons it is, there is really nothing you can tell LabVIEW to somehow treat the ActiveX component differently than what the registration information for that component tells an application to invoke it like. So your solution to create different processes (application) for each instance is the workaround to use, unless you want to dive into C(++) programming and create a wrapper interface to the ActiveX component that handles the specific threading requirements for your component explicitly (which unless you are a very seasoned C++ programmer with detailed ActiveX knowledge is more likely to be an exercise of frustration than anything else).

[rsouky]

I was hoping there was a workaround in LabVIEW.

I actually read a bit about the different threading modes of the ActiveX components and considered it a possibility why the operations were unsuccessful. I wasn't sure anyways.

Thank you Rolf. I learned a few things.