:?: Hi, I'm new to the forum. Can anyone help with a circuit of a digital read out (LED) tachometer, optically or magnetically driven. I want to measure the spndle speed of a milling machine with a range of 10 to 2000 rpm. I can pickup the pulses from the top of a pulley attached to the spindle. Many thanks

 

The easiest way is to use a single microcontroller to both acquire the pulses and drive the 7 segment displays (probably multiplex them). You can detect the rotation either optically or using a hall effect sensor and a magnet attached to your spindle. You measure the frequency of the rotation by measuring the time it takes to rotate 1x around and then just do the math to find it in RPM. You might want to average the last n measures or something to get a nice display. I would suggest a PIC or Atmel AVR as both can drive the display directly and have the input capture function.

 

Hi Crust

Thanks for your reply. I don't know much about the devices you mention, could you give me a bit more information please i.e. device numbers etc and I can then get the data sheets.

 

AVR's are awesome visit www.avrfreaks.org for more info than you could ever imagine on them!

__________________
A rectangular bear is just a polar bear after a coordinate transform. -- I dunno who.
A recent study shows that research causes cancer in rats. -- I dunno who said that one either.

 

Well, basically the idea is that upon each rotation, your micro (which is effectively a tiny computer with everything built in) gets a pulse. It has a very accurate timer inside. This allows it to measure the time between pulses and thus compute the frequency. At that point getting RPM is simple. Depending on how you acquire the rotation signal, you might have to do some signal conditioning before presenting the signal to the micro.

I did a simulation for another post on this board that shows the noisy tachometer output of a motor which is then conditioned and squared up to provide a very usable input to the micro. In fact, I have used that exact method before and found it to work quite well. Here is a link to the other thread which contains my plot.

http://www.electro-tech-online.com/v...569&highlight=

 

To assist you more, can you give us an idea of how you are measuring the rotation of your object (for instance, does it have a tachometer coil built in, does it output pulse/revolution or something).

I would use a set of common cathode displays and general purpose NPN transistors to multiplex between them. For a micro I would use an Atmel AVR, perhaps a AT90S2313 (which might be end-of-lifed, but there are similar parts). The documentation is very good and you can use the freely available GCC. There is a libc that supports many of the peripherals on the device. If the signal is not clean, you will need to condition the input signal (which is what the plot I showed was doing).

 

I have a question. Calculating RPMs from rotation time requires a reciprocal operation (1/T). Is it difficult to perform divide operations with micros that don't have divide instructions? Are there "canned" routines or algorithms available that others have developed? If not, would a lookup table for this purpose be feasible with a microcontroller?
Of course, it's simpler to measure the number of rotations in a fixed time period, but at low RPMs this could get tedious, and wouldn't be practical if the speed is changing even modestly fast.

 

Hello Ron, I'll try to answer each question

There are a couple of approaches, many will use a piecewise linear approach, but I think that is not a good impl, b/c it requires quite a bit of memory. Another approach is to use a software based divide algorithm (which can take many cycles).

Yes, in fact there is a motorola data sheet that explains how to convert period to frequency using the FDIV instruction which was specific (as I recall) to the 68HC11. It is basically, a divide which takes the numerator and leftshifts it by 16 before dividing by the denominator. It was still a relatively involved routine.

Agreed, esp in a processor like the AVR which allows you to interface one of its pins to the counter. The difficulty with this approach is at low speed (as you mentioned) it is hard to tell the difference between slow and no motion. In one system I designed, the micro used a type C PID loop to control the motor speed, it also had a digital readout for the speed. I cannot remember exactly, but I seem to recall that the control loop executed at about 2kHz, but I only updated the display 10/sec or something like that as long as the speed changed by some threshold. I think that you can probably use the counter in many applications. Even a jet engine spins at around 200,000 RPM or less and that translates to less than 4kHz -- well within the measurement limit of a microcontroller.

 

So, bottom line - is it practical to measure 10 RPM (one revolution in 6 seconds) to 2000 RPM (33 rev/sec) with an AVR or PIC or Basic Stamp? A 1 one minute sampling interval would only give you +/- 1 RPM resolution at 10 RPM. I'm assuming none of these micros have a DIV opcode like the 68HC11. Is a software divide algorithm practical for 2000 RPM? Or should Pearce be using a 68HC11?

 

hope this can help
http://4crawler.cruiserpages.com/Die...ml#TachInstall

 

Measuring 10RPM is difficult since ideally, you dont want your controller to have to wait 6 seconds between adjustments. The method that we use is an optical encoder on our motor shaft (ours is an air bearing linear drive, but the same principle applies). The particular encoder I use is 100 "pulses per revolution" So that turns a 10RPM into 1000 RPM, you would get a pulse about every 60ms. Also, on most of the drives with integrated transmissions I have used, when a tachometer is present, it is always measured at the input shaft speed rather than the output speed (probably for this very reason). There are not too many native low speed motors because their construction is difficult (if I understand correctly).

When using PICs or AVRs (which I would suggest), I woulse use the pulse counting in a certain window of time technique. In this case, a simple multiply is all that is needed to compute frequency. The tricky part is during rapid changes in acceleration which result in rapid changes to rotational velocity. In that case, the count may overflow or underflow and you need to adjust the sampling window accordingly. To avoid jitter, you can always average the last n windows (effectively a DC lowpass filter). I would setup my control loop for the minimum speed, not including 0, (longtest time between pulses), so that I would not have to dynamically adjust kp,ki,kd during operation.

The FDIV method in 6811 works great, it is just you get much better performance with less hardware in a pic or avr system, which translates to less problems and less money.