chdkptp - alternative ptp client - page 47 - General Discussion and Assistance

andrew.stephens.754365

461

Re: alternative ptp client

« Reply #460 on: 11 / December / 2013, 11:49:26 »

Advertisements

reyalp at Reply #454:
thanks, when the problem arose I had briefly examined the existing .inf which included:

DeviceGUID = "{7E8D9BE6-3379-4442-88E6-E3FE200DC43E}" and, while not the serial number, had suspected it was unique to the cam [not sure it is though]. To that extent, what you say about install seems to make sense. In any case will check it out asap [whenever that is].

waterwingz at Reply #456:
i'm pretty sure i'll need some comment, along the way, to get this working [i.e you'll be the first to know

PS: YMMV - daughter now considers I am an urban hero (she still doesn't know what that [YMMV] is - but i do now, thanks [a little] to G)

Other:
Other reasons why, after brief AutoHotKey / AutoIt compare, I decided on AutoIT was, seemingly, better support for arrays and a COM automation bridge [http://sourceforge.net/projects/au3automation/]. Since I [think I] might like to store / change individual camera settings in individual Excel worksheets in a workbook before shunting them off to the cams then AutoIT was it.

Like msl, i'm no programmer and I agree with microfunguy that 'time is short' - so while IUP/Lua definitely appeals to the [small remaining] purist within again, AutoIT it is [if I can get my hands on any "list" stdout with it

...otherwise...]

PS: impressive gui screenshot microfunguy !

« Last Edit: 11 / December / 2013, 16:04:42 by andrew.stephens.754365 »

Logged

reyalp

14082

Re: alternative ptp client

« Reply #461 on: 11 / December / 2013, 16:36:27 »

Quote from: andrew.stephens.754365 on 11 / December / 2013, 11:49:26

Like msl, i'm no programmer

The kind of project you have been talking about is going to require programming, one way or the other. From what I have understood so far, the chances of success without a reasonable proficient programmer involved appear extremely low, regardless of whatever you might want to do with the GUI stuff. I don't want to discourage you, but it's important to have realistic expectations.

Then again, if you are "not a programmer" in the same way msl is, you might be ok

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: alternative ptp client

« Reply #462 on: 11 / December / 2013, 17:27:01 »

Agreed reyalp:

when I say i'm not a program[m]er, I mean [just a personal perspective]:

I think folk who learnt sequence / loop / conditional branch [in the old days, whether Assembly Language or Fortran77]] are at a real disadvantage to those of today who learn oop concepts from the outset [the mindset is different in my opinion (and probably the actual neural connections)].

At some level [sequence / loop / conditional branch] my old granny could [maybe] have been a programmer ?

So, in old money - if I can do something once I should be able to do it 100 [or 125] times ? [with a little prompting].

In the final analysis [I think] motivation / persistence can do - quite a bit [at least I hope so]

If at all possible i'll need to leave the "wrappers", inheritance, mvc etc etc etc to you guys...i was looking at vaadin [https://vaadin.com/home] today for a short while though

I can only wish I was [already] up to msl's high standards

Logged

andrew.stephens.754365

461

Re: alternative ptp client

« Reply #463 on: 12 / December / 2013, 12:17:03 »

So, installing another ".inf" got the second cam working [thanks again]

Currently just using the clipboard to grab the list info with autoit code:

Code: [Select]

$CopyScreen = "{ALTDOWN}{SPACE}{ALTUP}ES{ENTER}"
Send($CopyScreen)
$Count = 0
While $count < 4
 Sleep(500)
    $Count = $Count + 1
    Send($CopyScreen)
WEnd

clipboard content =>

Code: [Select]

___> list
-1:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0001--0x04a9-0x3234 v=0x4a9 p=0x3234 s=9A952438E0A647E9AC0179DDC30582D5
-2:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0002--0x04a9-0x3234 v=0x4a9 p=0x3234 s=689D5005104943C09E988E4EA8301E22
___>

What is the dev/bus connect string [as an example] for either of these - please ?

Edit: also see this to grab the console info:

http://chdk.setepontos.com/index.php?topic=10060.msg103939#msg103939

« Last Edit: 29 / December / 2013, 12:51:50 by andrew.stephens.754365 »

Logged

reyalp

14082

Re: alternative ptp client

« Reply #464 on: 12 / December / 2013, 16:18:30 »

Quote from: andrew.stephens.754365 on 12 / December / 2013, 12:17:03

-1:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0001--0x04a9-0x3234 v=0x4a9 p=0x3234 s=9A952438E0A647E9AC0179DDC30582D5
-2:Canon PowerShot SX150 IS b=bus-0 d=\\.\libusb0-0002--0x04a9-0x3234 v=0x4a9 p=0x3234 s=689D5005104943C09E988E4EA8301E22
What is the dev/bus connect string [as an example] for either of these - please ?

d=<dev string> b=<bus string>

Note that the connect command accepts these as a Lua pattern: http://www.lua.org/manual/5.1/manual.html#5.4.1 so if you want to use the whole string, you'd need to escape at least the - characters with %, like

Code: [Select]

connect -b=bus%-0 -d=\\.\libusb0%-0002%-%-0x04a9%-0x3234

edit: as pointed out below, bus - needs escaping too

(technically for an exact match you should also escape the . but it matches . so it's ok)

I will add an option to disable pattern matching, because allowing the use of list output directly seems worthwhile.

Also note that you can easily list devices in a different format if you want, e.g.

Code: [Select]

!t=chdk.list_usb_devices(); for i,d in ipairs(t) do printf("%s %s\n",d.bus,d.dev) end

« Last Edit: 15 / December / 2013, 16:31:38 by reyalp »

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: alternative ptp client

« Reply #465 on: 12 / December / 2013, 16:27:38 »

nice one - thanks

Edit:

works as expected [after escaping the hyphen following "bus"]:

Quote from: reyalp on 12 / December / 2013, 16:18:30

so if you want to use the whole string, you'd need to escape at least the - characters with %, like
Code: [Select]
connect -b=bus-0 -d=\\.\libusb0%-0002%-%-0x04a9%-0x3234

(i) first instance to capture "list"
(ii) 2nd instance with "connect -b=bus%-0 -d=\\%.\libusb0%-0001%-%-0x04a9%-0x3234"
(iii) 3rd instance with "connect -b=bus%-0 -d=\\%.\libusb0%-0002%-%-0x04a9%-0x3234"

as instructed, it worked without escaping the period - I just chose to do that.

« Last Edit: 13 / December / 2013, 05:33:36 by andrew.stephens.754365 »

Logged

tpont

81

Re: alternative ptp client

« Reply #466 on: 15 / December / 2013, 09:34:17 »

Hi, I have a setup where a computer calls chdkptp on the command line to do remote shoot (rs -jpg) commands. It now works reliaby with powershot A2300 and A490 after some issues earlier. But the cycle time until another remote shoot command can be reliably sent is still a bit long. Reyalp has helped me look into various speed optimization issues previously in this thread. Since some time has passed and I haven't kept track of developments here let my ask: Has there been any news on the cycle time front? Does anyone know of some new canon budget compact cameras with CHDK support that perhaps could lower the cycle time for remote shoot? Or any new developments in CHDK/chdkptp on the horizon that could lower cycle time?

« Last Edit: 15 / December / 2013, 09:35:52 by tpont »

Logged

waterwingz

12139

Re: alternative ptp client

« Reply #467 on: 15 / December / 2013, 09:38:22 »

Quote from: tpont on 15 / December / 2013, 09:34:17

But the cycle time until another remote shoot command can be reliably sent is still a bit long.

How long is "long"? And how long would you want it to be?

Logged

Ported : A1200 SD940 G10 Powershot N G16

openuas

58
OpenUAS

Re: alternative ptp client

« Reply #468 on: 15 / December / 2013, 13:47:16 »

@tpont, It would be great if you could make 100 pictures of same object, same lightning and no focus change and post the timestamps of the file written in a CVS here. Also a description of the cam settings, type , resolutions etc. etc. We can use this as a reference for others to compare how fast their shots are.

And:
If you set you camera even without CHDK to all manual with no scene dynamics that change, like variable brightness, into continuous shoot with 100 pictures (Tape shutter?) with the fastest SD you can have you have an idea of what the camera is capable of. Then added the overhead time of transferring a e.g. 3MB file over USB from camera RAM via -rs. Faster than this it will never be. If your current settings and tryout are ~20% above this value, great!. If they are e.g.500% above, surely looking into chdkptp sourcecode and lua scripts and settings will be needed.

Logged

tpont

81

Re: alternative ptp client

« Reply #469 on: 17 / December / 2013, 18:54:27 »

Quote from: waterwingz on 15 / December / 2013, 09:38:22

How long is "long"? And how long would you want it to be?

In a best case scenario I want a cycle time of 2 seconds for roughly parallel shots with two cameras. With roughly parallel I mean that the cameras can be up to 500 milisecs out of sync without any problem.

What I get in practice is a cycle time average a bit over 4 seconds. The test I calculated this average from included a few errors. With errors I mean when one of the cameras doesn't react to a shoot command because the camera hasn't finished its previous cycle yet. The errors appear because the cycle time of each camera appears to vary in practice so it is hard to know exactly when then next photo can be taken. To mitigate that problem I run a script that checks if two new jpg files are created in the harddrive destination folder soon after the shoot command. If only one or zero new jpg files are detected after a certain number of miliseconds a notification pops up asking for a reshoot and any jpg from the error shoot is discarded.

A manually shot sequence of photos in continous mode with a single camera (button held down) in the same conditions takes on average 1.9 seconds per shot when saving to the SD card in the camera.

« Last Edit: 17 / December / 2013, 18:57:29 by tpont »

Logged