Trevor said:
I'm not designing it, I was after a pointer to something already made
to plug into or download the count to a PC.
"Ready made" is usually application-specific and may be
more trouble to adapt than it's worth.
It's not my project, I'm helping a friend.
Aha. What's the friend being paid? ;>)
I didn't realise I had to pay to ask a question here, I'm willing to
offer 20% of naff-all but will haggle on the percentage if you want.
Questions are free but answers may only be worth what you
pay for them.
OK, now that the terms are settled, I'll echo the Wiz's
response about parameters; vague questions usually get vague
answers. The more specific you get, the less effort the
design involves. But since you already knew that (or you
wouldn't have asked for help), I'll be fairly generic and
suggest the old webcam/software trick because you can handle
all sorts of parameter variations that way.
IMNSHO the really big question you ought to ask your
friend is "What does the PC want to see as input?". IOW, how
simple can you make the detector and still satisfy his
requirements? If all the crates (and spacing, etc.) are
identical and ambient lighting isn't reliable, beam-breaking
may be the simplest solution that fits his bill. Also, is
the PC expected to do (and capable of) any processing, or
can it only log counts every so often in between other
tasks? A dumb serial or parallel port (or USB) interface can
be slapped together easily from say mouse and disk drive
parts for the former situation, but if preprocessing's
involved, adding a barebones DOS-based XT PC that does all
the heavy lifting and supplies reports to the main unit on
request might actually be simpler and cheaper than a custom
interface. That's what I was reminded of from my days at a
systems design house here in PHX that used QNIX-based
'puters to run process control for industrial users.
Mark L. Fergerson