Fast data acquisition from DLL

[Pug2971]

I am working with an instrument that the only way to interact with it is a specific C++ DLL. I need to poll data pretty rapidly and store/display the data on a pretty rapid scale. The issue is despite any Queues or DVRs that I try to make I come to the same problem. If LabView is doing anything else, despite multithreading or a difference in VI priority/times loop priority, the Library call will take a backseat. A call that normally takes 20 ms could take hundreds. For example, let’s say I make two timed loops with one being the library call at a high priority, and the other any sort of analysis at a much lower priority. The library call loop will be delayed more and more depending on how fast I make the analysis loop go. Somehow the analysis loop will nearly always be on time but the library loop will just be more and more delayed, despite having a much higher priority. 

That is just one example of what I’ve tried. I have tried priority in timed loops, priority in Vis, and semaphores for just stoping the analysis and waiting for the Library calls to finish. Each is too slow for what I need. Is there a way that I can make sure that labView gives priority to the DLL finishing before continuing analysis? 

[mcduff]

Check if the dll is executing in the UI thread; the top of the dll icon will be colored orange. If safe to do so, change the thread from UI in the dll's properties.

mcduff

[rolfk]

---

@mcduff wrote:

Check if the dll is executing in the UI thread; the top of the dll icon will be colored orange. If safe to do so, change the thread from UI in the dll's properties.

mcduff

---

What mcduff said. But beware, unless the documentation states explicitly that the library is multithreading safe, the only person who can tell if the library is safe to be executed in LabVIEW from other threads than the UI thread would be the original developer. Possible problems if it isn't multithreading safe and you set it anyhow to run in any thread can range from crashes, to strange behaviour, up to no apparent problem until you have installed the app in a remote lab at the other side of the globe where you have to jump through hoops and loops in order to be able to debug it.