Faster Sync Triggering?

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #50 on: 08 / April / 2017, 14:18:33 »

Advertisements

Mod - please delete this comment. I found it impossible to correctly format it.

Edit: content deleted.

« Last Edit: 09 / April / 2017, 07:30:55 by andrew.stephens.754365 »

Logged

waterwingz

12140

Re: Faster Sync Triggering?

« Reply #51 on: 08 / April / 2017, 14:18:37 »

Quote from: andrew.stephens.754365 on 08 / April / 2017, 14:13:58

Quote from: waterwingz on 08 / April / 2017, 13:01:38
Nope - set_config_value(191,1) has no effect on ptp connectivity.
So, doing that in script has zero impact on the .cfg, correct?

Not correct. The value is saved in the CCHDK.CFG file and reloaded at startup. But what that value is set to has no effect on ptp connectivity.

Logged

Ported : A1200 SD940 G10 Powershot N G16

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #52 on: 08 / April / 2017, 14:33:52 »

Ok - that's 100% clear, thanks.

Something weird about this is in my memory. Will try to test/remember what and report back.

Logged

reyalp

14118

Re: Faster Sync Triggering?

« Reply #53 on: 08 / April / 2017, 14:59:37 »

Quote from: waterwingz on 08 / April / 2017, 14:18:37

Not correct. The value is saved in the CCHDK.CFG file and reloaded at startup. But what that value is set to has no effect on ptp connectivity.

Just for completeness, whether set_config_value immediately saves the config is controlled by set_config_autosave, which defaults on. If it's turned off, it would be fairly easy to get situations where the change was never saved, e.g. if you shut the camera down from script.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #54 on: 09 / April / 2017, 07:23:08 »

Quote from: andrew.stephens.754365 on 08 / April / 2017, 14:33:52

Something weird about this is in my memory. Will try to test/remember what and report back.

If there was a weirdness, I can't now repeat it. The following test was absolutely fine & no ptp lock out occurred.

For the record, the following functions were added to cameraside multicam.lua:

Code: [Select]

function cmds.lock_ptp_comms()                            
--e.g. to run !return mc:cmdwait('lock_ptp_comms')
usb_force_active(1) --lock ptp comms ON (+5V line changes do not disconnect)
write_status(true)                    
end            

function cmds.enable_remote()                            
--e.g. to run !return mc:cmdwait('enable_remote')
set_config_value(121,1) --enable USB switch operations
write_status(true)            
end

With the chdk remote menu options initially set as:
Enable Remote []
Switch Type [None]
Control Mode [None]

Then, using a usbhub with port 5V switch, the following multicam.lua CLI trace confirms successful operation:

Code: [Select]

___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A952438E0A647E9AC0179DDC30582D5
___> !mc:start() [ensure switch initially at +5V] 
___> !return mc:cmdwait('lock_ptp_comms')
lock_ptp_comms [subsequently, turn switch to 0V]
___> !return mc:cmdwait('rec')
rec
___> !return mc:cmdwait('enable_remote')
enable_remote
___> !mc:cmd('exit')
exit [subsequently, turn switch to +5V]
___> !mc:start()
___> !return mc:cmdwait('lock_ptp_comms')
lock_ptp_comms
___> !return mc:cmdwait('set_mode',{args=61})
set_mode 61 [movie mode, in this example, was selected on the camera]
___>

« Last Edit: 09 / April / 2017, 07:27:08 by andrew.stephens.754365 »

Logged

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #55 on: 20 / September / 2017, 11:52:48 »

Quote from: reyalp 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.

For cross reference with the new info available:

Quote from: reyalp on 17 / September / 2017, 22:47:43

I hadn't really thought about this before, but it is expected behavior, because the only way to get status messages from the camera is by polling, and the USB hardware remote code uses a tight loop that doesn't allow the camera PTP code to run. Getting high precision sync requires the tight loop, so this is not easily fixable in CHDK code.

If it spends too long in this sate (~seconds in my experience), attempting to communicate via USB results in errors like
ERROR: call failed:Protocol error: data expected

The exact behavior may be camera and host OS dependent. A short waits for the remote seem OK, probably because the underlying USB layer allows some wiggle room.

The simplest way to avoid this is for your shoot command to use mc:cmd() instead of mc:cmdwait()

It seems safe to assume there is no easy way to minimize the time difference originally envisioned!?

« Last Edit: 20 / September / 2017, 15:48:37 by andrew.stephens.754365 »

Logged

reyalp

14118

Re: Faster Sync Triggering?

« Reply #56 on: 22 / September / 2017, 01:34:20 »

Quote from: andrew.stephens.754365 on 20 / September / 2017, 11:52:48

It seems safe to assume there is no easy way to minimize the time difference originally envisioned!?

I'm not clear what "originally envisioned" is. My psuedocode in the first quote would problematic for actually triggering the remote, for the reason described in the second.

However, I thought the original question was how long the delay is between pressing shoot_full and the cameras being ready to see the remote signal. It's pretty short if you have half press already held. I would guess it's < 100ms, but you could measure it using the approach described by the pseudocode, without involving the actual remote at all. Just get_tick_count after press'shoot_full' and after ready and return the difference. You'd want to do this a few times to get an idea of the variance.

Then when you want to fire the remote from your code, just wait a bit more than that after sending the command that triggers shoot_full.

It shouldn't depend on the number of cameras: the mc:cmd won't return until the command has been to the last camera, so every other camera will have a longer delay.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #57 on: 22 / September / 2017, 03:42:35 »

Quote from: reyalp on 22 / September / 2017, 01:34:20

I'm not clear what "originally envisioned" is.

I can understand that.

I imagine, when I originally asked the question, I was trying to conceive a method to totally automate (in a failsafe manner) the hardware remote multicam.lua shooting method i.e. without relying on guesswork/rule of thumb. Your mention of the hook_shoot continue -> status message back to pc for switch control seemed to fit the bill (if 250ms polling had been acceptable).

Quote from: reyalp on 22 / September / 2017, 01:34:20

the mc:cmd won't return until the command has been to the last camera

True.

From a a practical perspective, even with a considerable "bit more" safety margin, this should be much faster than the previous method (now understood as unworkable) which included polling.

Thanks.

Logged

reyalp

14118

Re: Faster Sync Triggering?

« Reply #58 on: 22 / September / 2017, 17:31:16 »

Quote

Your mention of the hook_shoot continue -> status message back to pc for switch control seemed to fit the bill (if 250ms polling had been acceptable).

FWIW, you can adjust the polling interval in the options sent to mc:cmdwait (opts are passed to mc:wait_status_msg) However, cameras are polled sequentially and a USB transaction takes several milliseconds, so on large rigs the minimum achievable value could be significant.

Quote

From a a practical perspective, even with a considerable "bit more" safety margin, this should be much faster than the previous method (now understood as unworkable) which included polling.

Yes, I would expect 250ms between pressing shoot_full and triggering the hardware remote to be pretty safe. This is just an educated guess though, I haven't tested.

edit:
script execution time up through the point press'shoot_full' happens could also be a factor. press itself has some built in delay, and there's some hand-off time between the usb code and the script seeing it (~10s of ms).

An alternative would be to make a command that releases the hook_shoot, without requesting status. There's at most ~10ms between hook_shoot.continue() and the camera being in the hardware remote loop. So you could do something like

prepare shot command, sent with mc:cmdwait(). Could be combined with pre shoot
hook_shoot.set
press shoot_full
hook_shoot.wait_ready
release shoot_full
return status

trigger shot, sent with mc:cmd()
hook_shoot.continue

wait >=20ms, trigger hardware remote

« Last Edit: 22 / September / 2017, 17:46:14 by reyalp »

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: Faster Sync Triggering?

« Reply #59 on: 27 / September / 2017, 11:16:48 »

Quote from: reyalp on 22 / September / 2017, 17:31:16

Could be combined with pre shoot

Yes. I hadn't thought about that much but the longer the overall period from gaining focus (or, trying to do that), as always, the greater oppotunity for subject movement.

So, to get some numbers I used the recent discussion (re: multiple follow-up message feedback from a single cameraside function):
https://chdk.setepontos.com/index.php?topic=12368.msg134781#msg134781
to add the following (rough&ready) to a clean install (r746) of multicam.lua:

Code: [Select]

function cmds.preshoot_hook_times()

    local tick_prior_preshoot = get_tick_count()

    press('shoot_half')
    local status=wait_timeout_write_status(get_shooting,true,10,mc.preshoot_timeout)
    
    if not status then
        release('shoot_half')
    end

    local tick_post_preshoot = get_tick_count()
    
    local total_preshoot_period = tick_post_preshoot - tick_prior_preshoot

    write_status(total_preshoot_period, 'total_preshoot_period (ms)')
    
    if type(hook_shoot) ~= 'table' then
        write_status(false, 'build does not support shoot hook')
        return
    end

    if status then
    
        hook_shoot.set(mc.shoot_hook_timeout)
        press('shoot_full') 
        --https://chdk.setepontos.com/index.php?topic=12219.msg134738#msg134738
        --script execution time up through the point press'shoot_full' happens could also be a factor. 
        --press itself has some built in delay, and there's some hand-off time between the usb code and the script seeing it (~10s of ms).
        local wait_time = 0
    
        while not hook_shoot.is_ready() do
            if wait_time > mc.shoot_hook_ready_timeout then
                hook_shoot.set(0)
                release('shoot_full')
                write_status(false, 'hook_shoot ready timeout') -- write_usb_msg only when hook fails & prior get_shooting is true
                return
            end
            sleep(10)
            wait_time = wait_time + 10
        end

        local tick_post_hook_shoot_ready = get_tick_count()
        
        local total_hook_shoot_is_ready_period = tick_post_hook_shoot_ready - tick_post_preshoot

        write_status(total_hook_shoot_is_ready_period, 'total_hook_shoot_is_ready_period(ms)')-- write_usb_msg only when hook reached&prior get_shooting is true    
        release('shoot_full')
    
    else
    
        write_status(false, 'shoot_half was released - no hook_shoot_is_ready_period calculated')-- write_usb_msg only when hook not reached because prior get_shooting failed    
        
    end
    
end

The test was to run a single occurrence (cmd) of that on 8 cameras:

Code: [Select]

___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
etc etc
+ 8:Canon PowerShot SX150 IS b=\\.\libusb0-0008--0x04a9-0x3234 d=bus-0 s=52358FA
70E8940F9B145A6C7053BB251
___> !mc:start()
___> !return mc:cmdwait('rec')
rec
=true,{
 [1]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [2]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [3]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [4]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [5]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [6]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [7]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
 [8]={
  done=true,
  status={
   status=true,
   cmd="rec",
  },
  failed=false,
 },
}
___> !return mc:cmd('preshoot_hook_times')
preshoot_hook_times
=true
___> !mc:print_cmd_status(mc:wait_status_msg())
ok
1: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
2: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
3: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
4: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
5: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
6: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
7: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
8: {
 done=true,
 status={
  status=true,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
___> !mc:print_cmd_status(mc:wait_status_msg())
ok
1: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=770,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
2: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=690,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
3: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=680,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
4: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=690,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
5: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=750,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
6: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=680,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
7: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=710,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
8: {
 done=true,
 status={
  msg="total_preshoot_period (ms)",
  status=700,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
___> !mc:print_cmd_status(mc:wait_status_msg())
ok
1: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
2: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
3: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
4: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
5: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
6: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
7: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
8: {
 done=true,
 status={
  msg="total_hook_shoot_is_ready_period(ms)",
  status=140,
  cmd="preshoot_hook_times",
 },
 failed=false,
}
___> !mc:print_cmd_status(mc:wait_status_msg())

From this, the minimum prefocus period was 680ms, the maximum 770ms and the subsequent period until the hook_shoot was ready was constant at 140ms on all 8 cameras.

Of course, as you had already pointed out on the other linked thread, my 4th attempt at
!mc:print_cmd_status(mc:wait_status_msg()) hung as a short timeout had not been included.

Quote from: reyalp on 22 / September / 2017, 17:31:16

and there's some hand-off time between the usb code and the script seeing it (~10s of ms).

Is there another way of saying the same thing - I can't quite picture the context.

« Last Edit: 27 / September / 2017, 11:19:22 by andrew.stephens.754365 »

Logged