ReadSingleSampleDouble

[fmarcelino]

I'm trying to use a two edge separation counter, and I have it configured as such...

CWCounter3Task = new Task();
CWCounter3FirstEdge = CITwoEdgeSeparationFirstEdge.Rising;
CWCounter3SecondEdge = CITwoEdgeSeparationSecondEdge.Rising;
CWCounter3Task.CIChannels.CreateTwoEdgeSeparationChannel("Dev1/Ctr3", "Outbound",
minVal, maxVal, CWCounter3FirstEdge, CWCounter3SecondEdge,
NationalInstruments.DAQmx.CITwoEdgeSeparationUnits.Seconds);

The resulting call to ReadSingleSampleDouble, doesn't seem to be returning consistent results.  In some of the cases it's returning a value that is approximately half of the expected value.

If I put a 1 second delay between the configuration of the counter and where I issue the ReadSingleSampleDouble, it works perfectly.

I have run into a similar situation with another project, and eventually I had just left the delay in the code so that it works.

Do you know of any reason why the delay is necessary with the .NET version of the library?  

Thanks in advance.

[JefeL]

Take a look at the example solution located in:

… Documents\National Instruments\NI-DAQ\Examples\DotNET4.0\Counter\Measure 2 Edge Separation\Meas2EdgeSeparation\CS

I can only see a limited window of your program here so it is hard for me to make a direct comparison without more information. You appear to be doing everything the shipping example does and the shipping example does not use a delay before reading. 

[fmarcelino]

Hi Jeff,

Thanks for getting back to me.  I had an epiphany over the weekend since writing that initial question. 

It turns out that reason for the delay wasn't because of the NI libraries, but rather in the start time associated with kicking off some threads to monitor the counters. 

I had a couple of threads that the application would spawn just before each shot, once the values were recorded, the threads would terminate.  The delay it turns out is associated with the amount of time with the thread overhead.

I changed the architecture to make the threads persistent, and on second inspection, the complexity of the threads really isn't necessary (not sure why it was done that way initially as the original developer is no longer here).

Thanks for getting back to me