Maker Pro
Maker Pro

Counter/tachometer circuit?

U

Usual Suspect

Jan 1, 1970
0
Printing equipment such as sheet-fed presses refer to speed in
impressions-per-hour. I want to build a circuit that will display this number
on 5 LED digits.

The sensor will be a simple hall-effect or other sensor that is triggered up
to 4 times a second (maybe less than one, probably not more than 5).

It's a simple thing to start and stop a timer to calculate the period of the
print cycle, but how to convert that to a meaningful IPH figure? Is a look-up
table or maths done by microcontroller the only way? Or can some other means
be used?

I prefer the non-microcontroller solution, as I haven't yet broached the PIC
[used as generic term] world...

Thanks,
 
J

John Popelish

Jan 1, 1970
0
Usual said:
Printing equipment such as sheet-fed presses refer to speed in
impressions-per-hour. I want to build a circuit that will display this number
on 5 LED digits.

The sensor will be a simple hall-effect or other sensor that is triggered up
to 4 times a second (maybe less than one, probably not more than 5).

It's a simple thing to start and stop a timer to calculate the period of the
print cycle, but how to convert that to a meaningful IPH figure? Is a look-up
table or maths done by microcontroller the only way? Or can some other means
be used?

I prefer the non-microcontroller solution, as I haven't yet broached the PIC
[used as generic term] world...

The fast response method is to take the reciprocal of the
period between events and scale that to the desired units.

There are industrial displays made to do just that. I think
a common name for them is rate indicators. e.g.:
http://www.am.pepperl-fuchs.com/products/productsubfamily.jsp?division=FA&productsubfamily_id=1306
 
U

Usual Suspect

Jan 1, 1970
0
I'd like to see what's possible re. building my own circuit for this one
application.
The fast response method is to take the reciprocal of the
period between events and scale that to the desired units.

Is this approach possible without use of a custom uController? Or, for that
matter, what are the possible solutions, excluding the need for programming?

Thanks!
 
J

John Popelish

Jan 1, 1970
0
Usual said:
I'd like to see what's possible re. building my own circuit for this one
application.


Is this approach possible without use of a custom uController? Or, for that
matter, what are the possible solutions, excluding the need for programming?

Lots of things are possible that are not practical. The
simple way to compute rate is to count events during a
precise period, and display the count. But to get 5 digit
precision, you have to count 10^5 events, and that could
take a while, unless you add something like a gear tooth
pickup that gives you a couple digits of count per
revolution. You scale the units of the count by setting the
counting period appropriately. There are counter ICs
available that also drive displays. If you can't find them
with Google, I'll take a look and see what I can come up with.

The reciprocal method is definitely easier with the math
available through a microprocessor program. Analog or
digital reciprocals are a pain, especially near zero rate
(infinite period).
 
N

Nobody

Jan 1, 1970
0
I'd like to see what's possible re. building my own circuit for this one
application.


Is this approach possible without use of a custom uController?

Store a table of reciprocals in ROMs.
Or, for that matter, what are the possible solutions, excluding the need
for programming?

A *possible* solution is to multiply the impression frequency using a
phased locked loop and a divider. I don't know whether this would be
viable in practice; given the low base frequency, it may take a while
to re-synchronise if the frequency changes. You would definitely want a
proportional phase detector.
 
R

Rich Grise

Jan 1, 1970
0
Store a table of reciprocals in ROMs.


A *possible* solution is to multiply the impression frequency using a
phased locked loop and a divider. I don't know whether this would be
viable in practice; given the low base frequency, it may take a while
to re-synchronise if the frequency changes. You would definitely want a
proportional phase detector.

I saw a guy design an RPM readout that used 1 slot on the disk. He counted
milliseconds per rev. in one counter, used that number to preload another
counter, then divided some clock by it to give a readout directly in RPM.

Good Luck!
Rich
 
N

Nobody

Jan 1, 1970
0
You would need lots of supporting hardware for the ROM as well.

Huh?

Connect the output from the interval timer to the address pins, connect
the data pins to the BCD-to-7-segment decoders, hard-wire chip-select on.

Once programmed, a ROM containing 2^M N-bit words is just a combinatorial
logic chip with M inputs and N outputs.

