Searching \ for 'Revolution counting' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/timers.htm?key=count
Search entire site for: 'Revolution counting'.

Truncated match.
PICList Thread
'Revolution counting'
1999\08\12@063727 by dikelloway

flavicon
face
Hello list,

I am working on a project to count the revolutions on a rotating
wheel/disc.The sensor is going to be an optically coupled interrupter
module.

I intend using the 16F84 pic to convert the pulses from the opto
interrupter to a velocity figure and distance travelled for display on
an LCD readout.

If anybody has some info on this type of circuitrysoftware, I would be
most appreciative.


Regards

Dee

1999\08\13@101206 by Andrew Russell Morris

flavicon
face
At 08:22 PM 8/12/99 +1000, you wrote:
>Hello list,
>
>I am working on a project to count the revolutions on a rotating
>wheel/disc.The sensor is going to be an optically coupled interrupter
>module.
>
>I intend using the 16F84 pic to convert the pulses from the opto
>interrupter to a velocity figure and distance travelled for display on
>an LCD readout.
>
>If anybody has some info on this type of circuitrysoftware, I would be
>most appreciative.
>
>
>Regards
>
>Dee
>
I have done this very thing, but since I have a disclosure agreement with
my employer who now owns the code, I can't send you the code. I will,
however try to point you in the right direction. First of all, if you are
using a dc (brush) motor in your design, you will probably need to use
synchronous detection in your software to avoid motor noise interference. I
wrote a routine which would read the photodetector, incrementing a counter
when the emitter LED is on and decrementing the counter when the emitting
LED is off. You don't necessarily need to pulse the emitter with a square
wave (unless your photodetector amplifier is capacitively or unductively
coupled), but you need to do an equal number of samples when the emitter is
on and off. Any signal that is noise or just not synchronous to the emitted
signal will result in no significant change in the counter number from the
preset value. Preset the counter to 128 or some other number that will not
over or under flow. That complicates the code. For maximum noise immunity,
I set my trigger threshold to half the total number of counts. In other
words, consider the output high when the counter (I call an integrator)
reaches the preset count plus half the sample count. You shouldn't need a
lot of samples for motor noise. 20 samples worked for me.

When a high is detected from the synchronous detector, you would increment
another counter for distance traveled. Divide that by time for velocity.


I had problems with sunlight and had to capacitor couple the photodetector
and use a low value pullup resistor (in the detector) to prevent
saturation. I used about 20mA of emitter current. I also had to amplify the
photodetector output. I used my own discrete design, since I could not find
an opamp that met my speed, power and cost goals. Sometimes IC's are not
the cheapest solution.

I don't have a lot of time, right now, but I hope this helps.

Regards,

Andrew R. Morris

1999\08\13@104253 by Wagner Lipnharski

picon face
> >I am working on a project to count the revolutions on a rotating
> >wheel/disc.The sensor is going to be an optically coupled interrupter
> >module.
> >
> >I intend using the 16F84 pic to convert the pulses from the opto
> >interrupter to a velocity figure and distance travelled for display on
> >an LCD readout.
> >
> >If anybody has some info on this type of circuitrysoftware, I would be
> >most appreciative.

My two cents,

About calibration;
------------------
Make the software in some way that you can install a jumper or via
keyboard start a calibration process. This routine will zero the counter
and count pulses until you press that key or remove the jumper, after
travelling a very known and exact distance. The software then will
calculate by itself the relation between distance/count and store it
into an eeprom. That same information would be used later to display the
travelled distance, by simply multiplying that factor by the counted
pulses. This is easier than go into the "rodeo" with wheels sizes and
other factors, and allows the user to recalibrate the unit at any time.

About Pulse Counting:
---------------------
A debouncing routine is easier to do for optical devices.  Just
calculate what is the shortest pulse the sensor can generate, in other
words, what is the highest rpm of the wheel, the window size of the
sensor and so on. Now calculate the same for blocked sensor timming.
Suppose you find out this minimum pulse width to be 2ms and the minimum
blocked sensor time is 4ms. As soon the opto disc sensor receives light,
this pulse starts your interrupt routine, the software will read that
pin during 1.5 ms as fast as possible and can not reads other level than
the valid "lighted sensor". If this happens, than your software will
count one pulse and then will enter in a routine to measure the blocked
pulse for at least 3ms... then you will be sure you counted it right.

1999\08\13@161156 by Dan Creagan

flavicon
face
Wagner,

You mention

(snip)
>A debouncing routine is easier to do for optical devices.   (snip)

What would cause bounce in the kind of setup described in this thread?  I
currently have a test bench running at 30 rpm/50 spokes per revolution and I
don't believe that bounce comes into it (not yet, anyway). I would be
interested in the kind of situation that would cause it - if nothing more
than to know it when I see it.

Dan

