NI 9411 Continuous Edge Counting - external sample clock

[yachen]

Hi

 I have a DAQ setup that uses the following:

• Chassis NI cDAQ9188
• NI 9411
• Quadrature Encoder

I want to make continuous buffered measurement of position reading from the quadrature encoder. I first set up a task in NI MAX:

• It works if I configure my signal as 1 Sample (On Demand).
• It doesn’t work if I change to Continuous Samples (Use digital input sample clock as the external sample clock). I received Error 200284, which indicates not getting enough samples within the Timeout period.
• The only Sample Clock it accepts seems to be the 100kHz Timebase, and the sample rate needs to be 100kHz as well. This is too fast for what I need.

To simply the problem, I changed the task from position measurement to edge counting. The problem still there.

• I tried running the Counter – Count Edges (Continuous Clock).vi shipping example, the result is still the same.
• I have read up about the buffered continuous edge counting; it only says that an external sample clock is required, doesn’t go deeper beyond that.
• I have checked the KBs:
  • DAQ Assistant Edge Counting Error for N Samples or Continuous Samples
  • DAQmx Read VI Error -200284 Samples Have Not Been Acquired
  • Neither of them really answers my question.

Since I can acquire edge counts if the task is set to “On Demand”; I would say the hardware is configured correctly. 

It seems that when the task is set up as continuous buffered acquisition, then it needs an external clock to drive the data acquisition, which is fine. My question is: Why does it only accept the 100kHz Timebase and nothing else? It seems that it will not accept the external sample clock unless it’s the 100kHz timebase (and sample rate = 100kHz). With no sample clock => no samples acquired => Error -200284.

Continuous sampling works in simulation mode. I can use any sample clock, but with thee actual hardware that I have, it only works with 100kHz Timebase.

I have checked the routing of the sample clocks, the counter sample clock seems to support all external clocks.

Any ideas?

Thanks

Yu-An

[Kevin_Price]

I don't know specifics about your cDAQ hardware but have a lot of general background with NI DAQ devices and counters.

The 100 kHz clock is considered an *internal* clock.  Many devices (perhaps including your cDAQ chassis) can't route their internal timebase clocks to be used as sample clocks for counter tasks.  I would expect a more informative error than the one you report.

On the other hand, if you specify a PFI terminal as the source of an external clock and then fail to physically wire a clock signal there, the error you report is entirely expected.  You're telling the task to sample on digital edges at a particular terminal but not providing any edges to be used.

-Kevin P

[yachen]

Thanks for your reply Kevin,

But what you are saying is counter-intuitive to my observation. 

* If cDAQ can't route their internal timebase clock to be used as sample clock, then why it works on my 100kHz timebase?

* If it works on the 100kHz timebase, why not other sample clockss (eg. AI sample clock)?

* I do not have the hardware with me right not to try out the PHI method, but would be interested to know if it works.

Yu-An

[Kevin_Price]

1.  Very interesting.  I can only try simulated devices here but I agree that specifying the 100 kHz timebase and 100 kHz sample rate runs without error.   That's something I never knew was supported.

    I also note that if I select the more generic "OnboardClock" as the timing source, I get a -200303 error which states that an external sample clock must be specified.  I guess I must have always believed that error text and had never tried the 100 kHz option.   I still can't confirm that it works *correctly* with the 100 kHz timebase, but I do see that it doesn't throw an error.

2. It should work to configure for using an AI sample clock (or others), but the AI sample clock will only be generated and available when there's a hardware-timed AI task running.

3.  The PFI pin method can be used if there's a clock signal at a particular PFI pin.  The clock signal arrives there from an external source (function generator, wired from another DAQ board, etc.).   It could also arrive there as a pulse train output from another one of your counters if you set up such a task so the output signal can be used as a sample clock by the encoder measurement task (and perhaps any other tasks whose data should sync to the encoder measurements.)

    If you're using LabVIEW, look at the shipping example named "Counter - Read Encoder (Continuous Clock).vi".  You'll see that the default sample clock source is a PFI pin.   Then also open up the example named "Counter - Continous Output.vi".  It has a place to specify which PFI pin the pulse train should be directed onto.   You ought to be able to make things work by running both examples at once (using a different counter for each).

-Kevin P