Re : DAQmxbase blocking issue (mac os)

[Ageradi]

Dear All,

I am using the daqmx base framework on the latest versions of MAC OS X 10.8 and 10.7.

Driver is up to date on both systems. The application is developped in Obj-C / Obj-C++ using Xcode.

My issue is that the first time I call DAQmxBaseLoadTask(...) after the app is launched, the function takes ages to return (5 to 10 seconds, generally it's closer to 8-9 seconds). Of course during that time, the calling thread is blocked.

This is not an issue by itself. I am guessing that the frameworks is initiazing itself. The issue is that if I don't call DAQmxBaseLoadTask(...) on the main thread the first time, my app will never quit later, when the user decides it.

Subsequent calls to DAQmxBaseLoadTask(...) however, can be placed from any thread. So I guess, the framework needs to initialize itself, but on the main thread only.

As a side effect, blocking the main thread makes the app unresponsive. The graphic interface don't refresh, no user interaction is possible, and the user is strongly tempted to kill the app before the framework has finished initializing itself (10 seconds is a long time for some users). As a result of this abrupt termination in the middle of its initialization, the DAQmx framework may never be able to function properly until next reboot...

So, all this chain of events which eventually lead the user to reboot his/her computer and complain can be traced back to : DAQmxbase framework takes ages to init AND can only be initialized on the application's main thread.

My question is: How can I solve this issue ?

From what I could find:

- If the framework is not initialized on the main thread, all the above-described issues are solved. However, the application can't quit. It will hang on exit, until the system decides to kill it (or the framework bugs, I don't know). Between init and exit, the framework will work just fine.

- The first time DAQmxBaseLoadTask(...) is called, during its initialization, DAQmxbase framework spawns like 20 threads (no idea why).

- It seems that the reason preventing the app from exiting is that somewhere in the framework, one thread is waiting for the others to therminate, and that, for some reason, they don't (unless the framework was initialized on the main thread).

Do you have any idea on how I could solve these issues ?

Best regards.

[Mathieu_T]

Good afternoon Ageradi,

In order to help you, I would like to know further information :

   - Which version of DAQmx are you using ?

   - Which utility did you use for task settings ?

Thanks for your answer.

Regards

[NIthan]

Hello Ageradi,

This is known issue where calling a LabVIEW built framework from a cocoa app's secondary thread will cause the app to hang. If called from the main thread, the LabVIEW built framework will load but block the main thread while it's loading. This causes the main app to appear to hang the first time the framework is called (this looks like the behavior you are seeing). Since DAQmx Base is a LabVIEW built framework, it exhibits this issue.

Unfortunately, the only workaround right now would be to have a loading screen open while you call the DAQmxBaseLoadTask, so the user knows there is something loading and doesn't think the app has hung. This issue will most likely be fixed in the next release of DAQmx Base, currently scheduled for August 2013. Sorry for the inconvience, let us know if you have any additional questions.

Nathan Hickey

[Ageradi]

Hi,

Thank you very much for your reply. The behavior you are describing is indeed what I am experiencing. I am using this workaround while initializing the App (I try to load a dummy task).

Up until recently, We were only using DAQmxbase to drive a NI-USB 6501 device (we did drop the 6009 for an other vendor because of an issue in the driver making it unable to reliably control the analog output). The 6501 is working fine, but I tried the 6009 yesterday, and it is indeed blocking when called from a non-main thread.

Unfortunately, calling it from the main thread makes the app unusable. So  I am eagerly waiting the update to test it again.

In our current setup (where the 6501 is the only NI-device) the main issue is the one described in my previous message. Do you know why DAQmxBase does spawn so many threads ? They seem to remain dormant for the lifetime of the app. Can I safely kill them ?

[Ageradi]

Dear Mathieu_T,

Driver is up to date on both systems.

I used daqmxbase config utilityto create the tasks. However, if there is a way of setting them up programatically, I would love to do it that way.

Best Regards

[AdamKemp]

I just wanted to follow up on this issue because I am currently working on a potential fix. This is a bug in the LabVIEW runtime which is unique to OS X. The workaround described above does in fact sidestep the problem entirely. Note that for the workaround to be effective you can call any exported function from any LV-built framework in the main thread. It doesn't have the be a DAQmxBase Create Task function. You could just make another framework with an empty VI export and call that. In this case you would only get the overhead of loading the LabVIEW runtime engine instead of possibly extra overhead from creating a DAQmxBase task. I'm honestly not sure how big of a difference that will make, but it may be worth trying.

[Ageradi]

AdamKemp, thank you for your reply.

Actually, I don't have labview installed, and I don't use VIs.

Also, I have found that I can use digital I/O outside of the main thread, but I have to acquire Analog input on the main thread (that's terrible).

[AdamKemp]

I'm not sure you're describing the same issue. The issue described here is specifically about a hang on exit when you call a LabVIEW-built DLL (such as DAQmxBase) for the first time in some random thread. I only suggested using a stub DLL to avoid any potential overhead of calling a DAQmxBase function that might take a while. If that's not an option for you then just try to pick any DAQmxBase function (ideally one which shouldn't take long) and call it from the UI thread before calling any other DAQmxBase functions in other threads. It doesn't matter which function you call. This isn't a bug in DAQmxBase. It's a bug in the LabVIEW runtime engine itself. That's why it doesn't matter which function you call.

I can't think of any reason why this particular issue would cause only analog functions to behave improperly so perhaps that is another issue.

[Ageradi]

Dear AdamKemp,

You may be rignt, there might be separate issues. I tried calling other functions. Doesn't really make a difference. At most 0.5 second. That's not much.

Do the VISA, GPIB, DAQmxBase drivers install the labview runtime engine?

I am afraid to tell you... but there are no DLLs on MAC OS Systems. DLLs are found on windows platforms only. So you won't get far looking this way... Are you the only one working on a fix?

[AdamKemp]

VISA and GPIB don't depend on LabVIEW, but DAQmxBase is built using LAbVIEW so it does require a LabVIEW runtime. I don't know much about its installer, but I would assume it installs the runtime for you.

Sorry for the confusion. I was using the term DLL generically. A .framework on OS X is stll a "dynamic link library", even if they don't use that extension. You could also call it a "shared library", even though that term is used more for linux .so files. I work on too many different platforms to call the feature something different depending on which platform I'm using. It's just easier this way. 🙂