回复： VI calling from a multi-thread Teststand

[StevenHuang]

Hello,

My test system tests four UUTs at the same time(with batch mode in TS), the code is based on LabVIEW and call from TS, so every step the same VI will be accessed by four thread. however, it runs quite slow even i set the reentrant execution in VI propertise.

My Quesition:

Can I do it like this in multi-thread mode of TS?

How can I make it fast? (convert VI to dll?????)

Any help will be appreciated.

Thanks,Steven

[AllenP]

Steven,

This KB might help you.  Let me know if it doesn't.

Allen P.
NI

[StevenHuang]

Hello Allen,

Thanks for your help.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

Problem: I have a LabVIEW VI with parallel code blocks. These blocks run in parallel as expected when I run my VI directly or from a top level VI. However, the code blocks seem to run sequentially when I call my VI from TestStand. Why is this happening and how can I fix it?

Solution: In order to fix this behavior, simply set the VI Properties of "Execution" of your LabVIEW VI to "Other 1" or "Other 2". This change will make the parallel code blocks in your LabVIEW VI run in parallel as expected. To change this setting, from your LabVIEW VI, go to File»VI Properties. Select the Execution category. Change the Preferred Execution System to be either other 1 or other 2.

You need to make this change to any LabVIEW VI with parallel code blocks that is called from TestStand. The reason for this is that TestStand is using the LabVIEW ActiveX interface to run LabVIEW VIs. The LabVIEW ActiveX interface sets the caller's execution system to "User Interface" by default. This execution system is not recommended for a VI with parallel code blocks. If your LabVIEW VI's execution system is set to "Same as caller" (which is the default setting when creating a new LabVIEW VI), then it is executed in the User Interface thread when run through the LabVIEW ActiveX interface. This prevents the blocks to be executed in parallel.

-----------------------------------------------------------------------------------------------------------------------------------------------------------

In fact, only one block in my LabVIEW code, but it accessed by four thread from TS. I am sure that my VI can be accessed by four thread simultaneously if I enable the reentrant excution in VI property. I also have tried what mentioned in above document but no use.

However, if i only add a 1000ms delay to my LabView code instead of the 'calculation', it is fast enough!  what is happening or something i set wrong?

I don't want to convert all my LabView code to DLL cos too many VIs here, and difficult for mantenance either.

Any other good solution???

Thank you Allen...

Steven

[AllenP]

If the top-level VI is reentrant but the subVIs inside of it are not, you will likely have all 4 threads waiting for that subVI.  Without seeing your VI, that is the most likely what is causing the behavior.  Converting to a DLL won't really help you in that case either.  I wouldn't recommend changing any VIs that are not your own to being reentrant, as they may not work properly if run that way.

Allen P.
NI

[StevenHuang]

--------------------------------------------------------------------------------------------------------------------------------------------------------

If the top-level VI is reentrant but the subVIs inside of it are not, you will likely have all 4 threads waiting for that subVI.  Without seeing your VI, that is the most likely what is causing the behavior.  Converting to a DLL won't really help you in that case either.  I wouldn't recommend changing any VIs that are not your own to being reentrant, as they may not work properly if run that way.

Allen P.
NI
--------------------------------------------------------------------------------------------------------------------------------------------------------

Hello Allen,

You are right, is that LabVIEW function are not my own code which can't set as reentrant?

Did you mean that TS call LabVIEW run in batch model is not a better choice? 

I have attached a simple example, please help to clarify.

Any other way to fix my problem???

Thank you again, Steven

[AllenP]

As far as I can tell, the primative nodes you are using are not reentrant, so they are blocking each other from running.  This appears to be a limitation of those nodes.

Allen P.
NI

[AllenP]

I looked at it closer, and it looks like it is actually running reentrantly in the nodes.  However, the processor can only call the nodes so quickly.  I set up an experiment in LabVIEW where I was able to run the VIs in a varying number of parallel executions.  I have a dual-core machine.  I tried to call as the random number generator as many times as I could in 1 second in a different number of threads.  In 1 thread, I was able to get about 2.3 million calls in .2 seconds.  If I run 2 threads, I get about 4.6 million calls in .2 seconds.  However, if I increase the threads higher and higher, I still can only get 4.6 million calls per .2 seconds.  This seems consistent with running in parallel.  Once your processor becomes the bottleneck, new threads aren't going to make it execute any faster.

Allen P.
NI

[StevenHuang]

My machine is fast enough if you ask me! (P4 daul-core and 1GB memory)

In labVIEW a lot of functions are made by LabVIEW itsself and they are unable to run reentrant cos the reentrant property are not set. like(test stand functions, express VIs etc...), some VIs that the top level is reentrant but the subVIs are not, like: signal prossing VIs.

I updated the example, so you can exactly see the speed slow down which caused by LabVIEW's function. I can do nothing here!

In my program almost 1000 steps, in sequential mode runs about 60 seconds, but it runs 130 seconds with 4 threads in batch mode.

Quesition: if i convert all the execution VIs to DLL, is it possible to get rid of this situation? is it possible that run 4 threads in batch mode within 80 seconds???

Thanks, Steven

[AllenP]

Steven,

Even with your system, there will be a maximum amount of work that your processor can do.  It sounds like you have reached that limit.  Converting to a DLL won't help much.  You may get a bit of a performance increase if you switch to using the LabVIEW Runtime Engine rather than the LabVIEW Development System.  You can try switching your Adapter options to see how much performance improves, but I'd recommend developing with the LabVIEW Development System until you are ready to deploy.

Allen P.
NI

[StevenHuang]

Allen, Thank you very much.

Yeah, Coverting to DLL not help yet......

It runs about 120 seconds after switch to LabVIEW Runtime Engine, a little bit improvement.

Would you please tell me how is TS working with LabVIEW internally when VI property set as reentrant execution?

Thanks, Steven