Counter/tachometer circuit?

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,
--
Al, the usual


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Usual Suspect wrote:

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 &productsubfamily_id06
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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?
Thanks!
--
Al, the usual


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Usual Suspect wrote:

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).
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 07 Aug 2007 16:58:57 +0000, Usual Suspect wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Yes, a standard uController.

You would need lots of supporting hardware for the ROM as well.

Getting some 8 years old to do an FPGA.
http://www.eetimes.com/news/latest/showArticle.jhtml?articleID 1202710

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 07 Aug 2007 14:21:49 -0700, linnix wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Nobody wrote:

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.
--
Sue





Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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 :)
--

John Devereux

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 08 Aug 2007 10:00:22 +0100, John Devereux wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.
--

John Devereux

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Wed, 08 Aug 2007 08:35:26 +0000, Palindrome wrote:

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.

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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.

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).
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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?).
Thanks,
--
Al, the usual


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

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
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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,
--
Al, the usual


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

You'll have to read the manual carefully to see if they can do exactly what you need.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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,
--
Al, the usual


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

First you have to be sure you've got the number you want and not the reciprocal of the number you want, then you can worry about scaling. Only studying the manual or talking to a sales rep will help with that.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

OK. Thanks!
--
Al, the usual


Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.