Ultimate Intervalometer - a script for shooting over a long duration - v4.9 - page 63 - Completed and Working Scripts - CHDK Forum
« previous next »
Pages: 1 ... 58 59 60 61 62 [63] 64 65 66   Go Down

Ultimate Intervalometer - a script for shooting over a long duration - v4.9

  • 651 Replies
  • 243870 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #620 on: 01 / May / 2019, 09:50:27 »
Advertisements
Quote from: Mlapse on 01 / May / 2019, 09:20:26
In that case scenario 3 works best because CHDK does not replace CF, but just creates a film-thin layer over CF...and when timing is right you can look through that layer, so what is underneath should have the same setting. At a reboot CF zoom probably has priority over CHDK resulting in similar behaviour to setting zoom in CHDK.
It doesn't work that way - there are no "layers". 

What happens at reboot is that CF moves the lens zoom motor to a preset position and then forgets about it.  The CHDK script engine will not have done anthing at that point due to the startup timing of the ultimate.lua script.  So there is no prioirity to be decided (or fought over).

When the script later decides to also set the zoom position, it sets the zoom step (position) independently. The CF firmware that sets startup settings has no idea that happens.  And in the scenerio 3 case, the zoom is already pretty much at the position that the script is requesting and somehow that makes things seem more stable.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #621 on: 01 / May / 2019, 09:57:40 »
Quote
It doesn't work that way - there are no "layers". 

if there is no underlying data it can not retrieve CF settings and it clearly does.

if there is no influence from CF, how do you explain scenario 2?

in my experience there have always been conflicts between CF and CHDK.
if i encounter those for a specific setup I usually try to avoid setting that value in CHDK and see if it can be solved by setting it in CF.

the trick of forcing values by setting similar values in CF and CHDK is something that I don't use a lot, but for reboots in combination with zoom it seems it's needed again.
i also used it the other way round on my m10 (setting iso differently in CF and CHDK) to reduce max exposure.

i actually want to adapt the UI script so it does not use percentages anymore, but rather the fixed values CF uses on my S95 to prevent even small differences during a reboot/zoom/rezoom/focus cycle.
although i'm not certain that would change anything i think it would at least make chances smaller that there is a difference in some or other calculation.

since my goal is to work with the reboot function @ 24 days i wouldn't want to discover that is was for naught due to small zoom differences that I haven't spotted on my previous tests.
« Last Edit: 01 / May / 2019, 12:21:33 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #622 on: 01 / May / 2019, 13:04:46 »
Quote from: Mlapse on 01 / May / 2019, 09:57:40
Quote
It doesn't work that way - there are no "layers". 
if there is no underlying data it can not retrieve CF settings and it clearly does.
if there is no influence from CF, how do you explain scenario 2?
Apparently we have a different understanding what the term "layers" means - at least from a software design standpoint. Ignore my comments and move on.

Quote
in my experience there have always been conflicts between CF and CHDK.
Very true.  CHDK is a hack working on an undocumented software platform.  When CHDK does something, the Canon firmware is mostly unaware of it happening.  It's not expecting some foreign software to interfer with its normal operations.

Quote
i actually want to adapt the UI script so it does not use percentages anymore, but rather the fixed values CF uses on my S95 to prevent even small differences during a reboot/zoom/rezoom/focus cycle.
You can try to do that. The ultimate.lua script converts the percentage setpoint to a discrete "zoom step" position.  You could easily modify the  code to let you set the step position directly.

But understand that the only way CHDK has to set the zoom position is by telling the camera which zoom step position to go to.  PowerShot zoom lenses are not continuous zoom devices - they move the zoom position in discrete steps.  The number of steps is fixed for each different model - the less expensive ones have as few as 7 steps while the "super zooms" may have over 100 steps. 

So you might want to reverse the process you have described above.  Set the zoom position to the desired step position using the   set_zoom( ) function and then figure out exactly what setting in the Canon CF gets you the same position.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #623 on: 01 / May / 2019, 14:11:21 »
Quote
So you might want to reverse the process you have described above.  Set the zoom position to the desired step position using the   set_zoom( ) function and then figure out exactly what setting in the Canon CF gets you the same position.
Do you mean that the values I got are not the same as CHDK uses to set?

For range the S series specifies 0-127 in the documentation. I was hoping to use the focal_length, but if it is not going to be exact, i'll leave it at the percentage.

I captured these values by setting the lens manually and then taking a shot:
setting  focal_length zoom_step
28mm     6000           0
35mm     7493           2
50mm   10701           5
85mm   18189           8
105mm 22500           9
« Last Edit: 01 / May / 2019, 14:25:37 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #624 on: 01 / May / 2019, 14:30:08 »
Quote from: Mlapse on 01 / May / 2019, 14:11:21
Do you mean that the values I got are not the same as CHDK uses to set?

For range the S series specifies 0-127 in the documentation. I was hoping to use the focal_length, but if it is not going to be exact, i'll leave it at the percentage.

