Multifunction DAQ
Measure encoder frequency with PCI 6024E
Hi Jon,
Are you getting any errors when the code hangs? The maximum and minimum frequency inputs are used to determine which internal timebase to use for your measurement, so tweaking these values isn't going to change the behavior you are seeing. If I had to guess, it sounds like the high frequency case and the low frequency case are probably hanging for different reasons:
High Frequency Case: One common issue when trying to measure high frequency signals is error -200141 (data has been overwritten before it could be read by the system). We have benchmarks available for the maximum rates that you can acquire on a counter without acquiring any errors (the computer used in the benchmark is a bit outdated and this benchmark is very system dependant). Keep in mind you're using the Large Range 2-counter method. With a 30 kHz input and a divisor of 10, this would give you a 3 kHz transfer rate.
From the benchmark page linked above, you can see that using DMA vs. interrupts is going to make a great deal of difference in the throughput you can sustain over the counter lines. You can set the transfer mechanism to DMA using the following property node:
If you are using other subsystems of the board concurrently, you might want to take note that the 6024E only has a single DMA channel available.
Low Frequency Case: A common issue here might be a DAQmx Read timeout error (-200284). However, since you have the timeout set to -1 the error will never be thrown and DAQmx Read will instead block until enough samples have been acquired. If the desired number of samples never are taken in, the code will wait on DAQmx Read indefinitely unless there is a timeout set.
In your case, the rate that sample are being taken is completely dependant on the frequency of the input signal (Implicit timing). Since you have set a divisor of 10 and are asking for 100 samples from DAQmx Read, we will wait on DAQmx Read until 1000 pulses have been input (100 samples worth of data). Does this explain the behavior you are seeing?
If this is the issue, one common workaround is to set a timeout and handle the error when it occurs so that you can keep the loop running and stop the code gracefully with the stop button.
I'm not sure exactly what the requirements are of your application, but you might want to give something like this a try:
Here I've taken out the buffering and am just acquiring the most recent frequency value after every loop iteration. The jitter is going to be slightly higher (±1 timebase tick) since we are not dividing it across multiple periods like in the Large Range 2 Counter method, but the plus side is that data will be available more quickly.
Best Regards,
John
