Measuring short (faster than the clock) pulse width fails with NI DAQ USB 6363

[BluePhysics]

Fitting that I resurrect this thread the day after Halloween.

Was a solution to this issue ever found? I am having a basically identical problem. I am trying to get code working on a PCIe-6323 that I can confirm works on a PCI-6229. My measurement scheme and the approximate timing of my signals are exactly the same as the original poster. (In fact, I think I may be a successor of Yomach in their (or related) group since the code they posted looks strikingly similar to the code I got from my coworker.)

I can post the full details of my issue if folks are interested.

[John_P1]

If what you're asking is the same as the original post, I would stand by my original suggestion from before.  Reading through the thread it doesn't sound like the original poster ever tried it out.

The 6229 (M Series) and 6323 (X Series) have different counter implementations.  Duplicate count prevention is a configurable parameter on M Series, but not so on X Series.   From my recollection (and the reported behavior in this thread) a period measurement (or pulse-width measurement, or any other gate-based implicitly timed measurement) is sync'ed to the timebase on X Series, and if you get multiple periods without a timebase pulse then the hardware reports an overflow error.  Most users actually measuring the period of a signal would use an internal clock as their timebase so this wouldn't be a big deal.  But in your case you are using an irregular external signal as the "timebase", and so are susceptible to getting the overrun.

With the suggested workaround, the counter would be configured in edge count mode and the actual internal 100 MHz timebase would be used to sync the sample clock signal.

[Yomach]

Hey John,

Sorry for not mentioning it, since I was also discussing the issues with NI support directly at the time.

In the end, we did exactly what you wrote.

We still have some cases (rarer) in which we do pulse width measurement, didn't debug them to see if they also need a workaround now, for now it works...

And BluePhysics, probably a related group 🙂

I assume you're in the NV business?

Cheers

[BluePhysics]

I am indeed. Good to know John's solution worked out.