I'm talking about traditional ROM/PROM/EPROM chips with non-multiplexed,
parallel address and data lines, not I2C ROMs or suchlike.
 
P

Palindrome

Jan 1, 1970
0
Nobody said:
Huh?

Connect the output from the interval timer to the address pins, connect
the data pins to the BCD-to-7-segment decoders, hard-wire chip-select on.

Once programmed, a ROM containing 2^M N-bit words is just a combinatorial
logic chip with M inputs and N outputs.

I'm talking about traditional ROM/PROM/EPROM chips with non-multiplexed,
parallel address and data lines, not I2C ROMs or suchlike.

I like it.
IIUC:

It would need one 128kx8 ROM for each of the 5 digits of the display,
all with parallel inputs, to get the resolution required.

Possibly what the poster has in mind is to reduce the ROM sizes by using
supporting hardware to carve big chunks out of the address map.
 
J

John Devereux

Jan 1, 1970
0
Palindrome said:
I like it.
IIUC:

It would need one 128kx8 ROM for each of the 5 digits of the display,
all with parallel inputs, to get the resolution required.

Possibly what the poster has in mind is to reduce the ROM sizes by
using supporting hardware to carve big chunks out of the address map.

Arghh! It's horrible :)

You could do the whole thing with an AVR and a MAX7219. Two chips vs a
board full of counters, bussed EPROMS and seven-segment decoders.

Best wire-wrap it, to complete the authentic 70's look :)
 
N

Nobody

Jan 1, 1970
0
I like it.
IIUC:

It would need one 128kx8 ROM for each of the 5 digits of the display,
all with parallel inputs, to get the resolution required.

That assumes that you're including the 7-segment decoding in the ROM. If
you use separate decoders, you only need 4 bits for each digit, so 5x4-bit
or 3x8-bit. The size depends upon the resolution of the timer.
Possibly what the poster has in mind is to reduce the ROM sizes by using
supporting hardware to carve big chunks out of the address map.

I'm not sure that there would be much point. The only real advantage of
ROMs is their simplicity; in most other regards, a microcontroller would
be a better choice.

Maybe he was thinking about scanning out the digits rather than generating
them in parallel.
 
N

Nobody

Jan 1, 1970
0
Arghh! It's horrible :)

You could do the whole thing with an AVR and a MAX7219. Two chips vs a
board full of counters, bussed EPROMS and seven-segment decoders.

Best wire-wrap it, to complete the authentic 70's look :)

70's? Most of my ROM-based prototyping was in the mid-late 80's.

Mostly because I had an EPROM programmer and a stack of EPROMs, but lacked
a PAL programmer. You can't copy WordWise/View/etc ROMs with a PAL
programmer.

Flash wasn't around then, and the "development" (i.e. re-programmable)
versions of single-chip microcontrollers cost a small fortune.
 
J

John Devereux

Jan 1, 1970
0
Nobody said:
70's? Most of my ROM-based prototyping was in the mid-late 80's.

Mostly because I had an EPROM programmer and a stack of EPROMs, but lacked
a PAL programmer. You can't copy WordWise/View/etc ROMs with a PAL
programmer.

Flash wasn't around then, and the "development" (i.e. re-programmable)
versions of single-chip microcontrollers cost a small fortune.

