Faster Sync Triggering? - page 4 - General Help and Assistance on using CHDK stable releases - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5 6 7   Go Down

Faster Sync Triggering?

  • 68 Replies
  • 31775 Views
*

Offline reyalp

  • ******
  • 14126
Re: Faster Sync Triggering?
« Reply #30 on: 12 / February / 2015, 16:04:24 »
Advertisements
There is really no need to put *another* script on the camera to call loadfile. The whole reason for the loadfile('...')() trick is to run a file that exists on SD card rather than on your PC. If you wanted to check errors from the chdkptp command line, you'd use the code I posted in a single line, or from a file.

In the current version of chdkptp in svn (not in the packages yet) you can skip this entirely and run a file directly from your pc like
.<myfile.lua

The stuff you edited into your post about the f nil value error is totally unrelated to your problem here. It is about scripts that take menu options, which in CHDK (up to 1.3) were stored in one letter variable names.

Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #31 on: 12 / February / 2015, 16:59:53 »
Quote from: reyalp on 12 / February / 2015, 16:04:24
In the current version of chdkptp in svn (not in the packages yet) you can skip this entirely and run a file directly from your pc like
.<myfile.lua
Very nice. I'm not set up for chdkptp build so will keep an eye open for that.

I knew my error checking route was circuitous but expedient since I couldn't quite work out how to do it from chdkptp.

Thanks again.

Edit:
In chdkptp gui console, this
Code: [Select]
> lua f,err=loadfile('A/CHDK/SCRIPTS/LEVMAIN.LUA') if not f then error(err) end f()works
 ::)
« Last Edit: 12 / February / 2015, 17:31:28 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #32 on: 09 / January / 2017, 15:43:35 »
Quote from: waterwingz on 06 / February / 2015, 20:33:04
@hokiespurs : I have your script setup so it works now with a sync'd shot rate of 1.75 seconds per shot (on my A1200  - an elcheapo Powershot) !  And no special builds or changes to CHDK were needed.

The script turns on an LED each time it is ready to shoot and turns it off when the shot starts.  By watching the LED and manually toggling my USB remote switch each time it lit up, I took 34 shots in 60 seconds.   I would think that your uController has better reaction time than I do so you might even be able to go faster.  Or you could simply set the uController to fire every 1.8 seconds with no feedback from the LED.

Each shot is "sync'd" to the falling edge of the USB pulse so if you had multiple cameras, they would have all been within a few milliseconds of each other.

Code: [Select]
--[[
@title USB Sync
 @chdk_version 1.3
 @param   l LED?
 @default l 1
 @range   l 0 7
--]]

function restore()
    set_config_value(cnf.remote_enable,0) -- disable USB remote
    set_config_value(cnf.synch_enable, 0) -- disable sync
end

-- setup
    AF_led = l
    cnf=require("gen/cnf_core")
    set_console_layout(10, 0, 40, 14)
    print("USB Sync test started...")
    set_config_value(cnf.remote_enable,1) -- enable USB remote
    set_config_value(cnf.synch_enable, 1) -- enable sync

-- switch to shooting mode
    if ( get_mode() == false ) then
        set_record(1)
        while ( get_mode() == false ) do sleep(100) end
    end

-- set focus & exposure and lock them in
    press("shoot_half")
    repeat
        sleep(50)
    until get_shooting() == true

-- fire away as fast as possible
    repeat
        ecnt=get_exp_count()
        set_led(AF_led,1)
        repeat sleep(20) until get_usb_power(1) == 1
        press("shoot_full")
        set_led(AF_led,0)
        tic = get_tick_count()
        repeat sleep(20) until get_usb_power(1) == 0
        pwidth = get_tick_count() - tic         
        i=0
        repeat
          sleep(20)
          i=i+1
        until( get_exp_count()~=ecnt ) or ( i>100 )
        release("shoot_full_only")                     
    until ( pwidth > 2000)
   
-- done
    release("shoot_half")
    restore()
    print("done")


Edit : forgot to mention that the script will stop if you give it a pulse of more than 2 seconds.  Otherwise it will shoot forever.

Is there a way to know/estimate a minimum safe period between press("shoot_full") in above (i.e sensing +5V) and when the tight loop hook should have been reached (in order that the +5V -> 0V transistion can occur)...or should this period be negligible while "shoot_half" is active?

Would be interested to test something similar in multicam.lua taking advantage of usb_sync_wait(1) and a microcontroller to supply relevant voltages.
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Faster Sync Triggering?
« Reply #33 on: 09 / January / 2017, 19:18:07 »
Quote from: andrew.stephens.754365 on 09 / January / 2017, 15:43:35
Is there a way to know/estimate a minimum safe period between press("shoot_full") in above (i.e sensing +5V) and when the tight loop hook should have been reached (in order that the +5V -> 0V transistion can occur)...or should this period be negligible while "shoot_half" is active?
It's safe to initiate the +5V -> 0V transition as soon as you detect the AF LED turning off.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14126
Re: Faster Sync Triggering?
« Reply #34 on: 10 / January / 2017, 00:34:50 »
Quote from: andrew.stephens.754365 on 09 / January / 2017, 15:43:35
Is there a way to know/estimate a minimum safe period between press("shoot_full") in above (i.e sensing +5V) and when the tight loop hook should have been reached (in order that the +5V -> 0V transistion can occur)...or should this period be negligible while "shoot_half" is active?
On the camera, you could use the hook_shoot hook http://chdk.wikia.com/wiki/Script_Shooting_Hooks#hook_shoot to measure, or do something to signal that the camera is ready.

