chdkptp - alternative ptp client - page 88 - General Discussion and Assistance - CHDK Forum supplierdeeply

chdkptp - alternative ptp client

  • 1097 Replies
  • 399644 Views
Re: alternative ptp client
« Reply #870 on: 05 / December / 2015, 09:40:54 »
Advertisements
Seeming bug in r690 multicam.lua (repeated concatenated optional parameter sent):

As workaround (until fully tested), in function:

Code: [Select]
mc:cmd(cmd,opts)I changed this:

Code: [Select]
if opts.syncat then
sendcmd = string.format('%s %d',cmd,self:get_sync_tick(lcon,tstart,opts.syncat))
end
if opts.args then
sendcmd = sendcmd..' '..opts.args
end
to this:

Code: [Select]
if opts.syncat and opts.args then
sendcmd = string.format('%s %d',cmd,self:get_sync_tick(lcon,tstart,opts.syncat))
sendcmd = sendcmd..' '..opts.args
end
if opts.args then
sendcmd = cmd..' '..opts.args
end

Edit: syncat only to be added...
« Last Edit: 05 / December / 2015, 12:09:45 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 13457
Re: alternative ptp client
« Reply #871 on: 05 / December / 2015, 15:37:16 »
Thanks. This should be fixed in r691.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #872 on: 18 / December / 2015, 18:34:31 »
thanks reyalp! love it, especially the live-view! do you think you can make the window larger?
i am using it with an ixus 160 ...
« Last Edit: 18 / December / 2015, 18:43:11 by harpmaster »

*

Offline reyalp

  • ******
  • 13457
Re: alternative ptp client
« Reply #873 on: 18 / December / 2015, 20:01:46 »
thanks reyalp! love it, especially the live-view! do you think you can make the window larger?
i am using it with an ixus 160 ...
Currently, the largest display is what you get when "viewfinder 1:1" is checked. This is essentially the native resolution of the camera live view (in luminance, color is significantly lower res). It would be possible to scale this up, but you wouldn't get more detail.
Don't forget what the H stands for.


Re: alternative ptp client
« Reply #874 on: 21 / December / 2015, 07:16:40 »
Issue: multicam.lua shoot_hook_sync - get_shooting does not go false in wait_timeout_write_status when raw enabled (set via CCHDK4.CFG), ok with jpg only.

Tested in Auto mode with a single camera (sx150is-100a-1.4.0-4297-full).

CLI listing ok with raw off (CCHDK4.CFG used attached as txt)

Code: [Select]
___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
8E0A647E9AC0179DDC30582D5
___> !mc:start()
___> !return mc:cmdwait('rec')
rec
=true,{
 [1]={
  status={
   status=true,
   cmd="rec",
  },
  done=true,
  failed=false,
 },
}
___> !return mc:cmdwait('set_mode',{args=1})
set_mode 1
=true,{
 [1]={
  status={
   status=true,
   cmd="set_mode",
  },
  done=true,
  failed=false,
 },
}
___> !return mc:init_sync()
1: send 5 diff 31 pred=54111 r=54120 delta=-8
1: send 3 diff 66 pred=54146 r=54150 delta=-3
1: send 8 diff 136 pred=54216 r=54220 delta=-3
1: send 3 diff 167 pred=54247 r=54250 delta=-2
1: send 3 diff 197 pred=54277 r=54280 delta=-2
1: send 3 diff 229 pred=54309 r=54310 delta=0
1: send 11 diff 254 pred=54334 r=54350 delta=-15
1: send 3 diff 299 pred=54379 r=54380 delta=0
1: send 9 diff 337 pred=54417 r=54430 delta=-12
1: send 8 diff 369 pred=54449 r=54460 delta=-10
1: ticks=10 min=-15 max=0 mean=-6.487800 sd=5.062612
1: sends=10 min=3 max=11 mean=5.600500 sd=2.939558
minimum sync delay 8
___> !return mc:cmdwait('preshoot')
preshoot
=true,{
 [1]={
  status={
   status=true,
   cmd="preshoot",
  },
  done=true,
  failed=false,
 },
}
___> !return mc:cmdwait('shoot_hook_sync',{syncat=100})
shoot_hook_sync [sync +100]
=true,{
 [1]={
  status={
   status=true,
   cmd="shoot_hook_sync",
  },
  done=true,
  failed=false,
 },
}
___>

CLI listing timeout with raw ON (increasing shoot_complete_timeout from 5000 to 7500 made no difference)

Code: [Select]
___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
8E0A647E9AC0179DDC30582D5
___> !mc:start()
___> !return mc:cmdwait('rec')
rec
=true,{
 [1]={
  status={
   cmd="rec",
   status=true,
  },
  done=true,
  failed=false,
 },
}
___> !return mc:cmdwait('set_mode',{args=1})
set_mode 1
=true,{
 [1]={
  status={
   cmd="set_mode",
   status=true,
  },
  done=true,
  failed=false,
 },
}
___> !return mc:init_sync()
1: send 3 diff 38 pred=117508 r=117510 delta=-1
1: send 4 diff 131 pred=117601 r=117610 delta=-8
1: send 3 diff 199 pred=117669 r=117670 delta=0
1: send 36 diff 237 pred=117707 r=117740 delta=-32
1: send 39 diff 301 pred=117771 r=117810 delta=-38
1: send 34 diff 435 pred=117905 r=117940 delta=-34
1: send 4 diff 536 pred=118006 r=118010 delta=-3
1: send 67 diff 572 pred=118042 r=118110 delta=-67
1: send 31 diff 669 pred=118139 r=118170 delta=-30
1: send 8 diff 739 pred=118209 r=118220 delta=-10
1: ticks=10 min=-67 max=0 mean=-23.277800 sd=20.523779
1: sends=10 min=3 max=67 mean=22.901500 sd=20.720543
minimum sync delay 43
___> !return mc:cmdwait('preshoot')
preshoot
=true,{
 [1]={
  status={
   cmd="preshoot",
   status=true,
  },
  done=true,
  failed=false,
 },
}
___> !return mc:cmdwait('shoot_hook_sync',{syncat=100})
shoot_hook_sync [sync +100]
=true,{
 [1]={
  status={
   cmd="shoot_hook_sync",
   msg="get_shooting timeout",
   status=false,
  },
  done=true,
  failed=false,
 },
}
___>

Should raw setting make any difference?

Edit.
loosely related follow-up...I had originally used
Code: [Select]
savecon=con for i,lcon in ipairs(mc.cams) do con=lcon cli:print_status(cli:execute('u -nolua B.Slave_GUI/For_Slave_chdk-configs/RAW_ON_CCHDK4.CFG chdk/CCHDK4.CFG')) end con=savecon)to upload the raw ON config file after having completed the first jpg only shot but was not surprised to find the new config file setting was not used in the second shot (the raw shot).

Using this method is it known if the raw setting in the file would only take effect the next time chdk was loaded?

(wasn't sure if this could be better placed in sx150 porting thread...or somewhere)



Further info:
Base used was multicam-r692

Addition to camera script
Code: [Select]
capmode=require("capmode")
function cmds.set_mode()
--e.g. to run !return mc:cmdwait('set_mode',{args=1})

--1 -> AUTO
--2 -> P
--3 -> TV
--4 -> AV
--5 -> M

local new_mode = tonumber(mc.args)

capmode.set(new_mode)
wait_timeout_write_status(capmode.get,new_mode,100,mc.mode_sw_timeout)
end
« Last Edit: 21 / December / 2015, 09:41:55 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 13457
Re: alternative ptp client
« Reply #875 on: 21 / December / 2015, 14:11:00 »
Issue: multicam.lua shoot_hook_sync - get_shooting does not go false in wait_timeout_write_status when raw enabled (set via CCHDK4.CFG), ok with jpg only.

get_shooting() should go false after the raw finishes saving. This appears to work correctly on D10. If you have review on, it will probably wait for the review time too, but this shouldn't be directly affected by raw.

I would suggest trying with the timeout set to something large, like 20 seconds.
Quote
loosely related follow-up...I had originally used
Code: [Select]
savecon=con for i,lcon in ipairs(mc.cams) do con=lcon cli:print_status(cli:execute('u -nolua B.Slave_GUI/For_Slave_chdk-configs/RAW_ON_CCHDK4.CFG chdk/CCHDK4.CFG')) end con=savecon)to upload the raw ON config file after having completed the first jpg only shot but was not surprised to find the new config file setting was not used in the second shot (the raw shot).

Using this method is it known if the raw setting in the file would only take effect the next time chdk was loaded?
CHDK does not expect the cfg files to be changed externally while it's running! If you want to change the raw setting, use set_raw() or set_config_value(). You can use the 'call' command to send the Lua code in multicam, e.g. mc:cmdwait('call set_raw(true)')

If you want to upload cfg files, you should upload them and reboot the camera immediately, if any settings are change on the camera before rebooting, CHDK will probably overwrite the new CFG. Alternately, use one of the Lua scripts that saves and loads cfg values.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #876 on: 21 / December / 2015, 15:38:57 »
10 secs works reliably...your note reminded me  to list "review off" for inclusion in canon initialisation script  ::)

Thanks for various cfg options - pretty sure upload can be excluded as a contender.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #877 on: 24 / February / 2016, 13:36:27 »
@reyalp: a question about the -pipe option for rsint that was added in r690, https://www.assembla.com/spaces/chdkptp/subversion/commits/688 .

I have managed to use it to have an external process trigger the camera shoot. But is there also some way to read the message chdkptp returns on a successful shoot? After doing e.g. "rsint -pipe=C:\external.exe" the cmd window does not display anything when the camera shoots.

I have without success tried reading the StdIn of the external process. But I don't know if there is a problem with my code for reading StdIn or if chdkptp doesn't return anything there. Or perhaps I am missing something else.


*

Offline reyalp

  • ******
  • 13457
Re: alternative ptp client
« Reply #878 on: 24 / February / 2016, 16:07:04 »
I have managed to use it to have an external process trigger the camera shoot. But is there also some way to read the message chdkptp returns on a successful shoot?
Short answer: There isn't. Lua popen doesn't let you open a bi-directional pipe, so chdkptp can't send anything to to the control process.

If you want to read chdkptp output, you would need have your program start chdkptp from your process with chdkptp stdin and stdout connected. The main advantage of the -pipe option over this is it lets you use a very simple executable, e.g. if you want to control shooting with external hardware on something like a raspberry pi, you could have a very simple program that outputs s when it sees a particular value on a GPIO.
Don't forget what the H stands for.

*

Offline tpont

  • **
  • 81
Re: alternative ptp client
« Reply #879 on: 25 / February / 2016, 05:13:32 »
Ok, good to know.

If you want to read chdkptp output, you would need have your program start chdkptp from your process with chdkptp stdin and stdout connected.
Yes, but I haven't been able to write a program that starts, stdin/stdout connects *and* keeps two chdkptp processes throughout a session of taking many rsint shots.

 

Related Topics