Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading a counter is really slow

I have some pretty simple code that tries to read out a counter at <8 Hz for display on an X series.  On each read 1024 samples are requested and then displayed.  I've noticed that reading out the counter is remarkably slow given how few samples are requested (~90-100 ms) such that doing this without an asynchronous read is almost impossible (nearly 100% of thread time is spent in the counter read call).  Is there a reason for this?  The counter is buffered and the data being requested is negligable (few KB).  Am I missing something?

 

Rough code:

 

int numberOfSamples = 1024;

myXCounterTask->CIChannels->CreateLinearEncoderChannel("Dev1/Ctr3", "X Counter", CIEncoderDecodingType::X1, false, 0, CIEncoderZIndexPhase::AHighBHigh, 200E-9*1000, 0, CILinearEncoderUnits::Meters); 

 

...some ommitted code to configure PFI lines for reading

 

myXCounterTask->Timing->ConfigureSampleClock("/Dev1/PFI0", 8000, SampleClockActiveEdge::Rising, SampleQuantityMode::ContinuousSamples, numberOfSamples*10);

 

myXCounterTask->Triggers->ArmStartTrigger->Type = ArmStartTriggerType::DigitalEdge;
myXCounterTask->Triggers->ArmStartTrigger->DigitalEdge->Source = "/Dev1/PFI4"; 
myXCounterTask->Triggers->ArmStartTrigger->DigitalEdge->Edge = DigitalEdgeArmStartTriggerEdge::Rising;

 

//buffer a lot of samples to be sure we don't lose any
myXCounterTask->Stream->Buffer->InputBufferSize = numberOfSamples * 4 * 20;

 

counterXInReader = gcnew CounterReader(myXCounterTask->Stream);

 

Then my read out function just calls:

 

counterXInReader->ReadMultiSampleDouble(numberOfSamples);

 

I time almost 100 ms per call!   My read doesn't happen until after the counter samples have already been recorded, so I don't think its waiting for samples to arrive.  I also don't see any dropped or missing samples.  I can of course refactor this to use async callbacks, but its surprising to me that the daqmx function call is so incredibly slow, which makes me wonder if I'm doing something wrong.

0 Kudos
Message 1 of 4
(3,345 Views)

Hi saratoga,

 

This is strange behavior. Are you sure it is not waiting for samples to arrive? A simple way to check this is by changing the number of samples to read and see if the execution time changes.

Nolan H.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 4
(3,293 Views)

The code can't be triggered until after at least a few thousand samples have been acquired (the read is triggered by the completion of the sequence of events being counted), and the delay is less than it would take for the full number of samples to be accumulated, so I don't think it is waiting.

 

I'm assuming as I've configured it that I should just get the first N samples acquired right?  So even if more are coming in, it shouldn't be waiting?  

0 Kudos
Message 3 of 4
(3,290 Views)

I am a little confused by how the trigger is set up. But my initial thought is that it looks like the sampling rate is 8000 Hz and you are requesting 1024 samples which would take around 100ms. This would be pretty easy to try and verify. But something is telling me I am not understanding your application correctly…(?)

Nolan H.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 4
(3,275 Views)