Cannot measure frequency below 20 Hz on a NIDAQ 9178 chassis with NI 9402 in sample clocked mode.

[manisha.singh]

Hi,

I am trying to measure frequency using NI 9402 in NI cDAQ9178 chassis. I am setting the clock for my counter channel to be my chassis ai Sample Clock. Please find the attached code.

I am able to measure frequency above 20 Hz. For frequencies less than 20Hz, I get the following error:

DAQmx Error: Multiple Sample Clock pulses were detected within one period of the
 input signal. Use a Sample Clock rate that is slower than the input signal. If
you are using an external Sample Clock, ensure that clock signal is within the j
itter and voltage level specifications and without glitches.
Task Name: _unnamedTask<0>

Status Code: -201314

Setting the Rate to 1 also not does resolve the issue.

OTHER DETAILS:

* Running on 64 bit, Win7 platform.
* NIDAQmx Driver Version: 9.2.3f1.

Please let me know if you need any more information.

Thanks!

Regards,

Manisha Singh

The MathWorks

[Matt_McLaughlin]

Hi Manisha,

Reducing the sample clock rate to be below the signal should eliminate this error, so it is surprising that changing the rate does not help. When you say that "setting the Rate to 1 also does not resolve the issue," do you mean the same error message is being given or are other errors coming up?

I will check to see if I am able to verify this isssue, using the same setup and code.

[manisha.singh]

Hi Matt,

Thank you for looking into this. Yes, setting the sample clock rate to 1 does not resolve the issue. I get exactly the same error message. It feels that the sample clock has a minimum rate limit and I am unable to go beyond that even after setting to a lower value.

Let me know if you have any other questions.

Regards,

Manisha

The MathWorks

[vharihar]

Hello Matt,

I wanted to follow up with you regarding this issue. I executed the same C program that Manisha had attached as part of the original post with NI-DAQmx 14.5 and noticed the same error message.

Is this a documented bug? Can we get a CAR# to track this issue?

Thanks,

Varun Hariharan

The MathWorks

[John_P1]

According to the 9178 user manual, the very first clock edge will latch a sample (or try to anyway):

Therefore, the counter requires a full period of the input signal between when it is armed and the first sample clock edge.

In your case, the counter is armed "immediately" before the first sample is taken (50 ms to start the task might be a reasonable expectation... I suspect this is where your 20 Hz limitation comes from):

	DAQmxErrChk (DAQmxStartTask(CItaskHandle));
	DAQmxErrChk (DAQmxStartTask(AItaskHandle));

Try putting a delay between the start of your counter task and the first AI sample clock edge--it could probably be accomplished via a software-timed delay between the calls to start the tasks, but I'd recommend using the DAQmxSetStartTrigDelay function on the AI task for a more precise hardware-timed delay.

Best Regards,

[HeisenBerger15]

Alright so I got everything working correctly in both C and LabVIEW code.

The problems is in fact with the first sample, as John_P1 suggested. You simply need to delay that first sample from being requested. It is simple to do this in software instead of hardware.

If you are using CVI, just add #include <utility.h> to the top of your .c file and then add a delay before your DAQmxErrChk (DAQmxStartTask(AItaskHandle)); line.

Comment out / remove the DAQmxSetStartTrigDelay(AItaskHandle,10); line, as it wasn't doing what we thought it would. (Hardware delay).

I added Delay (.05); to delay long enough for the full period of the input signal at 20 Hz.

Depending on your frequency, this value may need to be adjusted. 100ms wouldn't be a bad idea.

This is expected behavior, and I don't think we need a CAR.

Let me know what you think!

-CB