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.

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 .

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.

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.

So if an application on your PC makes it overheat and break the PC is at fault for being defective and you get to RMA it? What about a laptop? And a Camera is different how?

In the end it would be faulty / bad design that makes the Camera fail. And that is absolutely a valid reason the RMA it.

> So if an application on your PC makes it overheat and break the PC is at fault for being defective and you get to RMA it?

Kernel code can absolutely brick your PC due to how much it can do. This could be fixed at a UEFI/microcode level, but not without taking a lot of control away from the OS and the end user.