6215 suitability questions

[JonHendry]

John,

That did the trick. Thanks so much! 

[JonHendry]

John,

One last point to clarify...

Which ctr1 input should I use for the sample clock? I have a switch hooked up to ctr1 Gate (PFI 2), but judging by Figure 8-30 in the USB-621x user manual, Gate and Sample Clock are two different things. And I'm finding that I have to close the switch twice to get it to register.

Is ctr1 Gate the correct connection, or is there another input I should be using?

Thanks,

Jon 

[John_P1]

Hi Jon,

Unlike our other M Series devices, the sample clock is a separate input from the gate on a 621x.  The new X series cards also use a seperate sample clock and gate input.

I'm actually on the road this week so I don't have a computer with DAQmx Base or a USB 621x handy, but if I remember correctly DAQmx Base will allow you to use any PFI line for the sample clock input (but must use default terminals for the counter gate/source/output).

So the problem is that every other pulse from your external signal is registering as a sample for the counter task?  Does the pulse work properly to sample the Analog Input task?

Do you have ctr1 configured as an edge count task?  This is what I had in mind for your application--in this configuration the Gate input of the counter would not be used (more in-line with fig 8-4 of the 621x manual).

The behavior you're seeing doesn't quite make sense to me, is there any way you could post the relevant part of your code so I can take a look how everything is configured?

-John 

[JonHendry]

John,

I've attached my messy, ill-considered code

"So the problem is that every other pulse from your external signal is registering as a sample for the counter task?"

I believe so. Here's the output of a run. Each line starting with "Time:" prints on the second closing of a switch connected to PFI 2 (Ctr 1 Gate).

What is being printed are the ms since start, the number of samples read (100), and the values of samples 1 and 100. Counter 1 is running at 1khz.   

dhc023738:ctr jon$ ./twoCtrChain

Reading

Time: 4835 mS Acquired 100 samples. Edge count: 216 4834

Reading

Time: 7540 mS Acquired 100 samples. Edge count: 4835 7539

Reading

Time: 10029 mS Acquired 100 samples. Edge count: 7539 10028

Reading

Time: 13315 mS Acquired 100 samples. Edge count: 10028 13314

Reading

Time: 14943 mS Acquired 100 samples. Edge count: 13314 14942

Reading

Time: 18641 mS Acquired 100 samples. Edge count: 14943 18641

Reading

Time: 20746 mS Acquired 100 samples. Edge count: 18641 20746

Reading

Time: 22653 mS Acquired 100 samples. Edge count: 20746 22653

"Do you have ctr1 configured as an edge count task?"

Yes. 

char        ctrChan1[] = "/Dev1/ctr1";
char        clockSource[] = "/Dev1/PFI2"; // Sample clock, ie switch input, input on PFI2, pin 3.
DAQmxBaseCreateCICountEdgesChan(ctr1TaskHandle,ctrChan1,"",DAQmx_Val_Rising,0,DAQmx_Val_CountUp);
DAQmxBaseCfgSampClkTiming(ctr1TaskHandle,clockSource,sampleRate,DAQmx_Val_Rising,DAQmx_Val_ContSamps,samplesPerChan);

Message Edited by JonHendry on 11-06-2009 05:57 PM

[John_P1]

Hi Jon,

The code looks good.  From the logs, it looks like the edge count from the counter is matching up with the OS clock pretty closely as we would expect.

It looks like you are telling the driver to read 100 samples per Read (samplesToRead parameter).  The DAQmx Read call is blocking and shouldn't return ANY data until all requested samples are available in the input buffer or the timeout has occurred. 

From the looks of things, it seems that two flips of the switch might be generating more pulses than we first thought--is there any way you can scope this signal so we can characterize the actual edge we are trying to trigger off of?  If this is a mechanical switch, we could be triggering several times each switch due to the bounce (each switch would have to register over 50 pulses to explain the behavior).

At this point I'm still speculating but it's the only suggestion I can think of right now that might explain the behavior you are seeing.  As far as a solution, I'll have to look into what options we have in DAQmx Base when I get back into the office next week.  In the meantime, if you could scope out the digital signal and post a screenshot it could help us pinpoint the issue.

Best Regards,

John

[JonHendry]

John,

Unfortunately my scope doesn't provide screen shots.  I do believe it needs debouncing. If I set samplesToRead to, say, 4, I get the following output with a single throw of the switch:

dhc023738:ctr jon$ ./twoCtrChain

Reading

Time: 706 mS Acquired 4 samples. Edge count: 602 705

Reading

Time: 707 mS Acquired 4 samples. Edge count: 705 706

Reading

Time: 709 mS Acquired 4 samples. Edge count: 707 707

Reading

Time: 711 mS Acquired 4 samples. Edge count: 707 707

Reading

Time: 712 mS Acquired 4 samples. Edge count: 707 708

Reading

Time: 714 mS Acquired 4 samples. Edge count: 708 708

Reading

Time: 715 mS Acquired 4 samples. Edge count: 708 708

Reading

Time: 717 mS Acquired 4 samples. Edge count: 708 708

Reading

DAQmxBase Error -200284: <err>The acquisition has stopped due to an error.

 The onboard FIFO may have overflowed.  

  I suppose it's too much to hope that the built-in debouncing filter can be activated from within mx Base?

Thanks,

Jon

[John_P1]

Hi Jon,

Unfortunately you're correct, the digital filtering isn't supported in DAQmx Base.  Your best bet is probably going to be to use an external debouncing circuit, it seems that this is in fact the issue.  The other option might be to parse the data in software to throw away duplicate edges (within a certain tolerance of the first timestamp of the sequence).

-John