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
Reply to
Usual Suspect
Loading thread data ...

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

formatting link

Reply to
John Popelish

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
Reply to
Usual Suspect

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

Reply to
John Popelish

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.

Reply to
Nobody

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.

formatting link

Reply to
linnix

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

Reply to
Rich Grise

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
Reply to
Usual Suspect

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.

Reply to
Nobody

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
Reply to
Palindrome

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
Reply to
John Devereux

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.

Reply to
Nobody

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.

Reply to
Nobody

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
Reply to
John Devereux

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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

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

Reply to
MooseFET

--
Joe Leikhim K4SAT
"The RFI-EMI-GUY"©
 Click to see the full signature
Reply to
**THE-RFI-EMI-GUY**

On Wed, 08 Aug 2007 07:49:58 +0000, Usual Suspect wrote: [Rich Grise wrote:]

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

Reply to
Rich Grise

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
Reply to
Usual Suspect

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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.