rpm sensor

[han_5583]

Hi All,

Currently I'm doing a project on RPM sensor connecting to Labview. My RPM sensor uses IR transmitter/receiver. When the motor turns in front of the IR transmitter receiver, the IR light will be reflected back and the circuit will have an increase of voltage from 1.8V to 3.2V. I'm planning to connect this output voltage to the Labview via the digital input, but I'm having problem as how to do the programming in Labview to calculate the rpm of the motor.

Appreciate if anybody can help me on this.

Thanks

Amy Tan

[Norm Kirchner]

I think first you must let us know what kind of hardware you're working with.

Eventually, you'll treat the DIO as a counter input

then you'll merely do a pulses over time elapsed measurement and translate 1 pulse into the fraction of rotations

The big trick for you will be to get the system HW setup and getting the counter info.

The equations are rudimentary.

[mross]

QUOTE (han_5583 @ Jul 16 2008, 09:41 AM)

Hi All,

Currently I'm doing a project on RPM sensor connecting to Labview. My RPM sensor uses IR transmitter/receiver. When the motor turns in front of the IR transmitter receiver, the IR light will be reflected back and the circuit will have an increase of voltage from 1.8V to 3.2V. I'm planning to connect this output voltage to the Labview via the digital input, but I'm having problem as how to do the programming in Labview to calculate the rpm of the motor.

Appreciate if anybody can help me on this.

Thanks

Amy Tan

You can use a counter to measure the time period between pulses. There are examples on how to do period measurement with counters.

OR

You can acquire the analog voltage and measure the time between the pulses the sensor produces. This is normal data acquisition and you should first consider a buffered acquisition not continuous. You can repeat the buffered acquisitions to produce a quasi continuous output of RPM.

The conversion from time in milliseconds to RPM is fairly simple.

(X milliseconds / time between falling signals) * (1 minute / 60 000 milliseconds) * [(time /rev) / (time between rising signals)] =

X minutes / rev

1/X = RPM

If you use the counter method the falling edges are much less prone to noise problems.

Mike

[crelf]

QUOTE (han_5583 @ Jul 16 2008, 09:41 AM)

My RPM sensor uses IR transmitter/receiver. When the motor turns in front of the IR transmitter receiver, the IR light will be reflected back and the circuit will have an increase of voltage from 1.8V to 3.2V.

That's not really an RPM sensor - it's a rotary encoder (try google that). The data you get back can be converted into RPM very easily - have a look at counter/timer examples in LabVIEW (you want to do a frequency measurement). Above all - remember not to violate Nyqist (try another google on that).

EDIT: Looks like Mike's given you a lot of info to work with :thumbup:

QUOTE (mross @ Jul 16 2008, 10:17 AM)

You can use a counter to measure the time period between pulses.

[AnalogKid2DigitalMan]

You may need to condition your signal if using a TTL digital or counter input. 1.8V level is sort of a gray area between where a logic low and high is defined. Suggest you look at the specs of your DAQ card to see if 1.8V will qualify as a logic low.

[mross]

QUOTE (AnalogKid2DigitalMan @ Jul 16 2008, 02:25 PM)

You may need to condition your signal if using a TTL digital or counter input. 1.8V level is sort of a gray area between where a logic low and high is defined. Suggest you look at the specs of your DAQ card to see if 1.8V will qualify as a logic low.

Oops, I missed that. The TTL spec will only call it low below 0.8V. And only call it high above 2.5 (I think). My experience is the ni counters are exeactly to the spec so 1.8V wil NOT be seen as a low signal.

I would make a threshhold detector of a basic op amp comparator operating between 0V and 5V rails.

Set Vref to the voltage of the signal above which you want to the output to be high and below which you want the output off - for example make Vref 2.5 volts.

The comparator will put the high rail on the output above 2.5V and it will be ground below 2.5V for a 50% threshold:

50% * (3.2 - 1.8) + 1.8 = 2.5V.

Sorry, if you are an EE and already know this by heart.

Mike

[mross]

I just read this snippet in a little noise reduction article from ni:

http://zone.ni.com/devzone/cda/pub/p/id/26...amp;metc=mtpsh3

"For industrial applications, TTL has the inherent disadvantage of small noise margins. With high- and low-logic levels of 2.0 V and 0.8 V, respectively, [TTL has] little room for error. For example, the low-level noise margin for a TTL input is 0.3 V (the difference between 0.8 V, the maximum low-level TTL input, and 0.5 V, the maximum low-level TTL output). Any noise coupled to the digital signal in excess of 0.3 V may shift the voltage into the undefined region between 0.8 V and 2.0 V. Here, the behavior of the digital input is uncertain and may produce incorrect values."

In this case we are talking about applying an analog signal to a digital input which is not always a bad idea if the levels are in spec, but signal conditioning is good insurance against errors that would be hard to notice.

