Full Manual Exposure control - page 2 - LUA Scripting - CHDK Forum

Full Manual Exposure control

  • 11 Replies
  • 243 Views
*

Offline Caefix

  • *****
  • 842
  • Sorry, busy deleting test shots...
Re: Full Manual Exposure control
« Reply #10 on: 22 / June / 2022, 12:18:27 »
Advertisements

https://chdk.fandom.com/wiki/Script_commands#get_flash_ready

if get_flash_mode()==0 then
   click ("right")
   sleep(200)
-- next keys
end --  :D
All lifetime is a loan from eternity.

*

Offline reyalp

  • ******
  • 13675
Re: Full Manual Exposure control
« Reply #11 on: 22 / June / 2022, 16:56:28 »
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
Quote
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)
Code: [Select]
con 22> rec
con 1> shoot
Initial flash mode was off, flash not triggered
Code: [Select]
con 2> =set_prop(require'propcase'.FLASH_MODE,1)
con 3> shoot
Flash triggered
Code: [Select]
con 4> =set_prop(require'propcase'.FLASH_MODE,2)
con 5> shoot
Flash not triggered.

Quote
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.

Quote
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)
Code: [Select]
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
...
Don't forget what the H stands for.

 

Related Topics