I once worked at Eyedentify, a company that made retina scanners for biometric security. Manufacturing was starting to ramp up production, so a burning room was built to cook the scanners for reliability.
We decided to use a small paper cup with a simulated retina pattern over the binocular-like eyepiece. Pressing the sole front panel button invoked a "scan," which was a motor-driven, infrared, near-field optical radar.
They asked me to build some boxes that would simulate a key press about once every minute. The unit would then log transactions. I used a 555 timer IC to drive a small relay. After I built two boxes and was starting the third, I realized that the burn-in room could hold 10 or 15 units. I did not relish the thought of building that many widgets.
I thought about it and realized that what we were mostly trying to accomplish was to check optics. I talked to our firmware guru, Bill, and we thought the Motorola 68000 microprocessor had some room in its ROM for a hidden routine. I told Bill to call the key-pressed routine once a minute, and do a loop once an obscure key sequence was detected.
At the same company, we had several models of scanners. The sales folks had to change firmware sometimes to fit the application, which could be networked or standalone.
I had used a trick on my Icom R7000 radio where you replace the SRAM with a larger one at the add-on circuit to swizzle the upper address bits. This took my R7000 antenna from 100 channels to 3,200. Note that it is really convenient to have a PC interface -- otherwise it takes a long time to program.
I got the same EPROM 27256s and used the Data I/O to stack two-code versions in one chip. I ran the upper address line to a small switch on the rear panel. Now the sales crew could flip the switch and reboot, and the unit would work for the other model.
This entry was submitted by Steve Lindberg and edited by Rob Spiegel.
Steven Lindberg has loved electronics since got his first Weller soldering gun when he was 12. He has 35 years of experience in test, debug, and design. His personal lab is 950 sq. ft. room with 350 instruments, from femto amps to a 40V 70A Sorenson, DC to 20 Gig.
Tell us your experience in solving a knotty engineering problem. Send stories to Rob Spiegel for Sherlock Ohms.
So how did you attach the relay to the fixtures holding the scanners, so that it could physically execute the key press? And did you have to build those fixtures; I'm assuming not, since you were using the burn-in room anyway, prior to your time-saving auto-keypress solution.
You alreayd corrected the typo in the article (burning room? Where are those smoke detectors when you need them - or was this a device to identify firemen while they enter a building ;-)
I presume that the relay was the first installment of the test and not used as soon as the solution was found in adding test routines in the unit's own software that would automatically scan every minute, so they only had to place the cups with simulated retina, throw the hidden switch and there was no need to have something interact with the device to initiate the test.
I recall our automated test of mobility-enabled DECT base stations and terminals. Two base stations were installed at two sides of a room, toy train tracks were laid out between them, the train cars were stuffed with handsets that had a special version of their normal software, the added User Interface routines generated (and tallied) outgoing calls with random timing. After a night of testing you could read the tallies and compare with statistics from the Base Station to see how many calls were missed or dropped, while the terminals roamed between the base stations.
I can never get the software crew to add test routines to the "operational" software. They insist that this would require retesting the entire software, and they are right. Their policy is to program the test routines, run the tests, then re-program with the operational file. What iif a bug caused a jump to a non-existant address, wihch in you setup would suddenly exist?
@ Battar: Additional code certainly does increase the software V&V burden, but if architected properly they can actually make the SW team's work easier. In every instance where I've requested operational additions I architect them to be generalized tools that everyone can use for test and debug. Once implemented, I then work with the SW team to work these features into their V&V test plans and procedures. In the end, the additions have actually reduced the overall SW test load and have repeatedly streamlined the whole development process.
I originally thought the same thing as Battar. In stuff I used to work on, test routines were never kept in the main operational software. They changed the timing, for one. But that was in the old days when cycles weren't "free." I can see if you architected generalized tools, as you say, Chris, then adapted them for different applications right at the outset, the could "live" in the real code because they'd go thru the complete test and dev cycle like everything else.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 5
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
7 