I captured these values by setting the lens manually and then taking a shot:
setting  focal_length zoom_step
28mm     6000           0
35mm     7493           2
50mm   10701           5
85mm   18189           8
105mm 22500           9
Now that I see what you are doing, I realize it's the same thing as what I suggested.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #625 on: 07 / May / 2019, 07:07:16 »
waterwingz, i was wondering in UI you have set the delay at reboot to 70 seconds, but in the debug setting that is only 5.
at least on my S95 the debug reboot works good, lens retracts in time.....although i only tested that for 10 times in a row.
did you encounter trouble with some camera models when this delay is shortened to the debug length?
i found some comments about scripts getting stuck with the lens out. so i guess there has to be a minimum wait.
« Last Edit: 07 / May / 2019, 07:40:08 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #626 on: 07 / May / 2019, 10:39:06 »
Quote from: Mlapse on 07 / May / 2019, 07:07:16
waterwingz, i was wondering in UI you have set the delay at reboot to 70 seconds, but in the debug setting that is only 5.
I hacked in a debug mode in so that I could test code without waiting for days for things to happen. The hack overrides the internal real time value to make things run much more quickly.  It's quite possible not everything works correctly when running in that mode.

Quote
at least on my S95 the debug reboot works good, lens retracts in time.....although i only tested that for 10 times in a row. Did you encounter trouble with some camera models when this delay is shortened to the debug length? I found some comments about scripts getting stuck with the lens out. so i guess there has to be a minimum wait.
I wrote that a long time ago.  ;)

IIRC it was coded that way because I was  concerned that when switching to playback mode just before restarting,  the lens might not retract immediately if it was not setup to do so in the Canon menus.  So I added the delay because a delay at that point did no harm, would guarantee the lens was retracted, and it might thus prevent problems with some cameras not having their lens retracted. I have no idea if that was really necessary but when you are trying to write a script that runs for months at a time, you take as many precautions as possible.   

When running in debug mode, for speed reasons I made sure my camera had the retract delay set to 0 seconds in the Canon menu and hence I shortened the delay.



Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #627 on: 07 / May / 2019, 11:06:42 »
ah, with my camera's lens retract is always set at 1 minute, also when i run debug...so i guess it works :)

and i understand your concern, enough time to get everything done is crucial for a stable reboot....because I'm guessing the NextBootReason of the M series is not available before digic6

but i'm interested in how quick it could stay stable, so i'm going to experiment some shorter times with it on an old a490, they are slow and have no value other than test objects to me.
« Last Edit: 07 / May / 2019, 11:09:33 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline Mlapse

  • *****
  • 584
  • S95 S110
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #628 on: 08 / May / 2019, 10:36:30 »
because i found some strange things when it was running in DEBUG.
i was planning to change the reboot value to 1 hour, so the script could run normally and reboot every hour.
however, my understanding of the code was not good enough to make that happen.

So I'm testing in DEBUG with 5 min interval and 1 day reboot at 12:00 the cam has rebooted 50 times.
When using the timed start/stop, the NO SHOT interval times were changing per day and per reboot.........see a small part of the log:
I am assuming this is the result of running in DEBUG and nothing to worry about, but i thought it better to ask.

Day 4  19:56 <no shot> V: 2.409 T: 36
Day 4  20:04 <no shot> V: 2.418 T: 36
Day 4  20:12 <no shot> V: 2.427 T: 36
Day 4  20:20 <no shot> V: 2.422 T: 36
Day 4  20:29 <no shot> V: 2.418 T: 36
Day 4  21:29 <no shot> V: 2.414 T: 36
Day 4  23:16 <no shot> V: 2.414 T: 36
Day 4  01:04 starting a new day
Day 5  02:48 start time : 09:00 stop time : 17:00
Day 5  04:36 <no shot> V: 2.422 T: 36
Day 5  06:26 <no shot> V: 2.427 T: 36
Day 5  08:16 <no shot> V: 2.418 T: 36
Day 5  10:06 switching to day mode
Day 5  14:50 IMG_0033.JPG tv: 1/800 f: 4.0 ISO: 400 TV96: 939 AV96: 390 bv: 726  V: 2.431 T: 36
Day 5  19:03 === Scheduled reboot ===
« Last Edit: 08 / May / 2019, 10:46:08 by Mlapse »
Logged
frustration is a key ingredient in progress
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Ultimate Intervalometer - a script for shooting over a long duration - v4.8
« Reply #629 on: 08 / May / 2019, 13:11:58 »
Quote from: Mlapse on 08 / May / 2019, 10:36:30
because i found some strange things when it was running in DEBUG. i was planning to change the reboot value to 1 hour, so the script could run normally and reboot every hour. however, my understanding of the code was not good enough to make that happen.
It's quite possible to do that but will it will take me a little time to figure out the best way to implement it with the least side effects and test.  Do you really want to try it still?

Quote
I am assuming this is the result of running in DEBUG and nothing to worry about, but i thought it better to ask
The code used to speed up the clock was a quick & dirty hack. What you see is normal and nothing to worry about.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 ... 58 59 60 61 62 [63] 64 65 66   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal