Reading back and printing the status of the flash via get_prop(props.FLASH_MODE) showed: when setting the flash to ON in the camera menu, the flash is also on (value 1) in the property. Setting the flash to OFF in the original camera menu, the flash prop is set to 2 as expected (meaning: off).
Writing to props.FLASH_MODE via set_prop() sets the value as expected (as reading back shows),
This all sounds normal
but it has no effect on camera behavior:
But this does not. As caefix said, setting some props is ineffective (which we call "read-only", even though the prop value itself changes), but flash mode is settable on a wide range of cameras, so IMO it's much more likely there is some specific quirk of the script or specific camera settings than your camera.
I personally confirmed on digic 2, digic 4 and digic 6 cams with the following procedure (using chdkptp)
con 22> rec
con 1> shoot
Initial flash mode was off, flash not triggered
con 2> =set_prop(require'propcase'.FLASH_MODE,1)
con 3> shoot
Flash triggered
con 4> =set_prop(require'propcase'.FLASH_MODE,2)
con 5> shoot
Flash not triggered.
By the way... is there a requirement, when props.FLASH_MODE should be written?
I'm currently doing this after switch_recmode(1) and press("shoot_half").
I would definitely set it while in rec mode (after switch_recmode(1) completes) and
before half press, so in between as caefix said. This appears to be how it is in the script you posted, though commented out in copy you posted.
It's possible that some delay is required, but your script looks like it already has some sleeps after switching to rec and before shooting. Also, if you change the shooting mode (P, Auto etc) you should probably set the flash mode prop after that, but the script doesn't appear to do that.
Are you certain that the USB power is actually switching in this case? If you turn on "Show Misc. Values" under Miscellaneous Settings -> Debug, the item labeled USB will show the USB power state.
There is no way to tell, since the camera goes into an endless picture-taking loop that can only be stopped by powering off. But the USB cable is detached, so physically it should be power state off.
If the USB cable is disconnected that should at least rule out hardware issues. Looking at your script, I don't see an obvious explanation, since the click shoot_full_only only happens in when get_usb_power(1) is 1.
General possibilities I can think of
1) get_usb_power continues to return 1 when it shouldn't
2) click("shoot_full_only") somehow fails to release shoot_full_only
3) CHDK Lua flow control is somehow broken
None of these seem very promising, but you may be able to distinguish them with some debugging.
For #2, it would only keep shooting if the Canon firmware is set to continuous drive mode. So, make sure it's set to single shot in Canon settings.
For #1, you could code some kind of hard coded limit on the number of shots without get_usb_power returning 0, something like (untested)
shots=0
repeat
if (get_usb_power(1)==1) then
shots = shots + 1
if shots > 10 then
error("shots > 10")
end
... (normal usb power on case goes here)
else
shots = 0
end
...
