3 ms·

But in this case, the camera processor still retains final control over the commands from the SDK. This isn't a customer firmware, just a networking interface t

But in this case, the camera processor still retains final control over the commands from the SDK. This isn't a customer firmware, just a networking interface that simulates pushing buttons and changing menus. The firmware has just as much ability to reject damaging commands as it would if the user was physically entering them.

999900000999 5y ago
Not many humans can click a button 30 times a minute for 5 hours straight. This feels like cya, it probably won't break the camera, but just in case it does .
- ferongr 5y ago
  An external intervalometer can. And in any case, both in both the SDK and the intervalometer case, the camera's OS is free to just stop functioning, to prevent any possible damage to the sensor or shutter mechanism due to overuse.
- LorenPechtel 5y ago
  That was my thought, also. You very well might be able to do things with the SDK that no human can do. The Therac-25 disaster comes to mind--a sufficiently skilled operator could inadvertently command it to become a death ray. (The trigger condition was to change it's operating mode while it was still executing the previous mode change command. Your average operator couldn't enter orders fast enough, but the fastest people could. It was supposed to work at high power with a target in the way to convert the electron beam to x-rays, or at low power as a direct electron beam. Confuse it and you got the high power mode with no target in the way and a fried patient.