Building a shared library breaks VI synchronization

[hardison352]

Hello.  I am running LabView 8.2 with an ELVIS (with a 6062E DAQ card)

I am creating a VI that is to control multiple elements of the NI ELVIS that must be called from a .NET program.  Specifically, I need to find a way to synchronize the Arbitrary Waveform Generator and Oscilloscope modules on the ELVIS (I want to generate a waveform and observe it through the scope).  I have been able to do this from within LabView (by using a rendezvous object to roughly syncronize the two operations in software and setting a hardware clock to trigger both modules).  Problem is that this synchronization breaks when I build the lab view project to a shared library and call it from a .NET library (using PInvoke).  When run from the .NET library, all parts execute but the Arbitrary Waveform Generator appears to run after the Oscilloscope completes reading (observed using a separate scope). 

I've confirmed that the inputs to the VI are being properly handled by the .NET code and interpreted by my VI.  I've confirmed that the scope channel does actually read data when run from the .NET library (ran a power supply line to the scope channel and got the right voltage readings back).  I've tried adjusting the frequency of the trigger clock (on the theory that the waveform generator was lagging the scope for less than my initial clock cycle) and do not observe any portion of the waveform via the ELVIS's scope.  Initially I was running the waveform generator in a separate LabView thread from the main program flow, which included the scope.  I have also tried restructuring the VI such that the waveform generator is in the main program flow (branching the error object line just before the rendezvous object for both the scope and the waveform generator).  Both approaches yield the same response.  Running directly in LabView leads to a correct syncronization, building the VI into a DLL and running from .NET does not. 

Has anyone seen anything like this?  Thanks in advance for your help.  I'm quickly starting to run out of ideas.

[hardison352]

Right, so after spending some quality time with the LabView help file reading up on thread execution priorities and the like, I found out what the issue was.  In LabView, if you view the Execution tab in the VI Properties dialog you can set the thread execution priority and "Preferred Execution System".  The former appears to modulate home many CPU cycles your executing VI gets while the latter presents a set of execution modes for different types of programs (data acquisition, pure computation, etc.).  We're interested in the latter item.

The default setting for this is "same as caller".  This likely lead to the change in behavior I was seeing between LabView and .NET (LV probably runs VI's in a more responsive mode, .NET not so much).  So, in the top level VI for my project, I set the execution system to data acquisition (not sure if this was the best option, but it's good enough), saved the VI and rebuilt the library.  You only need to do the top level VI because, by default, you sub-VIs will be set to "same as caller" so they will inherit the change.  With this done, VI behavior when run through .NET is consistent with that observed directly in LabView.