Many years ago, I had a stint where I wrote and managed some factory automation software.
One set of machines were almost ideal for this. When one placed material on the machine, it would read a barcode off of the bottom of the material container, and send a trigger which included that barcode to the automation software. The automation software could then look this container up in the database, find out what material it had in it and what processing that material needed. As the machine processed the material, it would send out triggers notifying the automation of the state of processing, which allowed the software to do some of the end processing early (processing generated a lot of data, and uploading that to the database as it came in saved several minutes of data upload at the end. A time savings that didn't matter at all, because processing generally took about 20 hours, so it was unlikely anyone was standing by the machine when it finished.) It also generated data on the state of the machine itself, so the software could notify maintenance when the machine would need cleaning after a run, including approximately when that would be (at least, so long as that notice wasn't sent to maintenance less than 15 hours into processing.) And, when the material was removed from the machine, it sent another trigger to tell the automation software that, too.
It sent triggers to the software to say when someone aborted a run (big easy-push red mushroom button beside the material pod), when the machine was powered off, powered on, or even someone pressed the reset button.
In addition to all of those triggers, there was a separate API to request the status of all of the above things. I've no idea how well that actually worked, because the triggers worked very well, and I never needed to explore the alternative.
The command interface was pretty simple: you sent the machine a process file name, and it returned a status code. That could be 0 - success (processing started), which would also be accompanied by a trigger that said the same thing. Or it could be an error, such as 1 - machine busy (already processing), 15 - no material, or about six other conditions. There were no other commands; to select a process was to start it. If anyone wanted to stop processing, there was a big easy-push red button beside the material pod.
The machine had a safety door that one had to close after placing material, before one could start processing. If one tried to start processing before the safety door was closed, regardless of whether that was via a manual start or via automation, the machine would lock up (with red lights flashing), and would not do anything else, until one restarted it - a process that took 15 minutes. The safety door did not send triggers to the automation software. There was no way to get a status check on the safety door.
This wasn't a major hurtle. All automation software required an automation terminal, which looked sort of like the gadgets some grocery stores have their stock people use to link barcodes to prices, process inventory, and stuff. Except these were simpler; they had no barcode reader, and they were physically connected with a cat-5 cable to the same switch that connected the machine to the network. They had about 50 keys (no modifiers), and a screen size something like 40x16.
Once the operator put material that actually needed to run on the machine, my automation software would tell them to "close the safety door and press any key to start processing" This message was enclosed in a simple ASCII-art box, and centered on the screen. If they instead put material that needed a different machine, my software would tell them that, displaying the error 'wrong machine' in banner-ish text at the top, and indicating which machine it needed in normal text in the bottom third of the screen.
Once processing started, my software would display a running status, including an estimated time to complete processing. The running status was not in an ASCII-art box, and was quite terse. It said, "running ", followed by the name of the process, with the time left on the line below, in minutes. When processing finished, it gave a brief message telling them where the material needed to go next, until they picked the material up off of the machine.
Now, even with this simple interface, I still got some support calls about the UI. I remember a few:
- The space key stopped working on the terminal. I've ordered a new terminal, but can you make it go remotely until it arrives; it'll take a week.
- The enter key stopped working on the terminal. I've ordered a new terminal, but can you make it go remotely until it arrives; it'll take a week.
- The 'A' key stopped working on the terminal. I've ordered a new terminal, but can you make it go remotely until it arrives; it'll take a week.
- The terminal's totally unresponsive, I can't make the machine start. (These calls fell into three categories: secretly one of the prior three, there was an error message on the screen, telling them why the machine would not process the material, or, the power was out to the building. The last only happened once, the others many times. Sometimes, the error message indicated they'd tried to start the machine before shutting the safety door, so a 15 minute reboot was needed.)
- I pressed a key on the terminal before I loaded the material, and it didn't do anything... (Note: the software didn't display *anything* before they loaded material on the machine. We had tried having it display an instruction to load material on the machine, but that turned out to be a bad idea. That's an entire post by itself. But even without displaying any text, they'd still try a total cart-horse inversion some times.)
- I accidentally left my note pad in the material bay when I started the machine. The interface doesn't give me any way to stop processing. (That's because the equipment interface didn't give me a way to abort processing. Of course, the big red button right beside the material bay would stop the processing just fine - and could've been invoked immediately, rather than calling the computer room, having me paged at 2AM, and waiting for me to call back while the machine happily ate the notebook and utterly de-qualled itself, requiring something like 30 hours of cleaning and re-qualifying. And, yeah, they tried to blame all that downtime, as well as the loss of the notes, on my lousy programming.)
- I see there's material running on {machine}, could you tell me how much longer it'll take to process? (If you're close enough to the machine to see it's actually processing, you're closer to the terminal that displays that info than to the nearest phone. Also, this question always came from someone who made at least as much as I did, rather than someone making barely more than minimum wage.)
I also occasionally got calls from the people who maintained the processing recipes about partial data on material that was still in the machine. Note that the first line of the data said when processing started, so that should've clued them in. Of course, I did also get a call from someone who *had* noticed that, and therefore was wondering why the processing had aborted, and why the software hadn't uploaded a completion status code explaining it. (Answer: someone liked to pretend this stuff's write once memory. As I recall, that person was the user who had asked that particular question.)
Note that the operators did not have my pager number. They could only call the computer room, and the computer room techs had a document that explained that the users could press any key on the terminal - any key at all - to start processing, once the material was properly installed in the material pod, the safety door was fully closed and locked, and there was nothing else in the material pod. This was the same document that indicated who they should call if there were any problems the document didn't cover. Of course, the first thing they did when they got one of these documents was to copy that last bit of info on their big spreadsheet of who to call, and only a few of the computer room techs ever looked at the document again.
(For those curious, they did actually use the wrong material error deliberately sometimes, to see where something needed to go next. When it was material that had just run on the machine, well, it would've been nice had they looked at the terminal before removing the material. But oh well; it would've been nice had I coded a delay between material removal and clearing the terminal screen, so there's sharable blame. When I saw they used that seven times in a row on different containers, each needing a different process, and having sat on average around 5 hours since they'd completed their last processing step, and having each come from a different process, I figured I really needed to get my coworkers to give more useful error messages, as it's pretty stupid to hold material while a machine with a 20 hour cycle time finishes up its stuff, to be able to tell where the material's supposed to go. Especially when they could just enter the container ID or the material ID into one of the handy computer terminals throughout the manufacturing floor, and find out that way... Eventually, they added some material barcode readers to some of the free terminals, so you could just set your material down by the terminal, and it would show you where to take it. Putting one of those by this set of machines eliminated that particular abuse.)
Just in case, somehow, I hadn't made it clear, each of the main system states - empty, ready to process, error, processing, finished processing - had a very distinctive look. I'd been told this was important, because while the operators were literate, many were not very keen on the concept.