The hook becomes "ready" immediately before the hardware remote stuff is called.

So if you wanted to do it all under software control, you could have a command that did something like
hook_shoot.set
press shoot_full
hook_shoot.wait_ready
release shoot_full
hook_shoot.continue (allowing it to continue into the hardware remote wait loop)
return status

On the pc side, you'd wait for this command to complete with cmdwait, and then do whatever is required to trigger the hardware remote, e.g. using system.execute() to run a command that controls a GPIO.

If you wanted to know when the shot was finished, you'd have to make an additional multicam command for that.
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #35 on: 10 / January / 2017, 10:10:59 »
Quote from: reyalp on 10 / January / 2017, 00:34:50
So if you wanted to do it all under software control, you could have a command that did something like
...
return status

Nice.

I'll not have time to code/test for a bit so, just to be sure I don't lose momentum & have the right end of your stick, you mean:

return status ->
  • wait_timeout_write_status(get_shooting,true,100,mc.shoot_complete_timeout,'get_shooting timeout')
?

In your pseudo function, can I place:
  • usb_sync_wait(1)
anywhere prior:
  • hook_shoot.continue
Quote from: reyalp on 10 / January / 2017, 00:34:50
If you wanted to know when the shot was finished, you'd have to make an additional multicam command for that.

You mean:
Code: [Select]
function cmds.status_check()
    wait_timeout_write_status(get_shooting,false,100,mc.shoot_complete_timeout,'get_shooting timeout')
end

Quote from: reyalp on 10 / January / 2017, 00:34:50
On the pc side, you'd wait for this command to complete with cmdwait, and then do whatever is required to trigger the hardware remote, e.g. using system.execute() to run a command that controls a GPIO.

For the record only:
I currently redirect multicam.lua status to text file and process that in an external application (AutoIt). I currently plan to control the Windows PC / Arduino serial comms by way of Putty/Plink and the AutoIt wrapper described here, in case it could be useful for someone:
https://www.autoitscript.com/forum/topic/128310-plink-wrapper/?page=1
A lot of overhead I imagine though and not everyone's cup of tea.
« Last Edit: 10 / January / 2017, 10:17:49 by andrew.stephens.754365 »
Logged
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #36 on: 10 / January / 2017, 10:15:49 »
Quote from: waterwingz on 09 / January / 2017, 19:18:07
It's safe to initiate the +5V -> 0V transition as soon as you detect the AF LED turning off.

Thanks, I should probably have described my idea in more detail!
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Faster Sync Triggering?
« Reply #37 on: 10 / January / 2017, 11:03:47 »
Quote from: andrew.stephens.754365 on 10 / January / 2017, 10:15:49
Thanks, I should probably have described my idea in more detail!
Yes.  I had assumed from your description that you wanted the microcontrollers to monitor camera status (shot completion) independent of your PC.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14126
Re: Faster Sync Triggering?
« Reply #38 on: 10 / January / 2017, 13:12:13 »
Quote from: andrew.stephens.754365 on 10 / January / 2017, 10:10:59
wait_timeout_write_status(get_shooting,true,100,mc.shoot_complete_timeout,'get_shooting timeout')
?
No, you wouldn't want to wait on get_shooting there, or any wait. I guess you could combine it with the hook_shoot wait (using hook_shoot.is_ready as the first argument) but you'd have to do the full press release differently.

Otherwise just use write_status(true)

Quote
In your pseudo function, can I place:

usb_sync_wait(1)

anywhere prior:

hook_shoot.continue
Probably, but I would set everything like that before pressing shoot_full

Quote
You mean:
Code: [Select]
function cmds.status_check()
    wait_timeout_write_status(get_shooting,false,100,mc.shoot_complete_timeout,'get_shooting timeout')
end
Yes, something like that.

Quote
I currently redirect multicam.lua status to text file and process that in an external application (AutoIt). I currently plan to control the Windows PC / Arduino serial comms by way of Putty/Plink and the AutoIt wrapper described here, in case it could be useful for someone:
In that case, in my example you could just make chdkptp output some recognizable string to the autoit code and have that trigger the arduino. Or if you can a stand along executable which can talk to the serial port, you could invoke it directly from chdkptp lua code.
Logged
Don't forget what the H stands for.
*

Offline andrew.stephens.754365

  • ****
  • 461
Re: Faster Sync Triggering?
« Reply #39 on: 10 / January / 2017, 14:08:53 »
Quote from: reyalp on 10 / January / 2017, 13:12:13
No, you wouldn't want to wait on get_shooting there, or any wait.

surely get-shooting will be true at that point (assuming correct procedure/operation) and the while loop of
function wait_timeout_write_status(func,value,wait,timeout,msg) will never be executed...i.e. zero wait is introduced since we immediately fall through to write_status(true)...or am I missing a trick ?

Quote from: reyalp on 10 / January / 2017, 13:12:13
In that case, in my example you could just make chdkptp output some recognizable string to the autoit code and have that trigger the arduino. Or if you can a stand along executable which can talk to the serial port, you could invoke it directly from chdkptp lua code.

Ok.

All great stuff - thanks.
Logged
Pages: 1 2 3 [4] 5 6 7   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal