Another stack for AutoIt / lua

  • 16 Replies
  • 3591 Views
Re: Another stack for AutoIt / lua
« Reply #10 on: 07 / May / 2015, 17:25:42 »
Advertisements
Based on your previous posts about multicam.lua etc, I assumed you planned to control the cameras with a single instance of chdkptp.

That's correct. My remark was poorly placed - it was made in light of H-H's comment regarding a Master AutoIT GUI controlling single instances on multiple machines. Apologies about that.

I did not mean to imply it would provide more functionality. The point is wrapping chdkptp in autoit adds a substantial amount of complexity, and requires a substantial amount of time writing and maintaining "glue" code.

I've just started mockup of the AutoIt GUI (screenshot attached) - GUI visual design change and autocode creation are very easy / relevant code snippets abundant.

The glue to chdkptp at the minute purely AutoIt "Send(this that or the other)" to the chdkptp command line.

Now, if I were to e.g:

  • press an AutoIt send button - single camera multicam request for chdkptp produce a complete table of zoom / Aperture values & have it save as a delimited text file on pc
  • suck this info into an AutoIt listbox (so the user can select an available zoom / aperture pair of interest)
  • press an AutoIt send button (the appropriate function.cmd having been added to multicam.lua camera side script) to have zoom/aperture set as selected

Could that be made fundamentally slicker / easier to maintain using IUP?
« Last Edit: 07 / May / 2015, 17:48:05 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 11200
Re: Another stack for AutoIt / lua
« Reply #11 on: 07 / May / 2015, 22:08:37 »
The glue to chdkptp at the minute purely AutoIt "Send(this that or the other)" to the chdkptp command line.
...
Could that be made fundamentally slicker / easier to maintain using IUP?
It's fairly easy to add tabs and buttons in chdkptp (see the gui_user.lua file for example)

Anything you can do by sending chdkptp commands from autoit, you can do in chdkptp itself using cli:execute(), but if you call code directly, it can make handling return values or data from the camera a lot more convenient than trying to parse chdkptp output.
Don't forget what the H stands for.

Re: Another stack for AutoIt / lua
« Reply #12 on: 08 / May / 2015, 02:49:40 »
...[]...but if you call code directly, it can make handling return values or data from the camera a lot more convenient than trying to parse chdkptp output.

Makes sense. Multicam.lua could should become very big. Perhaps my e.g exemplifies some workaround technique as substitute for lack of some fundamental lua understanding.   

I'll also dig in to IUP some.

Anyway, some reflection required in case the expedient route results in another F-35.

Thanks for comment.

Re: Another stack for AutoIt / lua
« Reply #13 on: 22 / May / 2015, 07:12:14 »
Background:
My sx150is has a real aperture (stepper motor? presumably with non-trivial time between realising each value) - not all values are available at all zoom_steps.

I designed an autoit gui listview control to enable single click selection of a particular zoom_step/aperture value pair (if anyone is interested the code is in this thread https://www.autoitscript.com/forum/topic/167766-listview-select-subitems/?do=findComment&comment=1246546).

A quick(&dirty), on the fly, set_zoom function addition to multicam.lua works fine when sending the listview zoom value...but i'm not sure whether, at this point, to bother setting the Canon Aperture [using a get_user_av_id / post_levent_to_ui("RotateJogDialLeft(/Right)",1) addition] or simply add a set_av96 override to it.

Having, for the first time, just looked at multicam.lua function cmds.shoot_hook_sync() and read the start of the script shooting hooks thread (http://chdk.setepontos.com/index.php?topic=11081.msg108530#msg108530), i'm not really sure if the set_av96 override I propose above would occur after the hook_shoot.continue() line in the function (if so, presumably that override time could vary a lot  between cameras and very negatively impact ptp sync?)

In summary, if I set an aperture override, say by an on the fly function addition to multicam.lua (or directly add to camera side script code) - when/where is the aperture override applied if subsequently shooting using cmds.shoot_hook_sync() ?

Other,
hadn't really expected to be thinking of implementing a ptp based trigger so neither do I particularly understand how the  tonumber(mc.args)) of wait_tick(tonumber(mc.args)) ends up the correct number on the different cams...a brief overview of pctime / cam tick logic would help me read the relevant multicam functions.

Haven't got around to looking at IUP yet  :-[



fmi:

http://chdk.setepontos.com/index.php?topic=8769.msg107995#msg107995

The highest resolution clock available to CHDK lua is get_tick_count, which has a precision (but not necessarily accuracy) of 10 ms. os.time only gives you seconds.

As I posted earlier, the multicam.lua chdkptp module attempts to do something a bit like what you described in  http://chdk.setepontos.com/index.php?topic=8769.msg107985#msg107985 using get_tick_count and wait loops in lua.

If a higher precision clock were available, you'd probably want to make a script command that let you schedule a shot to begin at a certain precise time using the remote hook, rather than doing the wait in Lua. The stuff in this thread http://chdk.setepontos.com/index.php?topic=8312.100 might be helpful. I suspect that even if you get the high precision clock, synchronizing it with a similar level of precision of USB would still be tricky.


« Last Edit: 24 / May / 2015, 16:18:27 by andrew.stephens.754365 »


*

Offline reyalp

  • ******
  • 11200
Re: Another stack for AutoIt / lua
« Reply #14 on: 24 / May / 2015, 16:18:36 »
In summary, if I set an aperture override, say by an on the fly function addition to multicam.lua (or directly add to camera side script code) - when/where is the aperture override applied if subsequently shooting using cmds.shoot_hook_sync() ?
Just call set_av96 or set_av96_direct before you start the half press. The aperture adjustment will be applied in the normal pre shoot process. Alternately, if the camera is in a mode that allows manual Av control (Av or M) you can set the USER_AV propcase. This should be equivalent to setting it in the canon UI.

The multicam testshots function has an example of setting exposure parameters (tv and av) before a shot.

Timing issues with the hooks are only a concern if you are trying to shoot rapidly with continuous mode or the "hold half shoot, repeatedly click full shoot" method.
Don't forget what the H stands for.

Re: Another stack for AutoIt / lua
« Reply #15 on: 24 / May / 2015, 16:21:13 »
Thanks.

*

Offline reyalp

  • ******
  • 11200
Re: Another stack for AutoIt / lua
« Reply #16 on: 24 / May / 2015, 16:54:33 »
Other,
hadn't really expected to be thinking of implementing a ptp based trigger so neither do I particularly understand how the  tonumber(mc.args)) of wait_tick(tonumber(mc.args)) ends up the correct number on the different cams...a brief overview of pctime / cam tick logic would help me read the relevant multicam functions.
The basic idea is
1) use get_tick_count on each camera and store the offset from the PC clock. This attempts to take transmission latency into account, so you can convert a "real" time on the PC to tick value on each camera.
2) to execute a "synced" command at a given time PC time, it just sends the tick value at which each camera should execute the command.
Quote
If a higher precision clock were available, you'd probably want to make a script command that let you schedule a shot to begin at a certain precise time using the remote hook, rather than doing the wait in Lua. The stuff in this thread http://chdk.setepontos.com/index.php?topic=8312.100 might be helpful.
FWIW, srsa did some research into high precision timers: http://chdk.setepontos.com/index.php?topic=11342.0 since that post was written. In principle, it should be possible to achieve much better sync over PTP, but the large, variable communication latency would cause some difficulties. The fast wraparound of the high precision counter would also complicate things.
Don't forget what the H stands for.

 

Related Topics