I actually designed the very thing the OP is looking for then (an
"items per hour" display. It used an 8748 (shudder). I had to build my
own programmer, and write my own assembler in BBC Basic. As well as
items per hour, it could display a total count and average production
rate. It also had switches for a multiplier to deal with multiple
items made per machine cycle.
 
S

Spehro Pefhany

Jan 1, 1970
0
Printing equipment such as sheet-fed presses refer to speed in
impressions-per-hour. I want to build a circuit that will display this number
on 5 LED digits.

The sensor will be a simple hall-effect or other sensor that is triggered up
to 4 times a second (maybe less than one, probably not more than 5).

It's a simple thing to start and stop a timer to calculate the period of the
print cycle, but how to convert that to a meaningful IPH figure? Is a look-up
table or maths done by microcontroller the only way? Or can some other means
be used?

I prefer the non-microcontroller solution, as I haven't yet broached the PIC
[used as generic term] world...

Thanks,

If you could live with 4 digits, we have a product that could be
modified to do that. That's way more resolution that is useful anyway
(you can't expect mechanical equipment to repeat within 10ppm).

Or, have a look around for totalizers/counters/etc. that offer
calculation functions. I bet there's something out there off-the-shelf
for a reasonable price compared to making one from scratch, even if
you need a fair number of them.

Best regards,
Spehro Pefhany
 
M

MooseFET

Jan 1, 1970
0
That assumes that you're including the 7-segment decoding in the ROM. If
you use separate decoders, you only need 4 bits for each digit, so 5x4-bit
or 3x8-bit. The size depends upon the resolution of the timer.

If you mux the display, you can fit it all in a single larger ROM.
You already have the oscillator and counter in the period measuring
part of the system.

I'm not sure that there would be much point. The only real advantage of
ROMs is their simplicity; in most other regards, a microcontroller would
be a better choice.

If you go with one of the variations of the 8051, the software is
about as simple as the software for making the contents of the
ROM(s).
 
T

**THE-RFI-EMI-GUY**

Jan 1, 1970
0
I have a Shimpo DT-5TG programmable panel mounted tachometer that will
do exactly what you want. Its new/old/stock (never used) $150. Includes
instructions.

Usual said:
Printing equipment such as sheet-fed presses refer to speed in
impressions-per-hour. I want to build a circuit that will display this number
on 5 LED digits.

The sensor will be a simple hall-effect or other sensor that is triggered up
to 4 times a second (maybe less than one, probably not more than 5).

It's a simple thing to start and stop a timer to calculate the period of the
print cycle, but how to convert that to a meaningful IPH figure? Is a look-up
table or maths done by microcontroller the only way? Or can some other means
be used?

I prefer the non-microcontroller solution, as I haven't yet broached the PIC
[used as generic term] world...

Thanks,

--
Joe Leikhim K4SAT
"The RFI-EMI-GUY"©

"Treason doth never prosper: what's the reason?
For if it prosper, none dare call it treason."

"Follow The Money" ;-P
 
R

Rich Grise

Jan 1, 1970
0
]
I think that's the kind of approach that was lurking in the shadows (or cob
webs) in the back of my mind.

I'll see how it percolates down (out?).

This has been bugging me since I saw that guy's design, sometime in the
early 1980's. The circuit was "simple", but "big" - i.e., he had something
like three banks of counters.

First, you'd have an ordinary start-stop counter to count some clock,
I used ms in my example, which is 1 KHz, but it could be anything, as long
as you know what it is.

Then, that gives you, say, millisecs per revolution.

So, I take that number and preload it into another counter, which
is clocked at, say, y Hz. So, now, y divided by millisecs per revolution
would give 1/y revolutions per millisecond, so if you want revolutions
per minute, y would be, what, 60 KHz? to scale it to RPM?

Hmmm... I guess it was just the two counter banks - the third row on
his schem. must have been the decoder/drivers.

Hmmmm... then somehow you've got to go from binary to BCD... Well, anyway,
have fun designing this klooge, and let us know what you come up with
either way, OK? :)

Cheers!
Rich
 
U

Usual Suspect

Jan 1, 1970
0
Or, have a look around for totalizers/counters/etc. that offer
calculation functions.

Many of these totalizers/counters have a scaling feature. For application as
a cycles-per-hour display, do I need a 3600x scale? ie, after each second of
measurement (at 3 hz sensor input), the display should read "10800".

Thanks,
 
S

Spehro Pefhany

Jan 1, 1970
0
Many of these totalizers/counters have a scaling feature. For application as
a cycles-per-hour display, do I need a 3600x scale? ie, after each second of
measurement (at 3 hz sensor input), the display should read "10800".

Thanks,

You'll have to read the manual carefully to see if they can do exactly
what you need.

Best regards,
Spehro Pefhany
 
U

Usual Suspect

Jan 1, 1970
0
You'll have to read the manual carefully to see if they can do exactly what
you need.

Yes, I frequently download user guides while researching a product.

But my question was more about whether I correctly understand the definition
of and need for "scaling" as applied to my case?

Thanks,
 
Top