supplierdeeply

Another stack for AutoIt / lua

  • 16 Replies
  • 3961 Views
Another stack for AutoIt / lua
« on: 05 / May / 2015, 09:35:44 »
Advertisements
I just started to put together an Autoit gui in order to control chdkptp.

AutoIt enables a lot of things like starting chdkptp and sending commands by keystrokes, e.g:

Code: [Select]
$sArg1_part1 = "C:\CHDKPTP\"
$sArg1_part2 = "chdkptp.exe"
$sArg1_part3 = "-i"
$sArg2 = ""
$iArg3 = @SW_MAXIMIZE

$final_arg1 = $sArg1_part1 & $sArg1_part2 & " " & $sArg1_part3

Global $iProcessID = Run($final_arg1, $sArg2, $iArg3)
I'm sure an excellent tool can be developed on this basis.

Interestingly, I bumped into this http://www.autoitscript.com/forum/topic/120498-embedding-lua-scripts-in-autoit/?do=findComment&comment=837248. The code there, somehow, reminded me a lot of some stuff in chdkptp.c, C <-> lua via the stack.

So, on the basis that everything is, mostly, possible and:
Quote
Lua is very fast, and allows us to extend AutoIt easily, similar to the way plugins work. This also allows us to immediately and easily utilize every package for Lua that currently runs on Windows - game engines, GUI libraries, networking, number crunching, and more.

I think the biggest benefit comes from the ability to create a framework application in AutoIt, and then offload CPU intensive functions, or functions intended to be customized (plugins) to Lua.
 
I was, very tentatively, wondering for an interested developer  - how difficult an AutoIt / chdkptp interface could be to develop?

"a little" and i'll continue my keystrokes, er..am, program. 

Re: Another stack for AutoIt / lua
« Reply #1 on: 06 / May / 2015, 18:43:59 »
I just started to put together an Autoit gui in order to control chdkptp.
This is how I would use AutoIT with Win-PE, but for clarity, some "Important Details" are omitted from
this post. It's (simply) just working with the "Real" Cameras, a "Real" but a Micro Operating System and
the "Real" System Hardware. You can do this stuff with WinXp-PE (PE 1v1) it's probably a bit easier BUT
is more un-reliable. There are various other limitations such as "Bloat Software" won't work, etc, also there
is a 72 Hour time limit. There is lots of web sites and forums regarding Windows PE with so many "Options"
that you will become confused. This (simple) method is not available on any of these PE web sites or forums.

Start:- "WinRE.wim" from a "Demo version of Windows 8 or 10", or similar, i.e WinPE or WinRE,
          versions 4, 5, or 5++.

See:- http://en.wikipedia.org/wiki/Windows_Preinstallation_Environment

"...The (WinRE.wim) package can be used for developer testing....",
     A Virtual Machine approach is not then needed.

Use:- A "BCD" file editor such as (free) "BootIce" in "Legacy Mode" this takes about 30 seconds to do,
        ONCE ONLY.

OR:- Just create a bootable "Development" CdROM that just contains the "Boot.wim" (approx. 200Mb)
        and also the omitted "Important Details" (approx. 100++Mb). This will probably take several attempts
        so its best to use a re-writable Cd-Rom. Bootable USB Sticks could also be use BUT at the risk of file
       corruption also they tend to be very slow.

See:- "Boot Configuration Data" - Editor
en.wikipedia.org/wiki/BCD
or http://en.wikipedia.org/wiki/Windows_Vista_startup_process#Boot_Configuration_Data

What now (simply) happens is that you have additional options, at boot time, to boot a "Developer Testing"
(Win-PE) version of windows.

## Questions:-

##:- Why Do I do this, to put it simply, its just a question of "WHO" is "Controlling" the Micro Operating
         System, you or M$ ~(???)~.

##:- The M$ ~(???)~ way is by using, "Trusted Publishers", "Trusted Installers", "Trusted Platform
          Modules", "Certified Inf and Cat Files", "Your USB" has a Problem", your "Program.exe" has
         "Stopped Working", "See your Administrator", "System Up-Dates" "XYZ...Failed", "SFP",
         "ABC...Error", etc, etc, and "Policys" and "Permissions" for "File Access" and "Permissions" for
         "Registry Access" etc, etc.

      Consider a, simple situation, when you connect a "Brand New" Canon Camera via USB-2 in order
      to obtain the PID_VID and iSerial  Number the "Trusted Installer" will then install the "Default" which
      simply see's the "Brand New" camera as a SD card only. All the "Trusted Stuff" then makes various
     "Backup Driver" copies and also by default creates a "RESTRICTED ACCESS" to "Backup Drivers" and
      a "RESTRICTED ACCESS" to the "Registry" some times this "Default" can very hard to reverse in order
      to use  an "Un-Approved" CHDK Camera Driver. Also when plugging another new camera into the
      USB-2 port, a diffrent version of this stuff will be created. With Multiple Cameras this eventualy results
      in a Un-Stable, Un-Reliable, Un-Dependable, Un-Controlable, MESS.
      There are many CHDK Newbee posts about this CHDK Camera "Driver Problem".

