Increasing Quadrature Decode Speed (9402 + cDAQ 9174)

[mrgilpin]

I'm writing a VI that monitors two encoders in real time and outputs a given value. These encoders are extremely high precision (80,000 pulses per revolution) and I need a high sample rate (> 10kHz) to capture the required movement.

If I run the attached VI using the counters on a PCI-6281, my effective sampling rate of the quadrature decode is ~12,800 Hz for each channel. There is obviously a software bottleneck due to the binary file disk streaming in each loop. This is, or something just like it, is needed to "idiot proof" the VI. If somone stops the VI at any time, the state of the encoders needs to be saved.

What is troubling, is that when I switch the counters over to an NI-9402 in a cDAQ 9174 chassis, the effective sample rate for each channel drops to only ~420 Hz.

What is causing this sharp decrease in speed??

I assume that right now the task is software timed and perhaps I should switch to hardware timed?

What I need is for this to run as fast as the software bottleneck allows.

[Kevin_Price]

Two problems:

1.  Software-timed single-point reads mean that you've got a bad ratio of driver call overhead per data point collected.  Hardware timing and multi-point reads will be a *much* better choice.

2. This is compounded by the USB connection to the cDAQ.  USB isn't particularly good for low-latency data in small packets.  Similar overhead issue plus other things.

On the 6281, you could create a dummy AI or AO task to generate a sample clock that is borrowed/shared by the encoder tasks.  I'm not sure what options you might have on the cDAQ -- I'm not as familiar with that product line.   Either way, once you set yourself up with hardware timing and reading the data in good-size chunks (maybe a few thousand samples per chunk, corresponding to some single digit number of read calls per sec), you should have no problem keeping up with a 10-20 kHz sampling and storage rate.   Well, no problem with the data acq function calls.  You may find that you need to adopt a kind of producer-consumer architecture that separates the file writing code into a different loop than the data acq code.

-Kevin P

[mrgilpin]

Thanks for the reply.

I'm trying the hardware timing option using a single channel with the 6281 using ctr0 to sample the quadrature and ctr1 to provide the sample clock signal at a fixed rate.

However, I'm still missing states.

I'm not getting a full 360 degree reading per revolution. I checked the encoder in MAX using the edge count, and I'm getting a total of 320,000 edges per revolution counting both the A and B output. This corresponds to 80,000 pulses for revolution.

In the end, it's OK if the VI returns samples realtively slowly (100Hz) as long as those values are correct.

I've attached the simplified hardware timed version.