The op amp comparator could be between 24V and 0V rails as well as between 5V and 0V. Of course you need a DIO board that has 24V digital IO to make it useful, but it is the way to go in a noisy environment. You would want to make very certain there is no confounding noise on the IR sensor output to the op amp.

Mike

[han_5583]

QUOTE (mross @ Jul 16 2008, 02:17 PM)

You can use a counter to measure the time period between pulses. There are examples on how to do period measurement with counters.

OR

You can acquire the analog voltage and measure the time between the pulses the sensor produces. This is normal data acquisition and you should first consider a buffered acquisition not continuous. You can repeat the buffered acquisitions to produce a quasi continuous output of RPM.

The conversion from time in milliseconds to RPM is fairly simple.

(X milliseconds / time between falling signals) * (1 minute / 60 000 milliseconds) * [(time /rev) / (time between rising signals)] =

X minutes / rev

1/X = RPM

If you use the counter method the falling edges are much less prone to noise problems.

Mike

Hi Mike,

Thanks for your advice. Actually I do plan to use the analog voltage, but I'm not sure my DAQ (USB-6008) is a buffered DAQ. Do you have any example on how to use the input voltage for the counter? I was hoping to measure how many pulse within a minute but I'm not sure how to do that.

Thanks in advance

[mross]

QUOTE (han_5583 @ Jul 20 2008, 05:40 AM)

Hi Mike,

Thanks for your advice. Actually I do plan to use the analog voltage, but I'm not sure my DAQ (USB-6008) is a buffered DAQ. Do you have any example on how to use the input voltage for the counter? I was hoping to measure how many pulse within a minute but I'm not sure how to do that.

Thanks in advance

Buffered versus continuous is a software option - depends on the example you start with.

I believe that all NI DAQ is buffered, if you want it. You do not need to DO anything to use buffered DAQ beyond using example code that accesses this function. The DAQ hardware has its own private memory on board that is the buffer. The PC is not involved in the buffering and buffering is transparent to you.

With a buffered acquisition, when you press the run button the DAQ card begins reading and temporarily storing the information in a circular buffer. When the buffer is full the new data overwrites the old. This continues until the VI is stopped. When you "Start" the acquisition, the data already filling the buffer is output to the arrays and other processing software of the virtual instrument. You can "Stop" and re-"Start" the acquisition, but in reality all you are starting and stopping is the use of the data in the buffer. The buffering of the data continues whether you use the data or not. You have to Close the acquisition to stop buffering. This background information is all low end function that you may not need to concern yourself with if example code does what you want.

You do not need to DO anything to use buffered DAQ beyond using example code that accesses the function.

You need to simply find an example that has the function you need and try it. Do not over think this. Go to Help/ Find Examples.

If you look for information about buffering you won't find much. That is because you are not supposed to worry about it. The common concerns are only at a higher level, like how big should the buffer be, is the buffer keeping up, and so on. You can easily skip over this at the start.

The main distinction between continuous and buffered acquisition is performance. Buffered is better. When you use a continuous acquisition you force the software to leave undefined and open for increase the amount of memory it has allocated (there is a data array of unknown size that the program must be prepared to increase in size). With a buffered acquisition the memory is fixed and things can be more efficient. Generally, if all you want to do is watch pretty squiggles on screen that you react to at human speed, then continuous acquisition is fine. If you have computation and analysis to preform on the data, then you should limit the number of samples and use a buffered acquisition. You can use a large size and there is no great penalty. Acquiring the data in discrete blocks and processing it afterward is often best.

In your case you need to count waves over a period of time and convert the result to RPM.

You need number of waves, the time period, and the number of wave per revolution.

Post processing an array is the simplest way to do it.

You would run this repeatedly to get a constantly updating indicator on your front panel.

Take data for a second, calculate the RPM, do it again and again.

Go find an example that seems to do the thing you want and try it.

First set up channels using the Measurment and Acquisition eXplorer (MAX) this way you can look at the data coming in before adding the complication of your own VI. This will save you some confusion. If you have a more current version of LabVIEW then go ahead and let MAX create tasks and use them.

Regarding counters. You should also explore the ni.com literature on counter use. Everything you need to use the counters is there. There will be examples appropriate for the USB-6008 the show you how to measure the period of an TTL square wave. If your wave goes below 0.3V and above 2.5V the counters may be able to read it even though it is a sine wave. If is not readable as TTL then you will have to condition it to TTL for it to be useful and reliable. When you have the period it is easily convered into RPM if you know the number of cycles per revolution.

BTW- it looks like you may be a student given the question and the hardware (which part of a student kit for classes in LabVIEW perograming). I am hesitant to spell out exactly what you should do since as a student you should be figuring this out your own. Also when communicating with LAVA for help, you should ALWAYS explore the example code and try to write something on your own to show us before asking advise. It really does not make sense for us to work harder at it than you do.

Mike