Labview locks event processing in external library (DLL) :-(

[anpis]

Hi all!

I have to test some Bluetooth functionality for devices on production line.

I use Bluesoleil Bluetooth C++ SDK to make small DLL to support several simple Bluetooth operations.

This DLL registers several event callbacks on BT HW, call function for Bluetooth device discovery and waits an result.

This operation driver executes asynchronously and to wait end the process DLL creates Windows event and activates it when appropriate driver's callback is called.

DLL uses Windows API function WaitForSingleObject with timeout to catch end the process.

After this process is finished I check gathered information about devices in environment.

It normally works when I call these DLL functions from C code.

Then I repeat the test functionality in Labview's VI where I use DLL wrapper to call DLL functions..

And the most functions works correctly inside of Labview too..

But I can see: event's callbacks in DLL under LABVIEW are processed in wrong time slot:

a) When I use C-code caller then DLL's callbacks gather information about devices in background

And when this process is finished counter of devices is not zero an I have a list of devices.

b) When I use Labview DLL caller then the discovery process is ended by timeout. I latch zero BT device counter.

And only after return from DLL call I can view in logs result of callback processing - incremented counter and gathered BT device properties.

But this information is already missed for me.

Is it possibly Labview organizes own event queue and processes it?

And is it possible event hooks in DLL are processed after return from DLL function call?

There are some way to configure this behavior in LABVIEW?

Thanks in advance for any ideas.

Anatoly

[anpis]

Hi all!

I have to test some Bluetooth functionality for devices on production line.

I use Bluesoleil Bluetooth C++ SDK to make small DLL to support several simple Bluetooth operations.

This DLL registers several event callbacks on BT HW, call function for Bluetooth device discovery and waits an result.

This operation driver executes asynchronously and to wait end the process DLL creates Windows event and activates it when appropriate driver's callback is called.

DLL uses Windows API function WaitForSingleObject with timeout to catch end the process.

After this process is finished I check gathered information about devices in environment.

It normally works when I call these DLL functions from C code.

Then I repeat the test functionality in Labview's VI where I use DLL wrapper to call DLL functions..

And the most functions works correctly inside of Labview too..

But I can see: event's callbacks in DLL under LABVIEW are processed in wrong time slot:

a) When I use C-code caller then DLL's callbacks gather information about devices in background

And when this process is finished counter of devices is not zero an I have a list of devices.

b) When I use Labview DLL caller then the discovery process is ended by timeout. I latch zero BT device counter.

And only after return from DLL call I can view in logs result of callback processing - incremented counter and gathered BT device properties.

But this information is already missed for me.

Is it possibly Labview organizes own event queue and processes it?

And is it possible event hooks in DLL are processed after return from DLL function call?

There are some way to configure this behavior in LABVIEW?

Thanks in advance for any ideas.

Anatoly

[LindyHop]

Hello anpis, 

For clarification would it be possible to post the smallest portion of your code that reproduces your error? 

[anpis]

Hello, Jonathan-L

Here I attach small fragment of DLL c-code which contains functions for searching for BT devices in environment.

This code defines couple of callback functions which are registered for BT driver and inform about each found device in environment and about search completing.

Searching starts in UpdateDeviceList() function, which creates Windows event handle to inform about search is completed.

And then Btsdk_StartDeviceDiscovery(...) function is called which has argument (last) to limit searching time.

Windows API function WaitForSingleObject(...) is used to wait searching is finished.

Originally it has infinite time for waiting.

When I use C-code maked caller for DLL then during this process regularly callback events are raised for each found device and work is normally finished after callback function AppInqCompInd() establishes the waited event.

Under Labview the behavior is different.

No callback events are processed during WaitForSingleObject() function and waiting is stated infinite.

When I limit waiting with some timeout and attach debugger to DLL code then I see as my breakpoints in callback functions are passed just after I go out from DLL or call by chain another function in DLL which starts another asynchronous process (for example EnumerateDevices() ).

I think Labview locks event processing because it installs some its queue for events. And event dispatching possible only after return in Labview from DLL code.

Now I trying to solve the problem with replace WaitForSingleObject() function in DLL code with limited cycle with dummy call SDK function EnumerateDevices() to push event queue. Seems it really works.

Another way - to move all low level event processing from DLL code  to Labview. But It is not good way.

There are no another ways on my horizon.

Anatoly

[LindyHop]

"Now I trying to solve the problem with replace WaitForSingleObject() function in DLL code with limited cycle with dummy call SDK function EnumerateDevices() to push event queue. Seems it really works."

Wait, so you got it working?

[anpis · Accepted solution]

Yes, I have tested this solution and have got it working. 🙂

I see the reason is Labview establishes its own queue for events such way that callback events are not processed inside DLL code  and are pending return to Labview.

And when I call inside of DLL another function which runs another asynchronous process (enumeration) this some way activates queue processing in application.

It is strange and not obvious situation.

I only suddenly discover this possibility during debugging.

I don't see another solutions and cancel this topic.

Best regards

Anatoly