I thought you might appreciate a progress report on this. I have been highly successful.
First let me state that I did not need to use CVI calls. I only used DAQmx calls. Specifically, I linked to the DAQmx ANSI C library.
In the process, though, I enountered a couple of problems.
The first problem was with the methodology in link that I gave to the Microsoft site that specifies a means to call managed C++ functions as callbacks from unmanaged code. Using the technique in the article, I specified a callback that was a non-static member function of the C++ class I created to communicate with DAQmx. I then registered the callback with the function DAQmxRegisterEveryNSamplesEvent. The callback was successfully called, however, when the callback function returned, I would repeatedly get a Win32 exception. I believe that the source of the exception was the DAQmx code.
What I did to get around this particular problem was to write a C function that would then call my class' EveryNSamplesEvent handler function. For the C function to call the class event handler, I used one of the methodologies in the Microsoft article I referenced. Specifically, I made the function pointer that was used to call the class' event handler a global static variable.
The vast majority of the time, this methodolgy works. However, when we change settings, I explicity call DAQmxClearTask and recreate the task. I was unable to find another way to re-register a callback function with DAQmxRegisterEveryNSamplesEvent to the existing task other than to call "ClearTask" and recreate the task from scracth. (Although, I found methods that will change things like the number of channels in the task, the buffer size, etc.) I need to be able to specify a different number of samples that would trigger the EveryNSampes event.
On doing this and then calling StartTask,
sometimes, the EveryNSamples event would not fire. I explicity traced the call sequence, and it stopped at "StartTask" with the EveryNSamples event then not firing. This does not occur every time; rather, it occurs randomly. However, it is unacceptable for our application.
So, the solution that I have implemented that seems to be working as we would like it to is to not use the EveryNSamples event. Rather, I spawn a thread that calls DAQmxReadBinaryI16, StopTask, and StartTask in a loop that is controlled by a loop variable so that the loop will exit when I want it to.
The question of "Supporting" this type of useage was brought up earlier in the thread. What I'll say is this. It appears that the support for this type of scenario is more on Microsoft's Managed C++ environment than it is on the NI end of things. That is, even though I had a few issues that I had to work through, pretty much there was nothing special I had to do in Managed C++ for this methodology to just work. That said, the NI DAQmx C library (other than what I outlined above) easily integrated into Microsoft's Managed C++ code. Personally, I am quite impressed by this because my code is a mix of managed C++ and unmanaged C (within the same funcitons sometimes) with nothing to indicate to the complier which pieces are managed and which are unmanaged and it "just works."
Anyway, perhaps this post should have been in the Multifunction DAQ forum, however, I would expect that most any "C" libraries supplied by NI would integrate virtually as easily as my experience here perhaps with the exception of callback functions. I expect that anyone who chooses this approach would have to test their individual case - especially callbacks - to determine whether this approach is appropriate for them.
On that note, this approach performs better than the DAQmx.NET class library; that is, we are able to collect more sample sets per second using this approach. I did not make a comparison of performance with the DAQmx MFC libraries. I shied away from the DAQmx MFC libraries because I had had problems with what appears to be the way threading is implemented in the DAQmx.NET libraries, and I saw that the DAQmx MFC libraries implemented their own thread management, too. IMHO, the way threading is handled in the DAQmx.NET libraries does not conform to Microsoft convention, and I did not want to take the chance that a similar problem would exist in the DAQmx MFC libraries.
Best Regards,
Matthew