1999\08\13@181121 by Wagner Lipnharski
picon face
Between the light emitter (led) and the receiver (photo-something
sensor) there is a disk with holes or slots, or a finger or some other
mechanical object that will block or allow the emitter light to hit the
receiver. The photo-sensors have a measurable sensitive surface area.
Even in a very high speed operation, the block element does not expose
or block the emitter light at once, light or dark will travels over the
sensor surface for some period of time, while it is changing from one to
another. Also, the light emitter is not a coerent light (laser), so it
projects a difused shadow of the hole or slot edge over the sensor. As
the photo-sensors are basically analog components with some kind of high
gain responsiveness, during the time that the light is travelling from 0
to 15% (guess) of the sensor surface it is quite possible that the
sensor output shows some instability with noise or multiple pulses, or
even some kind of ramp to change from dark to light output level.  This
is one of the factors that can generate "electrical noise" at the sensor
output.  Of course good sensors and/or attached circuits can use schmidt
trigger circuits to reduce this effect, so you will never notice it.

The second reason for noise (and/or bounce) is related to machine
vibration (can vibrate the hole/slot edge in front of the sensor), or
even real EMI around the sensor wiring.  In machinary it is not rare to
install sensors far away from the main electronic boards, and a poor
dimensioned cable or shielding creates the same keyboard problems.
Bounce/noise in keyboard circuits is not only caused by the mechanical
bounce of the key contacts.  Lets understand that the word "bounce" can
be read as "electrical bounce" rather than mechanical. Today's metal and
mechanical enginering used at keys and contacts are a little bit better
than 20 years ago, except if you go for very cheap and "hard contact"
keys and switches.    

The "electric + mechanical bounce" is used in heavy motion sensors as
some sysmographs and others. The great instability caused at the middle
of the switching "curve knee" of some optical sensors (at very low
temperatures) is important to detect very tinny changes in the light
exposure (movement of the disk slot or hole).

Years ago I saw a synchronous motor control device that used a half disk
to block a LED light over two sensors. Each sensor is located exactly
180¡ from the other. So each sensor receives light during 180¡ of the
shaft rotation. The LEDs are connected to AC (60Hz) voltage source, so
the sensors receive pulses during 180¡.  To control the motor speed, the
microcontroller counts quantity of pulses from each sensor, instead the
traditional way of measuring timming between light slots. At the first
pulse at sensor "A", counter "B" value is validated and vice-versa. It
is a pretty nice idea, since the processor speed, time loops or precise
time base is not important, everything is tied to the 60Hz power lines.
To change motor speed, the microcontroller use different counting
references.  An intermitent speed variation problem was found to be an
out-of-spec photo-diode "knee curve". It caused multiple pulses when the
LED was increasing its light (AC power). It could be solved by several
ways, but a simple exchange of the diode solved the problem.

Dan Creagan wrote:
{Quote hidden}

1999\08\13@222901 by Dan Creagan

flavicon
face
I'm working on something similar (collaborating, actually).
This is not for a commercial product. It is early days,
and I'm learning quite a lot about what can go wrong.


The project is to do spoke counting (not revolution counting) on a wheel
pattern to get as high a degree of accuracy as possible (and within budget
... budget = money hidden from the wife).  The pattern is scanned with a
photo-reflector IC.

I built a small mockup and used a QRB1114QT-ND (DigiKey PN) on a 50 spoke
pattern. I limited the current of the emitter to about 15 ma. For
the output of the detector, I found that the pullup resistor value was
critical for stability and settled on a 47K resistor - this will vary quite
a lot depending on your hardware - just put a scope on the output of the
detector (while it is in circuit ) and adjust the value until you get a well
formed wave.  The output was filtered with a .1 ufd cap to stop ramp up and
down noise, sent
to a Schmitt trigger for conditioning and then to a 16F84 for counting.
Right now, samples are taken every 1 second and then displayed on the LCD.
The final product will have continuous sampling and feedback for speed and
direction control using differential steering.

The pattern disk must run true. For  the mockup, I used a slotted base and
let
the disk run in it.

Since this is limited budget stuff (amazing how much
more careful you are when it is your own money that's being spent :)), I
used
an Excel pie chart with alternating black and white spokes. The chart must
be printed with laser toner (ink jet ink doesn't work well with IR
detectors) so you must either print it on a laser printer or use an ink jet
and then Xerox it.

I've tested it at 15 and 30 RPM and it is now stable with tested run times
of 1 hour.  No noise issues with the mockup.

Wagner commented on the 'debounce' issue in this same thread. I checked the
ramp up/down of the photo detector with the cap in place and without it. The
difference is quite remarkable and I could see how it would cause problems
(now that Wagner pointed out where the noise could come from - I guess I had
already done something about that and not realized why).

Finally, the detector IC must not have a detection footprint bigger than the
spoke size of your pattern - this may be obvious, just mentioning it.

Dan


{Original Message removed}

1999\08\14@004316 by Ravi Pailoor

flavicon
face
part 0 608 bytes content-type:text/x-vcard; charset=us-ascii; name="vcard.vcf" (decoded 7bit)

> >
> I have done this very thing, but since I have a

[non ?] :-)  disclosure agreement with

> <snipped>

> my employer who now owns the code, I can't send you the code. I will,
> Regards,
>
> Andrew R. Morris

--
Website : http://business.vsnl.com/chiptech


Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ravi Pailoor
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: wonderland:vcard.vcf 5 (TEXT/CSOm) (0000B6CA)

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...