Time out even though a measurement is made for pulse width

[Cimteker]

Thanks Kevin.

Line IO.setOutput("Nest1/LIInput") provides power to my DUT, after it powers up it generates the pulse that I need to measure

I hooked up a function generator to my pin and had no trouble measuring half a second pulse. It still times out when I run my script. I am thinking that it needs to see a rising edge of the next pulse to complete the measurement. There's only one pulse generated in my scenario. Do you know if this hardware is capable of measuring just single pulse width?

Thank you

CT

[Kevin_Price]

I'm pretty confident that the device can measure a single pulse and shouldn't need to see an additional rising edge.  I guess you could test this by wiring a DO line over to the pulse width measurement pin, then control the DO line from MAX while you run your script.

My only other thought (that doesn't really make sense to me, but hey, it's *something*) is that there may be some issue in the startup timing/sequence that's leading to odd results.  You first start the measurement task, then sleep for a bit, *then* power up the DUT, then immediately try to read a pulse width.  Maybe investigate your knowledge and assumptions about the timing and sequence there?

-Kevin P

[LeNIn_Kumar]

your question itself has answer, Your acquisition is for "ONE sample", But there is NO perfect PWM, the frequency always has a jitter. Every time the signal wiggles a bit you may lose a pulse.

Make the window bigger to catch at least 2 pulses and decide on the pulse,

Only disadvantage of this approach is you may receive output delayed by "one pulse" time.

[Cimteker]

Thank you LeNIn_Kumar but I do not have 2 pulses. My DUT generates a single pulse when it wakes up and I need to measure it.

In the meantime I had a function generator hooked up and I was able to measure my pulse width. Now, when I think about I should have set it up as 0.1 Hz with 5% duty cycle. That would effectively give me a 500ms pulse every 10 seconds.

CT

[DuncanW.]

Hi cimteker,

I echo Kevin's feedback in that you are probably not configuring the task settings correctly. However, it will be hard to track down which particular setting is wrong without having your code and being able to tinker with it (debug it).

Would you mind linking the Python library you are working from? I can't seem to find documentation on these particular function calls. Also, would you mind attaching the entire script so that we can run the code ourselves?

If you could attach a picture of the pulse you are trying to capture, that would be helpful as well.

Best,

Duncan W.

[Cimteker]

Hi Duncan,

Thanks for your interest.

I am including probably everything that you need to run my example. I am using SciTE editor to run my script. Now, I am getting very low values instead of a time-out. I am looking for a function call that will put a low pass filter in front of my signal. I was hoping that specifying the expected pulse width of 250-750 ms would eliminate microseconds results, but it does not.

Thanks again

CT

[Kevin_Price]

To the best of my knowledge, the Min and Max specification you can define for counter measurements is generally just used to decide what timebase to use.  What this usually amounts to is that the fastest timebase is used unless the Max time would make the counter rollover past 0.

For example, on your 6229 the fastest timebase is 80 MHz and your counter has 32 bits.  When it counts time based on the 80 MHz timebase, it will roll over in about (2^32 / 80e6) ~= 54 seconds.  If you specified a Max time of 75 seconds, DAQmx would choose to use a slower timebase that wouldn't roll over.

So, that being said, your device also supports digital filtering on PFI lines.  Filtering works differently on different families of products and I'm afraid I have no idea what the python syntax would be (or if this part of DAQmx is supported in the API).  But it's worth some effort to look into this.  If you get small measurements, it may be due to short transients during device powerup and the digital filtering feature would likely help.

-Kevin P

[Cimteker]

Thanks Kevin,

Honestly, I spent hours looking through the help file for any type of filtering. Could you point me to a C or LabVIEW call? I'll find my way from it to my Python wrapper.

Thanks

CT

[Kevin_Price]

In LabVIEW, it'd be a call to a DAQmx Channel property node. The pull-down selection from the property node goes "Counter Input-->Pulse Width-->Input-->Digital Filter".  Then you'd set Enabled==True and the MinimumPulseWidth parameter.   Hope that helps you in your search and hope that the API supports the same capability.

-Kevin P

[VicL]

CT,

I realize this post is about 3 years old, but I did not see a solution and I found one.  I recently had the same problem with the timeout error.  NI MAX would measure the pulse yet still timeout.  The measurement in MAX matched my scope reading.  My LabVIEW code would timeout and report a pulse width of zero.  I was using the DAQmx Timing VI to set my measurement to Implicit/Finite samples with one sample per a channel.  This setup would give an error of buffer too small and the buffer had to be set to at least 2.  I changed the 1 sample per second to 2 samples per second and the measurement worked without the timeout error.  It accurately measured the one pulse width and did not error expecting a second pulse.  The single measurement could be repeated without problem.  I'm not 100% sure but I think the solution worked because 2 counter measurements are needed for one pulse width measurement.  I have not found documentation that supports this theory, but it makes sense.