Measuring Motor frequency with counter.

[GTpumps]

Ok I have a super simple VI measuring frequency from a motor that has a sensor giving a square wave connected to counter zero, Acquisition mode is "1 Sample (on demand)". This is all working fine however when I stop the motor the counter timeout error crashes the VI. If I set the timeout to -1 to disable the timeout then stop the motor the VI locks up (I guess it's waiting for a pulse) until the motor starts tuning again. I intend to add some motor control stuff later that's why it has the 100mS loop timer. How can I solve this issue so I can freely stop and start the motor and the VI will keep running? 

 

[ZYOng]

Don't use DAQ Assistant. Use the DAQmx API. See Learn 10 Functions in NI-DAQmx and Handle 80 Percent of Your Data Acquisition Applications

You can use the shipping example instead. Make sure you save it as your own file before modifying it.

Go to Help >> Find Example... >> Hardware Input and Output >> DAQmx >> Counter Input >> Counter - Read Pulse Width and Frequency (On Demand)

[GTpumps]

Thanks very much for the suggestion. However that example VI also crashes with a timeout error if you stop the motor. I can't believe it can be so difficult to do a simple real world frequency measurement. There must be a way to deal with the timeout error without crashing the VI otherwise what's the point?

[ZYOng]

What's your version of LabVIEW, NI-DAQmx driver and Windows?

I think there's something wrong with your driver. You might want to try reinstalling it.

[Bob_Schor]

Did you look at the Example VIs that ship with LabVIEW?  Won't the "Counter - Count Edges" do what you want?  It basically has a loop that runs with whatever Loop Time you set and simply keeps track of how many Edges have occurred.  Get the Count just before you start whatever you want to measure, get the Count during, and after, and a simple subtraction will give you "# Counts During" or "# Counts Total".  If you "stop the motor", the Counter Loop won't have anything to count, presumably, but the # Counts will still be available -- a parallel loop that (temporarily) stops running because it needs a Count.  Hmm, now I'm wondering how you exit if the Counter doesn't have any counts pending (I don't happen to have any hardware to play with at the moment ...)

Bob Schor

[Kevin_Price]

1. setting timeout = -1 doesn't exactly *disable* the timeout, it sets the timeout to be infinite!  That's exactly why things hang when a timeout-like condition arises.

2. Counter-based freq measurement depends on incoming digital pulses.  When measuring encoder freq, you only get pulses while there's motion.  In the absence of new pulses, no new measurements can be made.

3. So the solution is to set an appropriate positive timeout value and then write code that *handles* the timeout errors you can *expect* to get when motion has stopped.  A timeout error doesn't have to be treated as fatal.  In apps like yours, it's simply information you can respond to.

-Kevin P

[JÞB]

Thank you Kevin!  Timeout simply means no count occurred. 

Now for the math instruction.  With your timeout set to 100mSec your frequency resolution is @10 Hz.  That is probably not ideal!  So, you need to DECREASE the timeout value until you get the resolution you need.  YES! You actually NEED to get more timeout errors.  Let's assume your motor is expecting to run at 8Hz.  And you want 2Hz resolution at 100mSec/sample %20 of your readings timeout so over any 500mSec period you get 4 counts and one timeout. You might get 3 or 5 but, your resolution is 2Hz. If you want more resolution 🤔 Decrease the timeout to 10mSec and you would find that instead of 4 counts every 5 readings you might get 38 or 41 counts every 50 readings and the rest timeouts or 7.6Hz(38 counts/ 500mSec) or 8.2Hz(41 counts/500mSec) for 0.2Hz resolution and you'll get 0.02Hz resolution at 1mSec timeout over 500mSec of readings.

[Kevin_Price]

Sorry Jay, I'm gonna have to do a little math destruction on your math instruction.

---

Now for the math instruction.  With your timeout set to 100mSec your frequency resolution is @10 Hz.

This would be true if the timeout value were the method for measuring the time between motor pulses.  But that's not what's going on here.  The counter hardware is being used to measure the frequency intervals directly -- and that's the reason a lack of pulses causes a timeout.  If the OP were counting edges in hardware and measuring time in software, there'd be no timeout to worry about.

Let's assume your motor is expecting to run at 8Hz.  And you want 2Hz resolution at 100mSec/sample %20 of your readings timeout so over any 500mSec period you get 4 counts and one timeout. You might get 3 or 5 but, your resolution is 2Hz.

Same issue here as previous, treating it like a hardware edge count divided by a software time interval.

If you want more resolution 🤔 Decrease the timeout to 10mSec and you would find that instead of 4 counts every 5 readings you might get 38 or 41 counts every 50 readings and the rest timeouts or 7.6Hz(38 counts/ 500mSec) or 8.2Hz(41 counts/500mSec) for 0.2Hz resolution and you'll get 0.02Hz resolution at 1mSec timeout over 500mSec of readings.

Here's the math destruction part.  8 Hz means 1 count per 125 msec.  IOW, 4 counts per 500 msec regardless of timeout value or sample rate.  50 readings at 10 Hz does require 500 msec, but one should still expect the count to increment only 4 times (+/- 1).

-Kevin P

[GTpumps · Accepted solution]

Hi Kevin,

thanks for your reply. You are exactly correct then why don't they include how to handle the error in any of the counter/timer examples, seems bizarre? NI must think the world is in perpetual motion lol.

It took me a long time searching on this forum to find a solution. This works.

[JÞB]

At Kevin

Whoops, I mistook the setup for count edges in consecutive gated periods.

Edit deleted after coffee... made the same dang mistake again!