Does calling by asynchronous call improve performance?

[beavercreek]

I'm hoping someone can shed light onto my situation.

Background -- 3 layers of vi's:

Regression Tester VI - inside a for loop the Wrapper VI is called 86 times

Wrapper VI - inside is a case structure which calls one of 50 different tests

Test VI's - All use the same reentrant VI's (JTAG Client and JTAG Agent)

Old Way - the Wrapper VI is inside the Regression Tester VI as a wired subVI

New Way - the Wrapper VI is called asynchronously by the Regression Tester VI (and immediately a Wait on Asynchronous Call)

In the past, we've had very inconsistent results out of the Regression Tester VI, for example:

Old way -- 56 out of 86 tests had failed (various ways, varied error messages)  the last test to pass was run number 60 (numerous had already failed before that)

New way -- 4 legitimate failures and 82 tests passed

Friday was the first time I ran it with the New Way (asynchronous calls).  I ran it again because I could not believe the difference!   ~8 hours later, same results, 4 legitimate failures and 82 tests passed.

I suspect some of the issues are from the reentrancy of the two main subVI's :The JTAG Client VI launches a JTAG Agent VI (if it needs to be launched).   The Agent VI is launched and closed with each of the 86 times the Wrapper is called.  The agent and client execution types are set to Preallocated clone reentrant execution.    This is because inside many of the Test VI's the Client is called many times inside while or for loops while communicating with two different Microcontrollers simultaneously.

My other suspicion would be the drivers for the JTAG adaptor misbehaving (or openocd.exe), but to me there is no difference between the wrapper called as a subvi or called asynchronously.  In both cases the agent must launch (and utilize the JTAG adaptor drivers) and then the wrapper terminates all communication (and openocd.exe) and there is a 10 second pause before the wrapper is called again.

Would the asynchronous call equate with a new memory allocation whereas repeat subvi calls might reuse the same areas?  some other way to explain why this change seems to make it run so much more reliably?

LabVIEW version 12.0.1.f5 (32-bit)

Windows 7 enterprise SP1 (64-bit)

[John_P1]

Are you opening the reference inside the loop?  If so, the behavior would be different (you'll actually get a new instance of the subVI each time you open the reference).  If you call the subVI in a for loop the memory between calls is shared (even if "Preallocate clone for each instance" is selected).  As an example:

my demo subVI:

Calling it asynchronously:

Calling it directly:

You likely have some sort of state in your subVI(s) that is affecting your reported test results.

Best Regards,

[rolfk]

Most likely that state is present in the underlaying DLL. By opening a new VI reference at each iteration (and closing it at the end) the VI is loaded and unloaded each time and that also allows the DLL to be unloaded and reloaded, initializing whatever internal states the DLL programmer has used.

Maybe there is an explicit Reset() function in the DLL that causes that reinitializtion as well, but it is just as likely that the DLL was programmed in such a way that for proper reinitialization it needs to be reloaded. This often happens with DLLs meant to communicate with hardware interfaces, since the programmer of the DLL is often not aware of more complex use cases of such DLLs within a bigger application and it is simply so much more convinient to add somewhere a global variable in the DLL holding all the necessary information, than implementing a function to open a local state structure that is then passed to all the other functions as a handle to operate on. Nobody will ever use more than one interface at the same time, so why bother with the extra complexity.

[beavercreek]

Thanks for the info guys!

@John_P1: I am indeed opening a new reference to the vi inside the for loop.  Thanks for drawing up those examples!  A good tip to remember when one wants a fresh set of 1's and 0's.