NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx GCHandle

Hello,

 

I've created a .net assembly that encapulates a test.  The test is setup, run, and results are gathered.  I'm running into a problem that only happens when running TestStand and not from VisualStudio 2013.  I do the exact same operations in TestStand as I do a in a test console project (VS2013):

 

  1. Create the Object
  2. Set Properties
  3. Run the Test    <-- Error in Teststand
  4. Get Properties

 

 It appears to deal with DAQmx when trying to read data from a task.  

 

Please see attached error dialog.

 

Thanks.

 

error.png

0 Kudos
Message 1 of 11
(5,307 Views)

Are you perhaps specifying a callback to the DAQmx APIs from a different appdomain outside of the one teststand uses to execute code modules such as from your UI's appdomain?

 

-Doug

0 Kudos
Message 2 of 11
(5,298 Views)

I create the object and set various properties within the sequence file.  I then call a function from the object that executes the "test".  In this function it creates the DAQmx task and registers for events and callbacks.  

 

Does DAQmx require to be in a specific app domain other than the one teststand uses to create the object within the sequence?  If so, what domain?  And could you point me to an example?

 

Thanks.

 

 

 

0 Kudos
Message 3 of 11
(5,295 Views)

Here is an example project of what I am doing and the exception that gets thrown.

 

 

0 Kudos
Message 4 of 11
(5,273 Views)

In looking at your .cs code I do see something that might be a problem. How do you know the daq task is done before you are calling StopDAQ()? Shouldn't you be waiting until it completes? Did you get an exception in StopDAQ? Is that why you added try/catch? Perhaps the exception was trying to warn you that the task wasn't done yet. Maybe you are getting an error because you are calling StopDAQ() and thus Dispose on the object before it completes, so when the other thread later calls into _daqTask_EveryNSamplesRead, the GCHandle is no longer valid since it might have already disposed of it when you called Dispose. You should rewrite the code to wait until the task is done rather than sleeping for 5 seconds. You could do something like:

 

 

Add the following to the top of private void StartDAQ();

 

_daqDone = false;

 

 

Replace System.Threading.Thread.Sleep(5000); with:

 

while (!_daqDone)

{

     System.Threading.Thread.Sleep(100);

}

 

Really there might be a better way though. You might see if there is an API on the daqTask itself to wait until it is done (I'd be very surprised if there isn't such an API or some other way to run things synchronously). I'm not really familiar with the daqmx APIs. You might post on the daq forums for help with this.

 

-Doug

0 Kudos
Message 5 of 11
(5,263 Views)

Hello Doug,

 

The idea is not to stop the task until I have manually stopped it.  The reference trigger is monitoring a critial line, so that if an event occurs it will stop the task and set a flag that I can check.  While the task is running an event will fire so I can read the data and store it away for analysis later.  Everything works great when running directly in visual studio.  I only get this exception from TestStand and I'm thinking it has something to do with firing the EveryNSamplesRead event in DAQmx.

 

The exception on occurs before I get a chance to stop the task and before the event actually fires off my callback function for reading the samples.

 

 

0 Kudos
Message 6 of 11
(5,256 Views)

"The idea is not to stop the task until I have manually stopped it. "

 

That is not the way your code is written. In the .cs file you attached it calls Stop and Dispose on the task after 5 seconds, regardless of whether or not it's done.

 

        public void DoDaq()
        {
            StartDAQ();

            System.Threading.Thread.Sleep(5000);

            StopDAQ();
        }

        private void StopDAQ()
        {
            try
            {
                _daqTask.Stop();
                _daqTask.Dispose();
                _daqTask = null;
            }
            catch { }
        }

 

Is the code you are running in Visual Studio exactly the same as this? It makes sense that calling Stop and Dispose on the task before it is done might cause problems like this. Especially Dispose since that is where something like a GCHandle might get freed. If it gets freed while still in use by the daqmx thread I can see you getting an error like this.

 

-Doug

0 Kudos
Message 7 of 11
(5,234 Views)

What does the callstack for the main thread calling into your code look like when the daqmq thread gets this error? Has is already called Dispose? If so that would be more evidence towards that being that problem and would indicate that the daqmx code is not synchronously stopping its worker thread when you call Stop(). If so you might want to get some help with this on a daq related forum.

Also, it's unlikely that anything being done by the .NET adapter is directly causing this problem. It's just calling into your code. It does create an appdomain but all of your code, including the daqmx calls you are making is all being called in that same appdomain.

 

-Doug

0 Kudos
Message 8 of 11
(5,231 Views)
Another idea, teststand does force garbage collection regularly by default, so if an object is not being properly pinned before being passed to unmanaged code it could be getting garbage collected before it's done being used. You could set engine.DotNetGarbageCollectionInterval to 0 to see if this makes the problem go away.

-Doug
0 Kudos
Message 9 of 11
(5,222 Views)

Hi Doug,

 

I have made the changes you suggested and still it does not fix the issue with TestStand displaying the error dialog and then crashing.

 

The odd part is that it appears the the sequence continues to execute and then passes.  I can see the green window pop up after the 5 seconds.  As soon as I dismiss the error dialog TestStand abruptly closes.

 

Attached is the updated code.  I've included the small console project where it execute without problem.

 

I've opened an issue with NI support and they said it looks fine but will investigate further.

 

Thanks.

0 Kudos
Message 10 of 11
(5,211 Views)