Buffered freq/pulse measurement that can tolerate oversampling

[viScience]

I would like to synchronize a buffered freq or pulse measurement to a continuous AI task using the shared ai scan clock.

The problem is that there maybe times were there are slow to no pulses to measure and the DAQmx driver will throw an error

indicating that multiple samples clocks were received before any pulse measurements could be made.  What I would like is to have

the sample clock default to a measurement of 0 and this value would be placed into the task buffer so that it will always be sync'd

to the other tasks.

[Kevin_Price]

I *think* you can get this kind of behavior from the new counter/timers built into the X-series boards.  As far as I know, none of the previous counter types support such a mode.

-Kevin P

[viScience]

I have a PXIe-6363 x series board and cannot seem to get this to work.  I have tried all of the bufferred freq and pulse width measurement modes but they all error out

when oversampling.  (ie. receive a scan clock edge when no measurement signal is present)  I looked for a timing or other property that would allow me to override that default behavior but could not find it.  Please let me know if you have any ideas?

[Kevin_Price]

I don't have personal experience with the new counter features of the X-series boards, but I *do* wonder whether this might relate to the "Duplicate Count Prevention" boolean property found deep under the DAQmx Channel property node.

-Kevin P

[John_P1]

Duplicate count prevention is a pretty interesting (and probably poorly named) property.  With duplicate count prevention disabled, the sample is latched in on the rising edge of the source.  If the gate is faster than the source, you could miss the samples that you might expect to read 0 (i.e. imlpicitly-timed buffered period measurement).

This isn't exactly what's happening on the X Series (Duplicate Count Prevention is always "True" for frequency measurements on X Series).  The problem is that there is no sample available in the counter FIFO on the edge of the sample clock.  I believe the error is thrown by the hardware and there isn't much that NI could change in the driver to correct for it, but I'll investigate a bit more just in case.

In the meantime, you might have to resort to counting edges of your external signal sampled from the AI Sample Clock.  If your external signal is high frequency, this would be suitable, but I think it's probably more likely that your external signal is relatively slow so doing this would introduce a very large error.  I'll think about this some more and post back if I think of a workaround.

Best Regards,

[John_P1]

I have confirmed that the error is thrown by hardware.  The best that could be done through software would be to restart the counter on the error, but this wouldn't be desirable since samples would be missed during the software re-arming of the counter.  Unfortunately, I can't think of a deterministic way to determine how many samples you would miss while the counter is re-arming.

So, I think we'll have to come up with some other workarounds.  Can you provide more specifics about the signal you are measuring (max and min frequency) as well as what your accuracy requirements are?  What other subsystems are you using on your X Series?

Best Regards,

[viScience]

Hi John,

Thanks for your help.  In my system I have a PXIe-6363 which is running my AI task and a PXI-6624 which is running 3 buffered encoder position tasks.

In addition I have a Camera link interface that is also running in sync with the AI scan clock.  The goal is to produce TDMS and AVI data that contains all AI and encoder channels

sync'd to the AI scan clock.  This part I have working.  The problem is that the customer would like an additional encoder channel that produces sync'd velocity data. 

I have thought that I might be able to do this with a counter on the 6363 running a buffered freq task but as you have pointed out, this will error out if the measurement signal is not

as fast as the scan clock.  The other option would be to use a encoder position task and reset the counter just after each scan clock reads in the count.  Even this method is elusive since

the Z channel reset must be synchronized with the A/B channel phase and this I cannot control.  Is there another way to asynchronously reset the counter used in a encoder position task?

Otherwise, the only thing I can think of is to just do a regular buffered encoder position task and when I read from the buffer I will have to do a difference and scaling calculation to turn angular position into RPM.

[John_P1]

Hi sachsm,

You can reset the counter asynchronously on a regular edge count task on X series DAQ cards like your 6363 (thank Kevin for originally suggesting this).

However, I'm not sure if doing this is worth it.  You lose noise immunity when you configure an edge count task instead of an encoder task.  The software method seems just as good to me (subtract consecutive samples to find the delta).

Best Regards,