3 ms·

Doesn't it also prevent focus?

jacquesm 10y ago
For me it definitely doesn't. It became part of the release cycle, analyze each and every change made to make sure it was safe and have a whole bunch of code that was tested to the max but never ever changed that would shut down the machine if it ever got outside of it's expected envelope. This is actually quite a tricky thing to do right because to be able to jog the machine out of a shut-down like that you have to re-enable it in a potentially un-safe situation. For each and every little challenge like that we found a good solution but some of those were real head-scratchers. A really nasty one that I recall was that when you power up a bunch of latches they can come up in an undefined state, so the decision was made to include a detector for that undefined state which first would have to be cleared before the output of the latches was allowed to influence the motors. This worked well in practice but given the restrictions of the machine this was all done on it took a bit of thinking, the solution we settled on was a magic sequence output on the parallel port indicating the system had successfully reset after which the relay powering the motor drivers would engage. So until that relay triggered everything else was ignored. This was already important enough with stepper drivers, but once we switched to servos for some of the more demanding applications it became crucial to safe operation that the drivers would never ever be energized with faulty inputs. A servo driving a ball-screw will happily wreck itself, the machine it is bolted on to and anything standing in-between (including the operator) if it suddenly gets driven to -10 or +10 V and naturally, you'd always get one of those two, never the safe '0'.
- 0xdeadbeefbabe 10y ago
  Is there also a way to make sure one guy isn't responsible? You know the way they credited Petrov with saving us from nuclear war?
  - jacquesm 10y ago
    Well, that can cut both ways. In Petrov's case it worked out well, but 'ownership' of a problem (and the associated responsibility) in smaller settings can also work to bring out the best in people. Separation of duties is a good principle, and wherever possible you should use it. https://en.wikipedia.org/wiki/Separation_of_duties https://en.wikipedia.org/wiki/Separation_of_duties But in the case of a single tech guy in a company there isn't a whole lot you can do in that direction, so it is best to clearly assign ownership and make sure that the people involved realize full well the consequences of a fuck-up.

For me it definitely doesn't. It became part of the release cycle, analyze each and every change made to make sure it was safe and have a whole bunch of code that was tested to the max but never ever changed that would shut down the machine if it ever got outside of it's expected envelope. This is actually quite a tricky thing to do right because to be able to jog the machine out of a shut-down like that you have to re-enable it in a potentially un-safe situation. For each and every little challenge like that we found a good solution but some of those were real head-scratchers. A really nasty one that I recall was that when you power up a bunch of latches they can come up in an undefined state, so the decision was made to include a detector for that undefined state which first would have to be cleared before the output of the latches was allowed to influence the motors. This worked well in practice but given the restrictions of the machine this was all done on it took a bit of thinking, the solution we settled on was a magic sequence output on the parallel port indicating the system had successfully reset after which the relay powering the motor drivers would engage. So until that relay triggered everything else was ignored. This was already important enough with stepper drivers, but once we switched to servos for some of the more demanding applications it became crucial to safe operation that the drivers would never ever be energized with faulty inputs. A servo driving a ball-screw will happily wreck itself, the machine it is bolted on to and anything standing in-between (including the operator) if it suddenly gets driven to -10 or +10 V and naturally, you'd always get one of those two, never the safe '0'.

0xdeadbeefbabe 10y ago
Is there also a way to make sure one guy isn't responsible? You know the way they credited Petrov with saving us from nuclear war?
- jacquesm 10y ago
  Well, that can cut both ways. In Petrov's case it worked out well, but 'ownership' of a problem (and the associated responsibility) in smaller settings can also work to bring out the best in people. Separation of duties is a good principle, and wherever possible you should use it. https://en.wikipedia.org/wiki/Separation_of_duties https://en.wikipedia.org/wiki/Separation_of_duties But in the case of a single tech guy in a company there isn't a whole lot you can do in that direction, so it is best to clearly assign ownership and make sure that the people involved realize full well the consequences of a fuck-up.