Script sleep oddity - page 4 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5 6   Go Down

Script sleep oddity

  • 57 Replies
  • 22846 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Script sleep oddity
« Reply #30 on: 18 / January / 2013, 21:55:01 »
Advertisements
Quote from: lapser on 18 / January / 2013, 21:44:20
Quote from: philmoz on 18 / January / 2013, 21:00:09
I've done this differently to lapsers suggestion to avoid having the 'action_push_delay(conf.script_shoot_delay*100)' delay execute twice in the event of a shoot retry.
Good point. Wouldn't it be easier just to pop the delay off the stack before pushing as_shoot again? The delay hasn't started yet, so it doesn't need to be cleared:
Code: (php) [Select]
static int action_stack_AS_WAIT_SAVE()
{
    static int first_shoot=1;
    if (!shooting_in_progress())
    {
        action_pop_func();
        int shoot_ok=(camera_info.state.state_shooting_progress != SHOOTING_PROGRESS_NONE);
if(kbd_is_key_pressed(KEY_MENU))shoot_ok=0;
        if(first_shoot && !shoot_ok)
        {
script_console_add_line((long)"RE-SHOOTING");
            first_shoot=0;
            action_pop_func(); //pop extra delay********************************
            action_pop();      //off the stack
            action_push_func(action_stack_AS_SHOOT);
            return 1;
        }
if(!shoot_ok)script_console_add_line((long)"SHOOT FAILED");
else script_console_add_line((long)"shoot succeeded");
        first_shoot=1;
        if (libscriptapi)
            libscriptapi->set_as_ret(shoot_ok);
        return 1;
    }
    return 0;
}

That's an option; but I prefer not to couple the functions together that tightly (e.g. the code waiting for the shot to complete needs to now about what's on the stack). It makes it harder to adjust in future if the shoot logic needs to change.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline lapser

  • *****
  • 1093
Re: Script sleep oddity
« Reply #31 on: 18 / January / 2013, 22:19:01 »
Quote from: philmoz on 18 / January / 2013, 21:55:01
That's an option; but I prefer not to couple the functions together that tightly (e.g. the code waiting for the shot to complete needs to now about what's on the stack). It makes it harder to adjust in future if the shoot logic needs to change.
I can understand that. I've only written entire programs without collaboration in the past, but I know organization is very important.

That said, I'm not sure having an extra delay after a re-shoot is a bad thing. Something went wrong with the first attempt, so an extra delay might increase the odds of the second attempt succeeding. It happens so rarely, nobody will notice the delay compared to the re-shoot time anyway. So I still vote for my original script. KISS, keep is simple stupid, is my motto. We can explain what we're doing with a comment or two.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Script sleep oddity
« Reply #32 on: 18 / January / 2013, 22:31:29 »
Quote from: lapser on 18 / January / 2013, 22:19:01
That said, I'm not sure having an extra delay after a re-shoot is a bad thing. Something went wrong with the first attempt, so an extra delay might increase the odds of the second attempt succeeding. It happens so rarely, nobody will notice the delay compared to the re-shoot time anyway.

My version adds a 250msec delay before retrying the shoot - yours doesn't, is starts the re-shoot immediately and then does the two post shoot delays back-to-back once the 2nd shoot finishes. You have to remember that the action stack executes backwards from the order things are pushed.

My version also skips the post shoot delay if both shots fail, and returns the result code to the script straight away.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline lapser

  • *****
  • 1093
Re: Script sleep oddity
« Reply #33 on: 19 / January / 2013, 01:19:13 »
Quote from: philmoz on 18 / January / 2013, 22:31:29
My version adds a 250msec delay before retrying the shoot - yours doesn't, is starts the re-shoot immediately and then does the two post shoot delays back-to-back once the 2nd shoot finishes. You have to remember that the action stack executes backwards from the order things are pushed.
Oh yeah? Here's what I say to that:

http://www.youtube.com/watch?v=tfHBPusZg6E#
Quote
My version also skips the post shoot delay if both shots fail, and returns the result code to the script straight away.
ok, ok OK! I give.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Script sleep oddity
« Reply #34 on: 19 / January / 2013, 03:48:10 »
I've created a test branch, philmoz-action-stack, in case anyone wants to try this out.

In addition to the action stack and script changes, I've removed the CAM_KEY_CLICK_DELAY related logic from all affected cameras and replaced it with a longer duration of CAM_KEY_PRESS_DELAY.

The 'shoot' script code also includes a retry if the shoot fails (as suggested by lapser).
For Lua, calling shoot(0) will bypass this and return without retrying if the first shoot fails.

Phil.
« Last Edit: 19 / January / 2013, 03:52:51 by philmoz »
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline lapser

  • *****
  • 1093
