Setting Up Sample Clock for Counter

[diarmaede]

All,

I am setting up counters channels to monitor angular positions from 4 encoders. I have not set up counters before. The encoders have 90k pulses per revolution.  I would like to capture >=8400 data points per second. If possible, I would like to synchronize the data capture from the encoders with a timed loop that runs at 840Hz, collecting at least 10 encoder readings per iteration of the main control loop.

I can set all this up, generally speaking, but I get error -89136, "Specified route cannot be satisfied, because the hardware does not support it," when I try to use "PXIe_Clk100" as the clock source. Can anyone point me to an article offer guidance on how I should set up the timing/clock settings? I have done some web research, but I haven't found anything helpful.

Unfortunately, I cannot share my code in this forum, but I would be happy to answer any questions.

Thanks in advance for your help.

[Kevin_Price]

1. On many devices, counter tasks aren't able to generate their own sample clocks.  Sounds likely yours is one.

2. They generally *can* borrow a sample clock from another task on the same device (if you're using a multifunction device).   With a PXI system, they can also generally borrow one from any other device in the chassis.

3. I've often found it easiest to create a dummy AO task that continuously generates 0.0 volts on a channel not physically wired anywhere.  Then I borrow its sample clock to use a sample clock for any counter tasks.  Just set the AO sample rate to 8400 Hz.

4. In this arrangement, it's important to start all the counter tasks first, and then start the AO task last.  This will sync sampling on the counter tasks.  The following link does a pretty similar thing, but with a dummy AI task and edge counting.  Same basic idea though.

5. I wouldn't use an official Timed Loop.  It's usually best to let tasks help you time your loops.  Request 10 samples from each task, and that'll make the loop (try to) run at 840 Hz.  

6. Frankly though, it's tough to make loops run *reliably* in Windows at rates approaching 1 kHz.  Can you request 100 samples at a time to get data updates at 84 Hz instead?  That'd likely work a lot more consistently.

7.  If you actually *need* data updates at 840 Hz, I'd follow up the 10 sample read with another read call where you input the special value -1, which means "read whatever's still leftover in the buffer".  This can help prevent you from getting a DAQmx buffer overflow error if/when Windows fails to keep up with this 840 loop rate.

-Kevin P

[diarmaede]

Hi Kevin,

Great information. Thanks.

You made me realize that I left out important information in my original post. The device I am using is a PXIe-6363 installed in a PXIe-1078 chassis. I am modifying LabVIEW RT code written by a colleague.  Software function has to be precisely synchronized with UUT hardware that is running at 840Hz, so the timed loop has been deemed important.

I'll look into your suggestions. Thanks again!

[Kevin_Price]

I haven't done serious RT work for many years and LV versions now, so take this as well-meaning but speculative advice.

Even under RT, I might be inclined to time the loop by requesting exactly 10 samples rather than using a Timed Loop.

In the Timed Loop approach, you should be requesting "all available samples" with every call to DAQmx Read.  You should NOT request a specific # of samples, because that would overconstrain the timing of the loop.  You need 1 and only 1 timing source to be in control.

So that much of it is fine, the problem is that by requesting "all available samples", you recognize and acknowledge that you may occasionally get 1 more or 1 less than the typical amount.  If you pass this array of samples around anywhere, it doesn't have a fixed size, and you risk getting the memory manager involved in things.  Generally not a great thing for RT.

Timing a regular while loop by specifically requesting 10 samples every time should give you good timing *regularity* as well as *fixed packet size* for your data.

Just a little something to consider.

One last tiny detail I thought of.  If you run tests for a long-ish time, you may have another thing to deal with.  The 840 Hz of the UUT is based on its own master timing source.  It won't exactly agree with your PXI system.   Many of NI's devices are spec'ed to <= 50 parts per million base accuracy.  No idea about your UUT.  But there's room for some disagreement, especially as the test lasts longer.

Further, 8400 Hz isn't precisely possible with your 6363.  It can only do integer divisions of the 100 MHz timebase, putting you no closer than ~8399.8 Hz.   Now granted, this isn't a *big* error, but it is one more thing to consider.

If you do need to do long tests, it's best to find a way to sync via hardware timing signals if at all possible.  This may end up having implications about how you set up your tasks and write your code.   There'll be trade-offs to consider.

-Kevin P