"To .NET Object" and ".NET Object To Variant" VIs seem to block execution for other calls of either VI?

[uknoblich]

I am trying to run two parallel while loops that each communicate with another process via COM/.NET.

Everything seems to run fine and in parallel, but the "To .NET Object" and ".NET Object To Variant" VIs seem to block execution for other calls of either VI, making this attempt fail.

Why do these VIs block execution? Is there another way to do get data in and out of .NET calls that does not block and is thus parallelizable?

Thanks,

Ulf

[DylanC]

Hi uknoblich,

If you open up the VI and go to File>>VI Properties then under the Execution you can see that this VI is non-reentrant. I would suggest using these VI's outside of your parallel loops (if possible) and then sending the object and variant to those loops. I will need to look into why they are not reentrant.

DylanC

[uknoblich]

Thank you for your reply!

I suspected something like them being non-reentrant, but I forgot I could see that in the VI properties. I tried to look at the block diagrams bu they are locked, so I'm not sure why they would be.

I've done what you suggested with the inputs that don't change, but there are some inputs and outputs that can change between loop iterations, so that doesn't work for them. Another thing I noticed was that not only do these VIs seem to block execution of the same VI, but also the other one, e.g. the NET Object to Variant seemed to block a call to To Net Object? I hope you'll figure out why they are not re-entrant and we can find a way to fix this or at least work around it.

Ulf

[DylanC]

Hi uknoblich,

I believe both of those VI's call into the same dll which is not threadsafe which is why they block each others execution. Whichever the case, it is not something readily changeable. As to a workaround, how many of these VI's do you have that you wish to run in parallel? The VI's are not very intensive and process rather quickly, how much of a delay do you seem to be getting due to them running sequentially?

The best bet would be to move these VI's out of your main parallel loops and have them run on there own. You can do this by using a Producer/Consumer or Master/Slave type architecture where you can convert your object's to variants and To .NET Object's in a consumer loop that doesn't affect the timing of you "Producer" or "Master" loop. The basic structure is found by going, in LabVIEW, to File>>New...>>VI>>From Template>>Frameworks>>Design Patterns>>Master/Slave Design Pattern

DylanC

[uknoblich]

Hi DylanC,

thanks again for your help.

I'm using these to connect to Matlab because I wanted to connect to multiple independent Matlab processes, for the exact reason to implement a producer/consumer architecture. I'm using a Matlab toolbox to get data streamed over TCP/IP, and want to use another Matlab process to analyze that data (using other Matlab toolboxes, so it's not easy to write it in Labview instead). Matlab is pretty painful to code this explicit parallelization in (or maybe I just haven't understood their concept yet), so I wanted to use Labview with its natural parallel processing capabilities as another option (and do a few other things, as well).

Unfortunately the Matlab script node calls Matlab as a shared server (all matlab script nodes interact with the same matlab process and block exection of other matlab nodes). Because of peculiarities of the Matlab COM implementation it seems I cannot use the Labview COM VIs (I couldn't figure out how to open a COM object based on it's ProgID), but found the workaround using .NET based on posts here and in the Matlab forums. After all this, I can connect to multiple independent matlab processes, but when I move data around (potentially several tens or hundreds of MB in a 2D array), now the NET Object<->Variant VIs block execution. I don't remember the exact numbers, but while playing with two parallel loops I've seen execution times of these VIs of several hundred milliseconds for the sizes of arrays I might encounter, several times slower than the execution of the call to Matlab, which presumably transfers the same amount of data (albeit in a different format).

At this point I'm trying to re-evaluate how much of those large chunks of data I really need in Labview. Since the majr parts of the analysis will be done in Matlab, maybe there's a way to make the Matlab processes talk to each other directly. Or if I can find a way to only need smaller pieces of data in Labview itself, I could just pass the NET object from one matlab to the other without converting it to a variant in between, and only convert smaller amounts of data to variants, which should be fast enough.

Ulf

[smercurio_fc]

For reference, this is the thread that generated this secondary issue: http://forums.ni.com/t5/LabVIEW/Connecting-to-multiple-Matlab-instances/m-p/2042380