##:- The "Win-PE" way is acheived by using Administrator Super Powers, the "Trusted Installer" and
       "Trusted Platform Module" is still  there but most of the other stuff isn't there so the end result is a
        Stable, Reliable, Repatable, and Dependable Micro Operating System, that is very usefull when using
        multiple cameras. One very usefull feature is that if you make a programing error that results in a
        system crash you simply "Re-Boot" into a brand new and "Clean" and "Stable" Micro Operating System.
        Another usefull feature is the cameras are not "Installed", Normaly M$ uses a "Generic" method of
        creating the necessary "Driver File" links and "Registary Entrys", every time a different CHDK Camera
       is connected via USB-2 the "Trusted Platform Module" checks the "Certified Inf and Cat Files" (and also
        Delays the Camera Connections).  If you initally connect your multiple cameras in a diffrent the
       order  "Trusted Installer" will automaticaly create different "Generic" and very confusing results.
       A better way, by using "Win-PE", is just to "Merge" the requied "Driver File" links and "Registary Entry's".
       this is a very widely used method that can be customised for multiple CHDK Cameras, producing
       "Standarised" or "Customised" Camera Drivers.

##:- "AutoIT" works very well and reliably with all versions of "Win-PE" this also applies to simple program
        development software and simple utility software such NotePad++, Explorer++ etc. So it's possible to
       do Multiple Camera CHDK "Development" and "Testing"  working with the "Real" Cameras, on a "Real"
       but a Micro Operating System and with the "Real" System Hardware.

      You can also use "AutoIT" to "SetUp" the Multi-Camera, Customised, CHDK Drivers. And as per your
      post as a "Remote" GUI Interface  to "Control" ChdkPtp running on multiple instances of "Win-PE".
       
H-H
See Attached File BootIce BCD
Continued in Post #2

« Last Edit: 07 / May / 2015, 00:36:05 by Hardware_Hacker »

Re: Another stack for AutoIt / lua
« Reply #2 on: 06 / May / 2015, 18:52:03 »
Continued from Post #1

##:- "AutoIT" GUI, Multi-Camera Control with "PhotoScan" Example #1:-

      Consisting of 64 "Cheap" (i.e $US 50) Ixus 145 Cameras, as a 8x8 Camera Array, i.e 8 Cameras mounted
      on 8 Poles. On each of the 8 Poles the cameras are connected to a 10-Port USB-2-Hub, the 10-Port Hubs
      are then connected to  4x Cheap "Refurbished" 10-inch Laptops, as a pair, that are running Win-PE and
     a "Slave" version of AutoIT, see stuff above, the 10-inch Laptops are then connected, via ethernet cables,
     to a "Master-PC" that is running "PhotoScan" and the "Master AutoIT GUI"

      ChdkPtp will also works very well and reliably with all versions of "Win-PE". The 8x8 Camera Array can
      then be commanded to "Shoot" via AutoIT, ChdkPtp and the USB-2 Hubs as an 4x16 Camera Array this
      minimises the "Shoot" Delay between the 64 Cameras in the array.
      This is the simplest method of "Shooting", but the cost is the camera "Shoot" delay.

##:- "AutoIT GUI", Multi-Camera Control with "PhotoScan" Example #2:-     

      The 8x8 Camera Array setup is the same as in that Example #1, Sending a Common "Shoot" signal to
      all 64 Cameras in the array using  the USB-Remote Method or the Battery Third Terminal Triggering
      Method and is only slightly more complex. The cost here is in  additional wiring and Hardware. As there
      are spare pairs in a Cat-6 Cable, they could be used as, Pair #1 for the EtherNet #1, Pair #2 for the
      Ethernet #2, Pair #3 as the +-USB-2 and Pair #4 as the USB-2 Ground and +5 Volts. The basic concept
      is that the PC-Master has a "Break-Out Box" for the 4x Cat-6 Cables, at the 4x 10-inch Laptops there is
     another 4x "Break-Out Boxs" that also contains the additional control components such as "Active USB"
     "Opto Isolators" etc.

      The "Master-PC" and the "AutoIT GUI" then recevies it's Camera Control Commands from a USB-2
     "Game-Pad" via free software.

