| « Loopy Validation | CodeThatDocumentsItselfSoWellItDoesNotNeedComments » |
Craig Landrum grimaced, sucking air through his teeth, clenching his fists, and tightly shutting his eyes. It wasn’t so much the 300-pound robot that was stampeding full-speed towards him while rotating its menacing gripper arm, but more The Admiral, who was wide-eyed with fear and instinctually reaching for his sidearm. Cha-cha-cha-chunk. Craig peeked through his left eyelid to see that the robot had halted on its track, not less than two feet from them, and nearly tipped over before zipping away in the opposite direction. Needless to say, the demo didn’t go so well.
In spite of the seemingly hostile behavior, the robot that Craig was working with was not some sort of military killing machine on the verge of sentience. It was a Fichetrieve, an automated filing system manufactured by Lektriever that was designed to retrieve microfiche film from a room full of shelves and cabinets.
You see, long before we had gigabyte databases with millions of pages of records, there was microfiche: a small, 4”x6” sheet of film that miniaturized up to 98 printed pages. While microfiche vastly simplified traditional paper storage, maintaining a gigantic set of data was still no picnic. You’d need to have a vast assembly line of microfilm cameras, film developers, indexing stations, film trimmers, frame mounting units, fiche storage units, and query terminals just to get started. And then there’s the whole team of people needed to run the line.
Some organizations, such as the Navy Military Personnel Command, needed to take things a step further. Because they’re responsible for maintaining the Navy’s active duty and retired personnel records, they needed a fiche retrieval system. And that’s where the Fichetrieve came in.
Fichetrieve units were incredible automated filing cabinets, and made for a very impressive demonstration to visitors. The end of each unit consisted of a large glass window that allowed visitors to view trays as they were extracted from the inner shelves and delivered to side stations by a huge robot “picker” that traveled on steel rails in the floor of the unit. The robot – weighing hundreds of pounds – moved at an impressive speed, and was fascinating to watch. The whole thing was driven by an Intel 8080 microprocessor located on an S100 card in the rear of the machine.
Craig’s job was to replace the Fichetrieve’s operator keyboards (which could be used to manually request a tray to a side station) with commands from the microfiche querying system. The idea was to make the whole process more efficient and reduce the manual entry required of the operators. All in all, it wasn’t too complicated of a task and involved sending a few commands over the serial interface to the giant Fichetrieve units.
It all seemed to work well and good, until that one fateful day when The Admiral decided to tour the facility. For whatever reason, the picking robots would go completely nuts and randomly stampede towards the glass window at high speeds. The Admiral was not happy, and much finger pointing and arm waving ensued.
As an immediate “fix”, Craig mounted a “Panic” button next to the window on each unit. This allowed anyone standing there to defend themselves by instantly killing all power to the unit should the robot decide to stampede and charge towards the glass. Of course, that wasn’t a real fix.
Over the next few weeks, hardware engineers were brought in to test and debug the 8080 microprocessor, and its firmware code was reviewed for bugs along with Craig’s code on the querying computer. Logic analyzers were employed to try and detect when the 8080 issued the bogus commands that drove the robot nuts, but to no avail –nothing was found. But at unpredictable times –primarily during VIP visits – the robot would go nuts.
No one’s exactly sure who figured it out, but someone discovered the cause: it was the shoes The Admiral and other top brass wore to the demos. Most of the gophers working day-to-day on the system wore sneakers, but the Admirals all wore patent leather hard-soled shoes, and as they walked across the carpeted fiche storage room during the walkthroughs, they'd built up a charge of static electricity.
While watching a demo, if they happened to touch a metal portion of the unit, that charge was sometimes enough to give an instant seizure to the 8080, causing it to issue a string a confusing and inaccurate commands to the robot, resulting in the picker stampeding at full speed towards the viewers.
The moral of the story was to never shake hands with a robot when wearing patent leather shoes.
|
Someone probably used the KAH opcode.
KAH - Kill All HumansProcessor will push the status of the flags to the stack, and will then attempt to kill all humans. This works much like 'Kill Some Humans' [KSH] but there is no way to set a maximum bodycount. Instead, with KAH, the immediate operand and ALU contents are ignored. Note: on the second edition of this CPU, this opcode can be masked by pulling low the "/safe" pin, and this is the recommended usage. |
Since sneakers were fine and leather boots weren't, I think it's a firmware issue. |
|
It had nothing to do with static discharge.
The robots clearly were sentient, and having detected brass in the room, were following protocol and racing up to the glass to salute the admirals and other VIPs. The lack of proper hands for saluting made them appear menacing. And being good robots, as soon as they raced up to the glass to "salute", they went back to work. If these robots had noses, they would be brown. |
|
I don't think the microprocessor "issue[d] a string a confusing and inaccurate commands to the robot" so much as crashed, reset, and restarted the control program. If the device was anything like the robots I helped design and deploy, the hardware can tell the software how far and in which direction the picker has moved, but not precisely where it is. To know that, the controller must run the picker down the rails until it encounters a limit switch.
Although the picker might look like it's charging menacingly, in fact it's moving at what the controller considers a safe slow rate, sort of groping blindly for the limit switch. But it still looks dangerously fast, especially when the movement is straight toward, and ending very close to, your face. It's just unfortunate that in this case the machine was programmed to use the limit switch at the window end of the rails. The real moral of the story is: if you must tease high-ranking officers by hurling heavy machinery at them without warning, make them check their sidearms at the door first. It's all fun and games until you get several cal.45 holes in your Fichetrieve. -Harrow. |
|
Thought this was going to be the story I heard about a tape retrieval robot whose operator thought "Gee, I wonder what would happen if I put in a negative number for the tape ID." Said robot did allegedly run off its rails and through a plate glass window. Supposedly this happened at a gas company in Detroit in the '70s or '80s and the person I talked to claimed to have witnessed the aftermath.
|
|
Ever hear of a random access tape machine?
It consisted of a storage cabinet with a large number of pigeonholes and a mechanical arm. The tapes used were rather stiff and about ten to twelve inches long. When the operator requested a certain tape, the mechanical arm would reach into the appropriate pigeonhole, grab the proper tape, pull it out, run it through the tape reader, and put it back in the pigeonhole. The problem was that sometimes the tape didn't go back into the pigeonhole. Instead, it caught on the outside and acted like a spring. When the mechanical arm let it go, the piece of tape would go flying out away from the cabinet. Someone I knew who had worked in a 1960s computer center that used them said it was pretty funny to be sitting there at the operator console and have occasional pieces of magnetic tape go flying by your head. I've always wondered just how much data such a piece of tape would hold. Remember that back then and into the 1970s, you could read magnetic tape with bit juice and a magnifying glass. |
| « Loopy Validation | CodeThatDocumentsItselfSoWellItDoesNotNeedComments » |
Anon Ymous: