In the late 70s, I had a job servicing line printers for a number of clients where we installed office automation (before PCs and desktop printers). I had my clients well trained to keep their hands off equipment that was not working to allow me to repair it before things got worse.
One day, I got a internal call from the accounting dept that their printer was on the blink and needed me to repair it. After a short diagnosis, I discovered that one of the control boards was malfunctioning.
The printer was designed with 132 printer positions for each line and a solenoid driven hammer for each position that hit a letter on a chain as it passed in front of the paper. The solenoids drew 1.5 A for a hundred milliseconds. The driver circuits drew so much power that they had to be spaced out on to 13 different cards to be cooled properly.
Well this day, after I pulled the faulty control card out, I lifted the lid of the printer and opened the printer gate to show that it was out of order. I took the control card down to the shop and spent 5 minutes soldering in a chip. As I walked back to the printer room I heard screaming and smelled smoke.
One of the accountants had closed the printer gate and started to print a report! Without the control card, all the drivers started firing simultaneously and continuously. They got so hot, the cards actually burst into flames. Fortunately once I pulled the power plug, the flames died out quickly.
But I had half the company parading through the accounting department for the next hour asking what the stink - literally - was. Fortunately, it was easy to blame the accountant for messing with equipment under repair. There were always war stories being told through out the company about client screw-ups so when it happened in-house, everyone could relate.
But we were always short on spare driver cards after that.
As Freshmen at San Jose State University in the late 70's, we did a similar prank with our SysAdmin's DEC printer located in his locked office adjacent to the huge engineering computer lab. We fed it one linefeed every minute, starting late Friday afternoon. By Monday morning, he could not open the door to his office due to the reams of paper that had relocated themselves from the box to the floor..Kids!
In the early 70's I was a summer student at Mizzou, writing an assembler in FORTRAN. I'd submit my cards and get my line printer output later. The printer was an IBM behemoth with a housing to keep the noise down, which would open automatically when the paper ran out. I got friendly with the computer operators, who informed me that there was no way to open the printer from a program. I took that as a challenge and realized that if you could simulate a paper out situation, it would open up. A few thousand overprints of a single line, followed by a page feed was sufficient to cut the paper and open the housing. We all enjoyed it until other students caught wind of the trick and started doing it. What I didn't realize was that the ribbon also didn't advance when you did that, and that we were also more or less cutting these very expensive ribbons. We were soon encouraged to stop submitting those jobs!
One of my co-workers described the prank they used to pull on the secretary at a previous job just after grad from high school. They would sometimes solder a small electrolytic capacitor across the AC in her IBM Selectric typewriter. Poor woman never knew when her typewriter would go BANG when she turned the power on. Apparently the cap protected the fuse by blowing open first.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.