LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Making pulse frequency measurements with NI USB-6356.

Solved!
Go to solution

I'm back to previous problems with my rotary encoder and making good frequency measurements. Following this earlier thread (Connect Non-TTL rotary encoder to USB-6356) I have the encoder hooked up so that I can read it as a digital signal using a counter.

 

Today I tried making 'CI Pulse Freq' measurements. The graph produced was pretty nice and seemingly agreed with the frequency I expected and what I saw on an oscilloscope. A reasonable amount of variation was visible (which is good, since I'm trying to troubleshoot the variation - tricky if my frequency step size is enormous and/or no variation appears...) so I was fairly pleased.

 

However, I don't know that I have a good way to plot this as a function of time. The number of pulses that I received measurements for was much lower than the number of pulses, and so I suspect I'm accidentally making a single measurement over and over, and the loop time is too long. This is backed by seemingly my For loop always having one element (that I saw whilst building the VI).

 

How can I set this up to make the buffered measurements described in the X-Series manual? (Chapter 7 - Counters). Will doing that enable me to measure every pulse? If I can, then presumably the time becomes something I can work out (after, if need be) and plot against.

 

The pulses were occurring at about 13kHz, which I don't think should be too problematic for the USB-6356. In future pulses might occur at rates up to around 130kHz, but if this is too difficult we can consider replacing the rotary encoder with a lower-resolution model (who needs 0.1 deg anyway?)

 

I'm reasonably sure that currently my problem is bad programming, but I'm not certain that at some point it won't be hardware/connection limited.

 

Attached is a simple VI that hopefully reflects the VI I earlier used (simplePulseFrequency.vi). Unfortunately the actual VI was replaced by a more messy and not-so-good 'CI Freq' measurement version.


GCentral
0 Kudos
Message 1 of 15
(4,117 Views)

Hi,

 

Can you post the environment that you're using? Also, what bit LabVIEW are you using? If you're using 64bit, have you tried switching over to 32bit? LabVIEW 64bit isn't quite as optimized as 32bit is in my experience.

 

If you are using Windows, then I have some bad news for you. If you take a look at this forum post: https://forums.ni.com/t5/LabVIEW/Time-loop-at-1-MHz/td-p/2822284 you will see that RavensFan says this, "In Windows, only the 1 kHz clock is available." I can tell you from experience that it is futile trying to get Windows to sample a waveform any faster.

0 Kudos
Message 2 of 15
(4,094 Views)

Thanks for the reply. I'm using 32 bit LV2016. 

 

Certainly I can't run a timed loop faster, but I don't think a timed loop should be necessary. A DAQmx Read can definitely provide better resolution than 1kHz even if you just call standard reads in a while loop. 


GCentral
0 Kudos
Message 3 of 15
(4,082 Views)

I haven't been able to find any data sheets to prove this, but this is what I've observed using daqmx read on a waveform.

The digital clock (the same one used in a timed loop) is what is used to determine when to pull data from a digital acquisition line. Until the clock says so, the data will remain unchanged. Therefore, if I have a waveform that is 0 V at 0 ms and 0.5 V at 1 ms, then all DAQmx Reads taken between the 0ms and 1ms interval will read 0V.

I'm not sure the specifics, but if I had to make a guess, DAQmx Read only pulls a number from a buffer. The buffer is updated every time the digital clock allows it to be.

Don't quote me on this, but that is what I've observed. I might have a loop that has run over 3000 iterations within a ms, but all 3000 of the values pulled from the DAQmx Read function remain the same until the next ms ticks over.

However, if you manage to find a way to pull data from the digital line any faster on Windows, I'm all ears.

0 Kudos
Message 4 of 15
(4,072 Views)

Ah. What I meant in my original post is that I think my loop is only reading one point per iteration. Therefore, the read rate is limited by the iteration of the loop rate, and although I can try and optimize that (by, for example, moving the graph updates outside the loop) I'm still unlikely to read all of the points.

 

Trying to time my loops would give me timing points, and that might allow me to have a time vs frequency graph, but then like you describe I'll be limited to slow loops, or external triggers and some sort of buffering anyway.

 

What I'm (probably) looking for is a way to get the DAQ board to continuously make measurements, then every time my VI iterates the while loop, it picks up the unread/unfetched points from the DAQ memory and loads them into the loop's array in the shift register. This would allow the loop to iterate 'slowly' and still read data at a high frequency, with a much higher sampling rate.

 

I just haven't worked out how to do it... I suspect some collection of DAQmx Timing (but I think that might give me Sample Clock timing, which isn't what I want, I don't think), Timing Property Nodes or a 'Samples to Read' value (but DAQmx Read by default reads all available samples, I think...).


GCentral
0 Kudos
Message 5 of 15
(4,065 Views)

Ah. Sorry if I'm not good at writing this down in an understandable manner.

 

What I'm trying to say is that I've observed that DAQmx Read will sample as fast as the polling loop will allow it (sometimes even over 500 times per ms). However, what DAQmx Read will output is not what you think it would. Ideally, DAQmx Read would directly read the value from the digital or analog line. This is not the case. DAQmx Read merely pulls a value from a buffer. In order to get the maximum benefits from DAQmx Read, this buffer needs to update as fast as DAQmx Read is polled. However, this buffer is triggered by the digital clock, the same digital clock that is limited by Windows to have a frequency of 1kHz. This means that no matter how fast the DAQmx Read function is called, the limiting factor will always be the 1kHz timing of the digital clock.

 

To test this, feed an analog waveform (ideally something less than 500 Hz according to Niquist's sampling theory) into a DAQmx Read function. Have the function be polled as fast as possible within a while or for loop. Save the measured values into an array to be observed later. Within the while loop, take a timestamp after each DAQmx Read function. Save these timestamps to an array to be observed later. You should see that between each ms, the voltage values read are the same value. The value will only change after a ms has passed.

 

I have performed the above test on my system, (a Win7 64bit NI PXIe chassis on 32bit 2013 LabVIEW) and have observed that the maximum sampling rate achievable (regardless of how fast my while loop may poll DAQmx Read) is 1kHz. This is supported by the symptoms of your test as it would seem that you cannot get a good measurement out of a 13kHz waveform.

 

If you do end up getting different values from the DAQmx Read function within a ms of each other, please let me know how. It is an issue that has been plaguing me for months.

0 Kudos
Message 6 of 15
(4,058 Views)

This thread is getting cluttered with misinformation.  Well-intended and pretty detailed, but pointing in fundamentally wrong directions.

 

There are shipping examples for DAQmx continuous voltage input that will clearly demonstrate the ability to sample into the 100's of kHz or more, depending on your board's max sample rate specs.

 

To nclark:  I believe what you're observing, but your diagnosis is wrong.  Run one of the shipping examples for AI and you'll see that distinct voltages can be sampled much faster than 1 kHz.

 

To cbutcher:  to perform a buffered measurement, you'll need to include a call to DAQmx Timing.vi in the config chain before starting the task.  Once you've set up a buffered task, you can continuously retrieve lossless data as long as you your read rate keeps up with your sample rate.  One common practice is to read data from the buffer about 10 times a second, reading whatever amount of data is available at the time.

   As you implied, you can accumulate the periods of all your lossless frequency data to create your own timestamp array, allowing you to plot freq vs. time rather than freq vs. array index #.

   

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 7 of 15
(4,041 Views)

Wow. Thank you so much for that reply. I'd rather be proven wrong than not. I've no idea what's going on in my current VI that is causing that measurement clipping, but you are correct in having me pull up an old example VI to observe how that works. I found the Voltage - Continuous Input example VI and so long as I have a good clock source, I can measure at greater than 1khz. I'm going to edit my old posts to avoid spreading this misinformation.

 

-edit-

Nevermind. I can't edit them because they are too old. That's a pretty silly feature to the forum.

0 Kudos
Message 8 of 15
(4,035 Views)

@NClark wrote:

Nevermind. I can't edit them because they are too old. That's a pretty silly feature to the forum.


Not a silly feature.  It would be risky for someone to say one thing in a message and have a whole thread develop around that, then they go and edit their message to something completely different or completely opposite to confuse people.

0 Kudos
Message 9 of 15
(4,028 Views)

Ok. Sorry for gubbing up your post, but this problem does interest me. For your buffered counter, I think I've found an example that might interest you. Can you look at "Counter (Buffered) - Continuous Output.vi" Its within the example programs that ship with LabVIEW.

0 Kudos
Message 10 of 15
(4,025 Views)