Can DLL update LabView array asynchronously?

[Scott E.]

Hi,

I have a dll that upon initialization, is event driven outside of LabView.  On a periodic basis (~1ms) the dll collects floating point data that needs to be stored in an array.  I need a way for LabView to not wait for the dll to finish collecting the data, hanging the user interface for minutes.  I'd like to:

1. define the array in LabView
2. pass the array's pointer(or pointer to pointer) to the dll during initialization, which returns to LabView immediately
3. have the dll update the array while the LabView thread is concurrently running.

I would like to store the array inside a LabView vi, in the shift register of a while loop.

Shouldn't this work?  Any alternative suggestions?

Thanks,

Scott

[Scott E.]

Alternatively, can I access the dll in a multithreaded way such that I could:
1.  Make one call to the dll to start the data collection process, where labview would wait until it returned.

2.  If the user hits a 'Cancel' button, make a second call to the dll (maybe in a parallel while loop) where the dll communicates to the first dll call to stop by setting or clearing one of its global variables.


Whatever the mechanism, I need to know that it will work on both the PC and Mac.  Your documentation on external code strongly implies that this should work, but I need some sort of confirmation before convincing my client to invest in using LabView.

Sincerely,

Scott E

Message Edited by Scott E. on 01-29-2007 12:22 PM

[Xaq]

Scott-

I think your best option is to use parallel loop structers in LabVIEW. With one loop making the DLL call and waiting for the DLL to return. The second loop can still run and wait for use input such that the VI doesnt hang and will still allow a user to stop the VI. In your DLL, use your second suggestion (a global variable) to stop the first DLL call from a second call. I would also suggest coding in some sort of timeout into the LabVIEW VI that forceably stops the VI after a certain time period to avoid hanging.

This method should work in Windows, but you will not be able to call a DLL on a Mac (you will have to use some other type of shared library).

[Scott E.]

Thanks Xaq,

The literature says that I can create a Code Fragment, which it implies is the DLL equivalent on the Mac(I'm not a Mac guy).  So for final confirmation - am I correct that the same multi-threaded approach should work on the Mac also, by porting the Windows DLL code to a Code Fragment?

Sorry to need such explicit confirmation, but it's necessary.

Scott

[Xaq]

Scott-

I am not very well versed in calling external code on Mac, but I think what you are looking for is called a Framework and you can build it using Xcode. The best piece of documentation I could find is linked below:

http://digital.ni.com/public.nsf/websearch/A6A6371FE0EA333B86257015005E3400?OpenDocument

This multithreaded approach should work in Mac OS, however, the Framework code may be a bit different than your DLL code when it comes  to thread management and multiprocess comminication.