pulse width measurment error vs no error measuring period

[dachenba]

Hardware:

NI Cdaq 9172 with one ni 9422 in slot 5 of the 8 slot rack

The Task is to accurately measure pulse width or semiperiod.

Using NiDaq and visual studio c++, language.

Code samples were acquired from National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Counter\Measure Period or Pulse Width

The problem is simply this.

A 1000 hz square wave is applied to counter one (or counter two, tried both) at the proper teminal of the 9422. The square wave is generated by an Agilent 33220A and is the signal verified by scope, and appears to very accurate in period, amplitude and duty cycle (50%).

Using the Nidaq code examples, and making 10  period measurments using the DAQmxCfgImplicitTiming function returns 10 very accururate period measurments.  When performing a measurment on the same signal using the DAQmxCreateCISemiPeriodChan function, the two results returned

for each measurement add up to the 1000 micro second period, however the results returned are approximately 586 micro seconds and 414 micro seconds.  This also occurs  when trying to measure pulse width using the DAQmxCreateCIPulseWidthChan function. Using the DAQmx_Val_Rising

parameter and 586 uS measurments are retuned. If the parameter  DAQmx_Val_Falling is passed the measurments are 414 uS.

Do I have some bad hardware --> the 9422?

I tried changing the signal amplitude from +10V peak to +23Volt peak and the measurements do not change? (period is still accurate)

It appears that the system is having trouble seeing the falling edge of the signal!

Am I missing a ground connection somewhere?

Any suggestions?

[LVbum42]

One thing you can do to check the hardware is verify in measuement and automation explorer if your PFI lines are counting edges correct.  Create a test panel for the counter I/O of the NI 9422 and count edges your known signal slowed down so that you can verify it is counting correctly.  Also, what counter are you using on the module and which PFI line are you wired into to take the pulse width and period measurments?

TESTING MULTIFUNCTION DAQ PFI LINES IN THE MEASUREMENT & AUTOMATION EXPLORER (MAX):  http://digital.ni.com/public.nsf/allkb/4790E23458D698E086256DCD00543C3D?OpenDocument

Regards,

Isaac S.

[dachenba]

Issac,

Thanks for the reply!

Removed all hardware in the cdaq9172 except the NI9422, that's located in slot five.

Slowed down the arb to a 1 hz square wave and then ran the test panel for the 9422.

The rising edge detection works fine and updates the edge count every 1 sec.

The system appears very capable of seeing the rising edges!

The signal from the arb is connected to pin 2 of the 9422 and the signal ground is connected to pin3 of the 9422.

PF1  

Returned freq to 1000 hz, 50% duty cycle, verified with scope... signal is very clean with very fast rise and fall times.

The function:

DAQmxCreateCIPeriodChan(taskHandle,"cDAQ1Mod5/ctr0","",0.0001,0.010000,DAQmx_Val_Seconds,DAQmx_Val_Rising,DAQmx_Val_LowFreq1Ctr,0.000100,4,"");

returns 0.001000 seconds for period

The function:

DAQmxCreateCIPeriodChan(taskHandle,"cDAQ1Mod5/ctr0","",0.0001,0.010000,DAQmx_Val_Seconds,DAQmx_Val_Falling,DAQmx_Val_LowFreq1Ctr,0.000100,4,"");

returns 0.001000 seconds for period

The function

DAQmxCreateCISemiPeriodChan(taskHandle,"cDAQ1Mod5/ctr0","",0.0001,0.001,DAQmx_Val_Seconds,"");

returns 0.000593 and 0.000407  

The function

DAQmxCreateCIPulseWidthChan(taskHandle,"cDAQ1Mod5/ctr0","",0.0001,0.001,DAQmx_Val_Seconds,DAQmx_Val_Rising,"");

returns 0.000594

This should be real straight forward stuff, measuring a pulse width.

I'm overlooking something... but what!

Any additional suggestions.  

[LVbum42]

Your wiring seems correct, however just to verify you may want to look over the counter input section of the cDAQ-9172 user guide.  There doesn't seem to be any issues as you appear to be connecting your signal source to the gate of counter 0 on the NI-9422.  Are you able to compare this behavior to another module?

NI cDAQ-9172 User Guide and Specifications: http://digital.ni.com/manuals.nsf/websearch/D0435486A31A3B038625743900690AEE

Regards,

Isaac S.

[dachenba]

Isaac,

Two different modules were tested and they both have the same issue.

Tried both slots, 5 an 6, same issue.

The 9422 is specified, I believe, up to 4Khz, but as the freq of the signal approaches 4khz, the pulse width error becomes larger and larger.

Conversely,  at very low freq. the error appears less!

One would think that 1kHz would be OK on a device specified for 4khz!

No success yet!

I'll dig through the 9172 manual, looking for applicable info!

[dachenba]

Hello

[dachenba]

Hello,

Nothing in the 9172 manual to suggest anything wrong, with connections or software.

I believe that the 9422 is not capable of connecting a clean signal to the 9172 counter system, to make an accurate pulse width measurement! 

Can someone confirm this. I do not want to waste any addtional time trying to use the 9422 is it's not capable of this.

Any insight/suggestions?

Thanks!

[Kevin_Price]

No real insight as I'm not familiar with your particular hardware.  In general though and by analogy to the hardware I *am* familiar with, I find your observations highly unexpected & surprising as well.  The particular quantization you see for semi-period measurement doesn't seem to break down as a possible off-by-1 type of issue, which is about all I could think to look for.

As to suggestions, you've tried period and semi-period.  What happens when you measure pulse width, either high time alone or low time alone?

-Kevin P

[John_P1 · Accepted solution]

Hello,

The 9422 specificaitons indicate "Input Delay Times" on page 14:

Input delay time

OFF to ON..................................250 μs max, 4 μs typical
ON to OFF..................................250 μs max, 130 μs typical

It seems that it is typical for the module to have a 126 us discrepancy between its detection of rising and falling edges.  This discrepancy would explain the measurements you have reported (a period measurement is the difference between consecutive rising-rising or falling-falling edges, whereas a pulse width measurement is the difference between consecutive rising-falling or falling-rising edges).

Best Regards,

[dachenba]

Thanks for the info.

It seems a contradiction to spec the device speed at 250us or 4000 hz but then spec an input delay at 130us.

But that detail explains the issue!

Thanks again!