LabVIEW driver using dll stops working when VI is called asnychronously

[ngblume]

Hey everyone,

while this is strictly not a question limited to DQMH, I came across this problem when developing a DQMH module and was hoping for some inputs, since DQMh relies on Async Calls...

I have a LabVIEW driver, that in turns calls a DLL, that establishes a connection to a CAN network / net.

When I use VIs from this driver in a VI and run this VI directly, everything works fine.

As soon as the same exact VI is called asynchronously, the calls to the DLL do not seem to work anymore and DLL-stuff like windows handles are zero.

Example:

The "Register Client" works fine, when I start this VI directly.

When starting this VI asynchronously as follows, the Window handle out is for example zero and the "Connect to Net" VI reports an error, stating that the provided client (registered by the VI before) is invalid.

Any ideas anyone?

Cheers

Niels

[joerg.hampel]

Just a quick first thought (and to make sure we're on the right track):

In your screenshot, you're supplying the option 0x80 (Prepare to call and forget) to the Open VI Reference function. The help states:

"Use this option flag when you want to call a target VI asynchronously with the Start Asynchronous Call node but you do not need to know when or what the VI returns."

I guess in your real application, you're doing something different?

[drjdpowell]

Make sure the VI clone you are creating has an open front panel; otherwise there is no Window to get a Windows Handle on.

[ngblume]

Hello,

---

@drjdpowell wrote:

Make sure the VI clone you are creating has an open front panel; otherwise there is no Window to get a Windows Handle on.

---

I will check that, but I think you are on track to the cause of the problem.

It seems that the way the window handle is determined is not working when the VI is called asynchronously (it is derived from the call chain).

I got the VI from the developer and will check how it works when used in asynchronous calls.

@joerg.hampel wrote:

Just a quick first thought (and to make sure we're on the right track):

In your screenshot, you're supplying the option 0x80 (Prepare to call and forget) to the Open VI Reference function. The help states:

"Use this option flag when you want to call a target VI asynchronously with the Start Asynchronous Call node but you do not need to know when or what the VI returns."

I guess in your real application, you're doing something different?

---

actually no... the intent is that the async started VI runs completely detached (such as a DQMH after start modulem, right?).

I will only interact with the VI using the API (in case of DQMH), or the VI will complete its tasks on its own and terminate.

Thanks!

Cheers

Niels

[joerg.hampel]

Sorry Niels, I thought the second screenshot shows how you call the VI in the red circle in the first screenshot. Sometimes, I do miss the obvious things, and then I'm thankful if somebody points them out to me, just to make sure 🙂

I second James. Also, maybe changing the thread option of the Call Function Library Node from Run in UI thread to Run in any thread might help?

[ngblume · Accepted solution]

Hello,

for reference, the reason of the problems was / is an unhandled special case when using the call chain function to find the window name to than pass to the user32.dll-function "FindWindowA"; the special case being the async call.

Call Chain, if AsyncCall is involved:

The last entry in the array is used to find the most top-level VI.

In case of AsyncCall this becomes the proxy, which has no window resulting in the error described by @drjdpowell.

Slight rearrangement of the function as follows solves the issue:

Cheers

Niels