Don't hold the spacebar!
-
While perusing a manual for the control software of a new piece of industrial equipment my company is of buying i found these two sentences.
"Depressing the space bar briefly while an output is selected will toggle the state of that output. DO NOT HOLD THE SPACE BAR DOWN!!"
This in regards to a diagnostic mode that enables you to set whether an input/output signal is high/low on the control board so you can test the electrical connections.
-
Okay.. some idiot did not understand the event model properly.. it should change the state only after the space bar has been raised. But they went through the hassle of documenting this behaviour nevertheless.
-
Well, it's not too much of a WTF if the autorepeat would cause the signal to cycle high/low very fast. That sort of thing can damage electronics.
Of course the software should make this impossible...
-
@mallard said:
Well, it's not too much of a WTF if the autorepeat would cause the signal to cycle high/low very fast. That sort of thing can damage electronics. Of course the software should make this impossible...
@sepi said:Okay.. some idiot did not understand the event model properly.. it should change the state only after the space bar has been raised. But they went through the hassle of documenting this behaviour nevertheless.
You two got your posts in the wrong order :)
-
Folks that write embedded code to do such things should be fired.
This is why I'm a control systems engineer: while I personally don't think computers should be allowed to control things that move, the best I can do is ensure that I know what the computer is doing when it's controlling stuff that moves, so I develop those controls.
The worst part is, I'm not senior enough to have my opinions override potentially WTF situations yet...
-
@too_many_usernames said:
Folks that write embedded code to do such things should be fired.
This is why I'm a control systems engineer: while I personally don't think computers should be allowed to control things that move, the best I can do is ensure that I know what the computer is doing when it's controlling stuff that moves, so I develop those controls.
The worst part is, I'm not senior enough to have my opinions override potentially WTF situations yet...
Your e-peen must be huge, obviously.
-
@too_many_usernames said:
Folks that write embedded code to do such things should be fired.
This is why I'm a control systems engineer: while I personally don't think computers should be allowed to control things that move, the best I can do is ensure that I know what the computer is doing when it's controlling stuff that moves, so I develop those controls.
The worst part is, I'm not senior enough to have my opinions override potentially WTF situations yet...
I totally agree. I have done a lot of coding with industrial automations, and it should be the first thing that anybody addresses when controlling hardware. If a sequence of events could possibly damage hardware (or worse, the operator) it is the responsibility of the programmer to prevent such circumstances. Although the initial coding could have been a mistake, the first step that should have happened upon discovery was to fix it and provide an update instead of changing the documentation to tell users not to press the spacebar. Anything that adds manual user input to circumvent something that could have been done with software easily (especially when controlling hardware) should be avoided.
-
@pitchingchris said:
Anything that adds manual user input to circumvent something that could have been done with software easily (especially when controlling hardware) should be avoided.
From the OP, it's user input that's causing the problem, not the software's reaction to it. You can only counteract so much PEBCAK in software. I work in control systems, and I'm not happy to code for excessive "user stupidity" if said stupidity shouldn't be allowed near a keyboard/mouse in the first place.
I work in control systems - I code for stupid mistakes, but if user actions could cause a problem outside our remit (but we could code around such circumstances if it involved multiplying LOC by 10) I'd rather there was a note in the Operations manual saying "don't do this," and raising an alarm if there's a possibility of what they're thinking of doing may cause a problem.
-
@too_many_usernames said:
This is why I'm a control systems engineer: while I personally don't think computers should be allowed to control things that move,
There's nothing wrong with allowing computers to control things that move. The problem is allowing anybody who claims to be a "programmer" to control things that move.
Accredited engineering qualifications might not work for software development in general, but there should be laws requiring bonded accreditation for anybody who creates systems for physical automation, just like there are for the people who build the machines being automated.