##:- "AutoIT GUI" is a simple, relaible, and flexible way of controlling a multi-camera array.
         i.e. AutoIT provides the System Control Glue Code.

##:- This version of "Win-PE" is normaly is a Command Line Interface only i.e. No Desktop,
        No Metro Tiles, No File Explorer, No Control Panel, No M$ Bloat, etc.

      It's very easy to directly start a Xp like "Start.exe" or a AutoIT.exe or ChdkPtp.exe from a simple
      ChdkPtp.cmd or WinPeShl.ini file.
      Win-7 PE or RE can also be used BUT has a major limitation of only 30Mb of Spare capacity in the
      Ram Drive also its harder to interface with.

H-H
 
rem x:\Programs\ChdkPtp-r658\ChdkPtp.exe -g -cd

x:\Programs\ChdkPtp-r658\ChdkPtp.exe -h

pause

x:\Programs\ChdkPtp-r658\ChdkPtp.exe -g -c
« Last Edit: 06 / May / 2015, 19:06:11 by Hardware_Hacker »

*

Offline reyalp

  • ******
  • 11392
Re: Another stack for AutoIt / lua
« Reply #3 on: 06 / May / 2015, 23:11:41 »
I was, very tentatively, wondering for an interested developer  - how difficult an AutoIt / chdkptp interface could be to develop?
The current version of chdkptp is meant to be built as a standalone executable that includes it's own Lua interpreter, so it can't be loaded as a dll or as a lua module in some other Lua interpreter.

Some people have managed to build it as dll that can be used as a Lua module, for example jbaiter's python interface uses this approach https://github.com/jbaiter/chdkptp.py

I would eventually like to have this capability in the the standard source, but it's not a high priority for me and there are some issues that need to be resolved.

This would only solve half the problem, you would still need a way to call chdkptp code from autoit. The interface you linked looks like it would be fairly cumbersome.

I don't really understand why you want to involve autoit at all. If you want a GUI, learning enough IUP and Lua to customize the chdkptp GUI would seem like a better approach.
Don't forget what the H stands for.


Re: Another stack for AutoIt / lua - what is WinPE ?
« Reply #4 on: 06 / May / 2015, 23:31:40 »
For the benefit of those who have read this thread and wondered what the heck WinPE is :
link > What is Windows PE?

From that website :

Windows Preinstallation Environment (Windows PE) 2.0 is a minimal Win32 operating system with limited services, built on the Windows Vista kernel. It is used to prepare a computer for Windows installation, to copy disk images from a network file server, and to initiate Windows Setup.

Windows PE is not designed to be the primary operating system on a computer, but is instead used as a standalone preinstallation environment and as an integral component of other setup and recovery technologies, such as Setup for Windows Vista, Windows Deployment Services (Windows DS), the Systems Management Server (SMS) Operating System (OS) Deployment Feature Pack, and the Windows Recovery Environment (Windows RE).

And later on in that article,  in the limitations section (there are many - these are just two) ;

  • To reduce its size, Windows PE includes only a subset of the available Win32 application programming interfaces (APIs). I/O (disk and network) and core Win32 APIs are included.
  • To prevent its use as a pirated operating system, Windows PE automatically stops running the shell and reboots after 72 hours of continuous use. This time period is not configurable.

tl;dr  : it's a stripped down version of Windows Vista intended for boot loading that H-H and others have found useful for hacking.  See http://en.wikipedia.org/wiki/WinBuilder
« Last Edit: 06 / May / 2015, 23:43:30 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

Re: Another stack for AutoIt / lua - what is WinPE ?
« Reply #5 on: 07 / May / 2015, 00:28:42 »
For the benefit of those who have read this thread and wondered what the heck WinPE is :Windows Preinstallation Environment (Windows PE) 2.0 is a minimal Win32 operating system with limited services, built on the Windows .... kernel. It is used to prepare a computer for Windows installation, to copy disk images from a network file server, and to initiate Windows Setup.

That is a very OLD M$ link.
M$ the current version for Windows 10 is about 5+
And M$ has since changed many of the WinPE and WinRE features.
I have found that it's more reliable than other Windows versions for
certain one off applications.

When Windows fails WinRE will then start automatically.

H-H

*

Offline philmoz

  • *****
  • 3070
    • Photos
