Encoder Frequency to RPM

[Z_Squared42]

Hey people,

Im working on a project that involves testing a dc motor. One of the functions in this program is to calculate the speed at which the motor is rotating. I know how to convert from counter frequency to rpm, but my issue lies with the frequency I get from my encoder. I am using  CI Freq daqmx create channel wired to an implicit daqmx timing function. When I run my VI I notice the the frequency consistently drops to 0 every so often which messes with the data. I have my project attached, the specific subvi this occurs in is the measure motor speed.vi. Any feedback would be much appreciated. Thank you!

-Zachariah

[Hooovahh]

Well an easy solution would be to hold the last value for X number of reads incase it drops out.

If I had to guess I would say that it is possible that you are sampling so fast, and your edges come so slow, that you might ask the counter "How many edges have you seen"  It will reply with 2, which may mean 100RPM.  Then if you ask it again "how many edges have you seen since I last asked you"  It may say 0 because you just asked, and no new edges have been seen.  This would mean 0RPM.

So you can sample less often, or add code to hold values, or run faster.  That is if this is the problem.  If you run the motor slower you may see these drop outs more often.

[Z_Squared42]

I appreciate your response, what do you mean/how do you hold the last value? I'm also dealing with spikes of high frequency as well. I just cant seem to get it to consistently read accurately.

[Z_Squared42]

Heres a snippet of the particular part code in which I am experiencing problems with a spike in frequency...

[Hooovahh]

---

@Z_Squared42 wrote:

Heres a snippet of the particular part code in which I am experiencing problems with a spike in frequency...

---

This is not a snippet is is a screenshot.  It is a static picture that like any other image, where a snippet is a static image with a LabVIEW VI embedded in it so others can open your code.

http://www.ni.com/white-paper/9330/en/

With that out of the way you could use a feedback node in that VI, or wrap it in a while loop that had a TRUE wired to it to turn it into a Functional Global.  Then data can be stored in the uninitialized shift register like the previous good value.  If you get a value you suspect is bad just use the last good value.  You don't want to do this forever of course, if you get several bad values in a row you need to assume the value is actually bad so you'll need code to know how many bad reads is actually a bad reading.  In your case getting two bad readings in a row maybe good enough to say the signal is bad.

EDIT:  Also this maybe a band-aid for a much bigger issue.  You mention having trouble finding a good reading and a larger issue might be in your setup.