(Promoted from a comment elsewhere, original context not needed for this to make sense.)
Being aggressive, brave, feeling privileged, or whatever it is that makes me speak out in almost any circumstances doesn’t actually correlate well with knowing things useful in a discussion or in having ideas of value to a discussion. It’s worth some effort to me to avoid driving away people who have stuff to contribute to the discussion even if they are “timid” or easily scared off. Brash, outspoken people don’t really lack for opportunities to make their points; but we don’t have “all the points”.
Both for the call buttons at each floor, and the floor buttons in the elevator car, we expect them to respond to pushing by some change in state to show that our command has been received. Nearly always this is some form of a light coming on (background of the button, surrounding the button, rarely a little light right in the button). I will refer to this as the “state indicator”.
In addition to acknowledging our immediate command, the state indicator conveys information to other users of the elevator. When we come to the doors we can see from a distance that the “up” call button has already been pressed, so we don’t have to force our way through the crowd to push it ourselves; and the same thing for the floor button once we’re in the car.
All these buttons have to talk to a central controller (well, or to distributed controllers which talk to each other, thus achieving the same goal as a central controller). For the elevator to actually come when the “up” call light is on, the elevator car itself has to move to that floor, stop, and open its doors. For me to arrive on the 11th floor after pushing that button, the car has to go there, stop, and open its doors.
But there’s a weird thing that happens with many elevators, including the ThyssenKrupp elevator system at the DoubleTree Park Place (where I was for Fourth Street Fantasy Convention last weekend, and where Minicon will be for the first time this coming Easter). Often, if I push a button rather briefly, I will see the state indicator come on briefly, and then go off and stay off. My push does not seem to have “taken”, at least the central controller has not accepted it. (If I wait, the elevator never comes in response to the call I thought I made, but which after the brief blink is not acknowledged. It may of course come to the floor to drop somebody off, and may then continue in the direction I want, but it never comes empty, so I feel safe in saying I have not managed to log my request with the controller.)
How can this happen? The most obvious way to set it up is to have the state indicators simply controlled from the central controller. Thus, if it comes on, the central controller does have the request, and if it doesn’t, it doesn’t (well, or the indicator is burned out, or there’s a wiring fault, or…oh, the heck with it; it doesn’t).
The evidence appears to suggest that this isn’t how it works, for whatever reason.
Okay, rampant speculation based on very little knowledge (said to be a dangerous thing; though actually that’s “learning”) coming up. It’s worth remarking that elevators are fairly old technology, that they’re safety-critical, and that they have been heavily regulated for most of the time they’ve existed. This can tend to limit implementation or design choices sometimes in bizarre ways.
One theory is that getting the request logged in the central controller and the response back to the state indicator is slow enough that people were reacting weirdly (they’d push the button, nothing would happen and then just as they tried again the state indicator would come on, for example). If this is seen (as it probably should be) as a user interface fault, maybe somebody had the bright idea of turning on the state indicator locally briefly, for long enough that the central command to turn it on would have arrived before the local command expired.
But that then raises the question of why the brief push is enough to trigger the local turn-on but not the central controller; surely it makes no sense for the two to have independent access to the exact details of the analog button-press and to make independent decisions about it based on different rules! The local module should decide if the button has been pressed or not, and then both take local action and communicate with the central controller, so they would never be in conflicting states.
It’s possible that, either in these particular elevators (which are fairly old), or in elevator designs by tradition, or perhaps by old regulatory fiat, this approach was adopted at a technological era when it was economically beneficial to put all the intelligence in one central place, and then do extremely simple things locally to work around it (I didn’t test carefully, the local turn-on of the state indicator may be as simple as “while the button is pressed”).
Or it could be weirder and much more interesting; we can always hope.
Speculation, as above, is cheap. Does anybody actually know anything about elevator control systems?
This particular behavior bugs me because the light coming on instantly tends to influence me to making shorter button pushes (I see confirmation!), which makes it more likely that I haven’t actually held the button down long enough to log my request properly.
So, as you may have noticed recently I got a copy of Jerry Stearns’ old Mpls. in ’73 t-shirt from the surplus archive collection. It was in good enough shape that I scanned it, and gave a passing thought to maybe doing a modern edition—if I could get the various people involved, whoever they were, on board.
So I ran into Jerry Stearns early at Minicon, and confirmed that he thought it was a good enough idea. Also that the artwork was by Ken Fletcher (it’s not signed). And, even more useful, Jerry had with him a collection of paper prints from the same screen. Those are much higher resolution, not as distorted, and much easier to scan.
The best scan seems to be the red channel of a 48-bit color scan of the version with blue ink on orange paper (contrast!). With a bit of cleanup it currently looks like this:
So, I’m getting ahead of myself here, but it’s fun to work the scan and see what I can get. I guess I’d better talk to Ken soon!
It was just too ugly. Even for a temporary server. Especially when you consider all those wires flapping around would impede airflow.
Only took about half an hour of work to rewire it, although waiting for cable tie anchor pads to set (the adhesive wants 24 hours, ideally; and this batch I’ve had pull off in many situations, to the point where if it happens again I’m throwing the rest out) slowed down the elapsed time.
It also made getting the side panel back on easier (this case has a shroud connecting the CPU cooling fan directly to the outside, on the removable side of the case) since the wires were held back. That’s also why the sloppy wiring would work, though—those wires that look like they’d get into the CPU cooler wouldn’t really, once the side panel was on properly.
Cooling is working excellently (the external fan in front of the expansion bay probably helps; that’s held on with cable ties and tape too).