Re: Another stack for AutoIt / lua - what is WinPE ?
« Reply #6 on: 07 / May / 2015, 01:14:26 »
For the benefit of those who have read this thread and wondered what the heck WinPE is :Windows Preinstallation Environment (Windows PE) 2.0 is a minimal Win32 operating system with limited services, built on the Windows .... kernel. It is used to prepare a computer for Windows installation, to copy disk images from a network file server, and to initiate Windows Setup.

That is a very OLD M$ link.
M$ the current version for Windows 10 is about 5+
And M$ has since changed many of the WinPE and WinRE features.
I have found that it's more reliable than other Windows versions for
certain one off applications.

When Windows fails WinRE will then start automatically.

H-H

Using WinPE / WinRE in his way is a violation of the Microsoft license agreement - posting these sort of instructions is against the forum rules.

Phil.
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)

Re: Another stack for AutoIt / lua
« Reply #7 on: 07 / May / 2015, 07:57:11 »
Continued from Post #1

##:- "AutoIT" GUI, Multi-Camera Control with "PhotoScan" Example #1:-

      Consisting of 64 "Cheap" (i.e $US 50) Ixus 145 Cameras, as a 8x8 Camera Array, i.e 8 Cameras mounted
      on 8 Poles. On each of the 8 Poles the cameras are connected to a 10-Port USB-2-Hub, the 10-Port Hubs
      are then connected to  4x Cheap "Refurbished" 10-inch Laptops, as a pair, that are running Win-PE and
     a "Slave" version of AutoIT, see stuff above, the 10-inch Laptops are then connected, via ethernet cables,
     to a "Master-PC" that is running "PhotoScan" and the "Master AutoIT GUI"

      ChdkPtp will also works very well and reliably with all versions of "Win-PE". The 8x8 Camera Array can
      then be commanded to "Shoot" via AutoIT, ChdkPtp and the USB-2 Hubs as an 4x16 Camera Array this
      minimises the "Shoot" Delay between the 64 Cameras in the array.
      This is the simplest method of "Shooting", but the cost is the camera "Shoot" delay.

Great stuff H-H.

I'll need to reply in bits because of small brain.

1. Does this "Master AutoIT GUI" relate to something like: https://www.autoitscript.com/wiki/FAQ#How_can_I_run_my_script_on_a_remote_computer_over_the_network.3F:

"How can I run my script on a remote computer over the network?

The answer to this question depends on how much experience you have in networking. If the target system is a Windows 2000 or Windows XP Pro system to which you have administrator access then you may use one of the following programs:
PsExec from SysInternals
BeyondExec from BeyondLogic
With either of these programs it is possible to launch any process on a remote system and even copy your script to the target computer before starting it. Neither these programs nor any others will work with Windows XP Home Edition unless you create a custom "command listener" that you manually install on the target system.
NOTE: Those of you with more advanced programming skills and a little imagination can figure out how to use the service control libraries and srvany.exe to do this same thing without either of the above mentioned programs."


?

2. Are you creating mccams.txt ([description starting here http://chdk.setepontos.com/index.php?topic=11667.msg114745#msg114745 ]) from stock multicam.lua on each laptop to manage each subgroup of cameras (and the persistence that enables) ?

PS: i've printed the thread in case I should need a firelighter.


Re: Another stack for AutoIt / lua
« Reply #8 on: 07 / May / 2015, 08:07:14 »
I don't really understand why you want to involve autoit at all. If you want a GUI, learning enough IUP and Lua to customize the chdkptp GUI would seem like a better approach.

Probably because (i) the AutoIt GUI builder ("coda") is fairly easy to use (ii) good support on AutoIt forum (iii) I have a little AutoIt experience (iv) I couldn't start to imagine how to use IUP to control multiple instances of chdkptp (v) I can't, currently, think that IUP will provide any more functionality than AutoIt (if I already knew some IUP that perspective may be different though).

Thanks for the other info.

*

Offline reyalp

  • ******
  • 11392
Re: Another stack for AutoIt / lua
« Reply #9 on: 07 / May / 2015, 15:52:26 »
(iv) I couldn't start to imagine how to use IUP to control multiple instances of chdkptp
Based on your previous posts about multicam.lua etc, I assumed you planned to control the cameras with a single instance of chdkptp. If you plan to run multiple instances chdkptp, then using some external program to control may be required, but to me this approach seems problematic for a large number of cameras.

Note that running chdkptp in a Lua dll loaded by autoit would be equivalent to running a single instance of chdkptp, so whatever benefit you expect to gain from using multiple instances would be lost. All it would give you is the ability to call chdkptp Lua functions directly instead of feeding stdin and reading stdout.

Quote
I can't, currently, think that IUP will provide any more functionality than AutoIt
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.
Don't forget what the H stands for.

 

Related Topics