Re: Script sleep oddity
« Reply #35 on: 19 / January / 2013, 10:54:10 »
Quote from: philmoz on 19 / January / 2013, 03:48:10
I've created a test branch, philmoz-action-stack, in case anyone wants to try this out.
I don't see it online yet. I'll be gone a day or two, so if you want skrylten to test it with his focus bracketing script sooner, you can compile it for the s2is-100f and post it here:
http://chdk.setepontos.com/index.php?topic=9118.msg95486#msg95486

I don't think shoot(0) is needed. Also, I've been experimenting with adding a shoot parameter that specifies the interval from the last shoot. To shoot every 5 seconds, you would do:

repeat shoot(5000) until false
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline reyalp

  • ******
  • 14128
Re: Script sleep oddity
« Reply #36 on: 19 / January / 2013, 20:17:43 »
The test branch does not miss any shots on my cameras in the cases (from http://chdk.setepontos.com/index.php?topic=7611.msg95684#msg95684 ) that previously failed.

The key actions are generally 10ms shorter than trunk:
Code: [Select]
=t=get_tick_count();click('shoot_full');return get_tick_count()-t
5:return:70
=t=get_tick_count();press('shoot_full');release('shoot_full');return get_tick_count()-t
6:return:80
=t=get_tick_count();press('set');return get_tick_count()-t
7:return:40
click() is 10ms shorter than press('shoot_full');release('shoot_full') because one more action stack cycle is required.

The above are just observations, not necessarily things that should change.
Logged
Don't forget what the H stands for.
*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: Script sleep oddity
« Reply #37 on: 20 / January / 2013, 04:34:47 »
SX220:

The 'click' command works fine.
Code: [Select]
con 3> =t=get_tick_count();click('menu');return get_tick_count()-t
4:return:100
msl
Logged
CHDK-DE:  CHDK-DE links
*

Offline lapser

  • *****
  • 1093
Re: Script sleep oddity
« Reply #38 on: 23 / January / 2013, 16:14:42 »
I did some testing in continuous mode using this script:
Code: (lua) [Select]
--[[
@title Sleep Test
--]]
function tsleep(delay)
  time0=get_tick_count()
  sleep(delay)
  return get_tick_count()-time0
end

--assume continuous mode
print_screen(1)
press("shoot_half")
repeat print(tsleep(10)) until get_shooting()
exp0=get_exp_count()
press("shoot_full_only")
repeat
  repeat
    stime=tsleep(10)
    exp=get_exp_count()
    if(stime>10)then print(stime,exp) end
  until exp~=exp0
  print("Picture number ",exp,"taken in continuous mode",exp-exp0)
  exp0=exp
until false
With Phil's new sleep code, the sleep(10) almost always returns 10 msec later, with only an occasional 20 msec return, maybe 1 in 50 times..

This script writes to a log file while saving pictures as fast as possible at the same time. After a few shots, the camera slows way down, with shots becoming irregular. However, the sleep(10) times still stay at 10 or 20 msec. This shoots down my theory that a busy camera was slowing the script down by increasing the action stack cycle time above 10 msec.

So the script, and camera, must be blocking in file writing because they're interfering with each other. This seems to become a problem when the shot interval in continuous mode is over 1 shot per second. Does anyone have any insight into this, or a possible solution or work around? At the moment, my work around is to not write a log file during high speed shooting.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Script sleep oddity
« Reply #39 on: 23 / January / 2013, 16:37:01 »
Quote from: lapser on 23 / January / 2013, 16:14:42
I did some testing in continuous mode using this script:
Code: (lua) [Select]
--[[
@title Sleep Test
--]]
function tsleep(delay)
  time0=get_tick_count()
  sleep(delay)
  return get_tick_count()-time0
end

--assume continuous mode
print_screen(1)
press("shoot_half")
repeat print(tsleep(10)) until get_shooting()
exp0=get_exp_count()
press("shoot_full_only")
repeat
  repeat
    stime=tsleep(10)
    exp=get_exp_count()
    if(stime>10)then print(stime,exp) end
  until exp~=exp0
  print("Picture number ",exp,"taken in continuous mode",exp-exp0)
  exp0=exp
until false
With Phil's new sleep code, the sleep(10) almost always returns 10 msec later, with only an occasional 20 msec return, maybe 1 in 50 times..

This script writes to a log file while saving pictures as fast as possible at the same time. After a few shots, the camera slows way down, with shots becoming irregular. However, the sleep(10) times still stay at 10 or 20 msec. This shoots down my theory that a busy camera was slowing the script down by increasing the action stack cycle time above 10 msec.

So the script, and camera, must be blocking in file writing because they're interfering with each other. This seems to become a problem when the shot interval in continuous mode is over 1 shot per second. Does anyone have any insight into this, or a possible solution or work around? At the moment, my work around is to not write a log file during high speed shooting.


Are you sure it's not getting stuck in the inner 'repeat' loop waiting for the exposure count to change?
Try counting how many times it loops waiting for exp~=exp0, or record the before and after tick counts.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 2 3 [4] 5 6   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal