09-10-2010 04:20 PM
I am trying to measure the output of a shaft encoder to measure velocity/acceleration.
Any thoughts on what the most efficient way to do this would be? Using the counter/digital inputs is out of the question since they acquire only about 1kHz rate at 100samples/reading that gives me readings every 0.1sec at best. I am looking for somewhere at or beyond readings every 0.03sec.
Right now I am trying to get what I want from analog input using the Single Tone VI to determine the frequency. Using 48kHz sample rate and 800 samples for each tone finder calcuation gives me a velocity data point 60 times per second (60Hz). So anyhow is there a more programatically efficient method of getting the frequency than the Single Tone VI? I am ranging from around 80Hz to 4000Hz frequencies from the shaft encoder.
The reason I need improved efficiency is because I am using IMAQ USB to simultaneously acquire from my USB camera to syncronize with the calculated velocity readings. 60Hz is the goal since I would like to run my camera at 60fps, although 30fps coupled with readings at 30Hz would be acceptable as well. Right now I am only capturing around 15fps though probably because my while loop is slowed down due to the calculation. I figure this since I have other programs running with an identical structure (simultaneus load cell readings and 60fps video) with no problems and at a sampling rate of 1kHz!
Thanks for any help. I'll post more details later and perhaps my code so far.
09-13-2010 10:28 AM
Hi elixirnova,
If you feel like the Single Tone VI is slowing down your other code, perhaps you can put this is a parallel while loop so that the Vision Acquisiton can run at optimal speed. Also, I am not sure how your analog input setup looks, but here is an example of how to use analog input to work as a counter input. Also, here is code that performs 2 edge analog separation on two seperate analog input lines. I fully realize that this is not what you are looking for, but it uses similar logic. It scans through an analog array and looks for a certain value and then looks for the next rise on the second line. It then reports back the time between each pulse.
The frequency measurement performs the same task continuously. You can then take the time between each counter pulse to calculate the frequency. I am not certain that this will be more efficient, but it would work as well.
Best,
09-30-2010 10:42 AM
I really should post the code... but here is where I'm at. One method that I found works at 30Hz (which gives one data point per frame in 30fps mode of my camera) is to just index the AI waveform collected with each "Image" frame in my while loop. Then I just use the Tone VI to detect frequency of each indexed waveform when saving to my video/data file.
Of course more data points is always better this is giving what I am wanting for now. Only problem is when derriving an acceleration graph I am obviously down to 15Hz which only gives me one data point every 2 camera frames. So I'm thinking of just dividing each indexed waveform that I aquire at 30Hz in half so I can have two velocity data points per video frame and would then have one acceleration data point per frame.
The limiting factor when I run at 60fps video is that I am not able to run my continuous AI channel beyond ~2000Hz since I get some memory error saying pretty much it is overwriting data or something? Can't remember too well. In 30fps mode I have no problem acquiring at 48kHz which is the max of the USB 6009, although I think I could get by with around 24kHz or even slightly lower if nessicary.
Maybe I can post code sometime later today if I remember!
10-01-2010 04:25 PM
A good thing to keep in mind is to increase the number of samples per channel in your task if you increases your sampling rate. This will help to empty the buffer to avoid the error you are receiving. Here is a KnowledgeBase article that discusses this as well.
Best,
10-02-2010 11:57 PM
Thanks, that should be a big help. Here is some clips of my code. The snippet of 30fps VI works fine, the 60fps adaptation is what I need to improve still. I am thinking I'll try parallel while loops tomorrow as well as the suggestion on samples per channel to keep the buffer freed up.
10-04-2010 09:42 AM
Sounds great. Let us know how it turns out.
Best,