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

chdkptp - alternative ptp client

  • 1106 Replies
  • 517665 Views
Re: alternative ptp client
« Reply #290 on: 28 / January / 2013, 08:47:28 »
Advertisements
Should it be possible to run the chdkptp client (via the command line) with multi cameras at the same time?

I've got one camera scripted to take a photo every 40 seconds and if I attach another camera it will generally connect fine but there's often libusb errors and not all commands will excute safely. I'll get some examples of the output soon.

I'm using the serial number of the cameras to connect to them with their respective scripts so there's no issues of connecting to the wrong/same camera.

If it isn't something I should be doing that's fine, just wondering if people have managed to run the client with multiple cameras?

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #291 on: 28 / January / 2013, 17:16:42 »
Should it be possible to run the chdkptp client (via the command line) with multi cameras at the same time?
Yes. You can either control multiple cameras from a single instance of chdkptp, or (if you are careful) run multiple instances.

Quote
I'm using the serial number of the cameras to connect to them with their respective scripts so there's no issues of connecting to the wrong/same camera.
Unfortunately, this doesn't work as you'd expect. To determine the serial number, chdkptp needs to create a temporary connection. This will disrupt any other clients connected to the device who's serial is being queried. If you use one instance of chdkptp, then it can get the serial number without resetting existing connections. However, controlling multiple cameras is only supported in the lua API, not the cli. You can see the 'multicam.lua' module for an example.

IIRC seeing kernel log messages with the serial number, which suggests there might be a way to get this without a full connection (since the kernel presumably already has it). If anyone knows how to do this, I'd be happy to add support to chdkptp (if possible).

edit:
Another thing on my TODO list is to not to attempt to connect to cameras that already have an active connection, so when connecting by serial, it would only query cameras unconnected cameras. I think this should be doable, but I haven't got around to working on it yet.
« Last Edit: 28 / January / 2013, 17:19:34 by reyalp »
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: alternative ptp client
« Reply #292 on: 29 / January / 2013, 03:50:05 »
Having a strange problem with chdkptp (revision 323) and all current CHDK versions (release-1.1, trunk and philmoz-action-stack).

Using the GUI, I connect the camera and double click 'Camera' on the Files tab.
I then select the CHDK directory and right click and select 'Upload directory contents'.
I select the CHDK directory from my build folder and click Ok.

It will then upload some of the files to the camera before locking up chdkptp (shows as 'Not responding' in Windows). Turning off the camera will bring chdkptp back to life; but not all files have been uploaded.

Tested on G1X and G12 so far - happens on both.

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

Re: alternative ptp client
« Reply #293 on: 29 / January / 2013, 06:00:59 »
Yes. You can either control multiple cameras from a single instance of chdkptp, or (if you are careful) run multiple instances.

What is the careful way of doing it via multiple instances? My current setup is one camera taking a photo every 40 seconds. This is a case of a script with chdkptp, ftp upload etc running as a cronjob every 40 seconds. The second camera is activated via a motion sensor. When the sensor detects motion the RPi runs a script which takes some photos from the second camera using chdkptp then ftp uploads etc.

Quote
Unfortunately, this doesn't work as you'd expect. To determine the serial number, chdkptp needs to create a temporary connection. This will disrupt any other clients connected to the device who's serial is being queried.

Would it be better to use the pid or dev number to connect? Does this prevent chdkptp having to query for a serial number?

Quote
IIRC seeing kernel log messages with the serial number, which suggests there might be a way to get this without a full connection (since the kernel presumably already has it). If anyone knows how to do this, I'd be happy to add support to chdkptp (if possible).

edit:
Another thing on my TODO list is to not to attempt to connect to cameras that already have an active connection, so when connecting by serial, it would only query cameras unconnected cameras. I think this should be doable, but I haven't got around to working on it yet.

It is good to know you're thinking of doing more with it. I really do love chdkptp, it's a dream for automated high quality photo capture. I'm definitely going to be using it more after buying a job lot of 18 "broken" Canon compact cameras off ebay, 5 worked out of the box!


*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #294 on: 29 / January / 2013, 16:23:12 »
What is the careful way of doing it via multiple instances? My current setup is one camera taking a photo every 40 seconds.
By not using command that try to connect to all the available cameras. This includes "list" since it tries to show the name an serial (I should add an option to just show bus/dev)
Quote
Would it be better to use the pid or dev number to connect? Does this prevent chdkptp having to query for a serial number?
Yes, pid, dev and bus should fine.
Don't forget what the H stands for.

Re: alternative ptp client
« Reply #295 on: 30 / January / 2013, 08:12:42 »
Thanks. Connecting with pid has improved things greatly.

Re: alternative ptp client
« Reply #296 on: 08 / February / 2013, 08:47:50 »
I'd dearly love to get this working under OSX on a Mac, but I think may not be possible because the OSX version of libusb has problems claiming a usb device (because OSX gets exclusive control as soon as you plug a USB device in). This is certainly true for some devices (e.g. mass storage devices like disks and cards, as well as HID's) does anyone know if it's untrue for cameras?
The libusb page says
Quote
Darwin (Mac OS X) implementation has one limitation. If the OS has an interface driver that matches the characteristics of a device, it will seize the interface and the kernel driver cannot easily be detached. So libusb will not be able to use that interface. This is a particular problem with generic HID devices. For HID device,  HIDAPI is recommended.
No idea if this applies to PTP devices. If so, maybe a higher level API you can use for PTP commands ? In the long term, I hope to make things modular enough that you could change the underlying communication layer to something other than libusb. You'd expect that there should be some mechanism for camera vendors to support their PTP extensions in their own apps. It looks like there are remote capture apps for Mac (e.g. for Canon cameras that can do remote capture using the Canon SDK), so you might look into how those work.

IUP also does not have native support for OSX. I don't know if it runs under X11. Native OSX support is on their TODO list.
Hello,
I was able to compile IUP.3.7 and CD.5.6 for OSX 10.7 as dylib-s. I would be happy to upload them somewhere so someone else can confirm that they work and then send them to Tecgraf.
I didn't experienced the OSX libusb limitation with my cameras (powershot sx10 and A810). But experienced one other strange behavior:
after connecting the camera to USB port, camera will retract lens and turn of screen. (this is not happening in Ubuntu) Depending on settings in "Image Capture.app" the camera will be mounted to selected app (default is iPhoto. you can turn out mounting, but it has no impact on the behavior that I'm describing). Then I'm able connect to camera with chdkptp with working console, browse and liveview.  HW and chdkptp gui buttons are not working but that's porobably normal as I read in this forum. The real problem is switching to record mode with switch_mode_usb(1), which is not working and do something harm in camera. liveview and browsing is still working, but that's all. attempt to switch the camera off with HW button or command is freezing the camera.

I found one workaround for this behavior, but virtualbox is needed and it's not very practical. Create usb filter for one virtualbox host (in my case I it's ubutnu hots). Then when you connect USB cable, connect with chdkptp from virtualbox host, switch to record mode, disconect chdkptp, remove camera from virtualbox host usb devices. then the camera will now connect to OSX as before, but will not retract lens. you can browse content with iPhote OR can connect with chdkptp from OSX and the camera fill not freeze.

I wasn't able to discover what is the reason why this happens. Probably OSX send to camera command to switch to some mode from witch switch_mode_usb(1) is not working and the camera ignore this OSX command when camera already executed switch_mode_usb(1) from virtualbox host. I tried to add autostart script that call switch_mode_usb(1), but it didn't help.

in the attachment is fix for small bug that I found in lua/gui.lua

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #297 on: 09 / February / 2013, 17:26:34 »
Hello,
I was able to compile IUP.3.7 and CD.5.6 for OSX 10.7 as dylib-s.
Nice work.
Quote
I would be happy to upload them somewhere so someone else can confirm that they work and then send them to Tecgraf.
It might be more useful to describe what is required to build it (or perhaps provide a shell script that does everything). I'd be happy to include that in the documentation somewhere. I have no idea if tecgraf is interested in hosting binaries like this, but you could post on their mailing list.

Quote
The real problem is switching to record mode with switch_mode_usb(1), which is not working and do something harm in camera. liveview and browsing is still working, but that's all. attempt to switch the camera off with HW button or command is freezing the camera.
This definitely sounds like the OS is putting the camera in some state that isn't encountered on other platforms. I know nothing about OSX USB architecture (and relatively little about other platforms), so unfortunately I can't be any help there.

switch_mode_usb is pretty hacky, it's not really surprising that it can fail like this.

If you have the capability to sniff USB, you that might provide some clues. There might also be something recorded in the camera log when OSX does it's thing, which could point to functions or variables to poke in the firmware to get out of that state. See here http://chdk.wikia.com/wiki/Debugging#Logging_camera_console_output for information about getting camera log output.

Quote
in the attachment is fix for small bug that I found in lua/gui.lua
Thanks, added in r324. I also upped the timeout since 50 didn't seem to be enough on my d10 with the check actually working  :-[
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #298 on: 10 / February / 2013, 18:54:34 »
Using the GUI, I connect the camera and double click 'Camera' on the Files tab.
I then select the CHDK directory and right click and select 'Upload directory contents'.
I select the CHDK directory from my build folder and click Ok.

It will then upload some of the files to the camera before locking up chdkptp (shows as 'Not responding' in Windows). Turning off the camera will bring chdkptp back to life; but not all files have been uploaded.

Tested on G1X and G12 so far - happens on both.
Sorry for taking so long to respond, was buried in RL work.

It's normal for chdkptp to show "not responding" if it's busy for a while (lua script currently doesn't yield back to the gui until it's done). Of course, the upload should finish eventually. Uploading lots of small files is quite slow.

I was able to upload the CHDK directory from my SVN tree this way several times without problems.

If it is actually hanging, you can get some output in the cmd window by doing the following in the gui console
Code: [Select]
set gui_verbose=2
!util.util_stdout = io.stdout; util.util_stderr=io.stderr
Then all the normal status output will go to the cmd window, rather than the gui window, which allows you to see it as the upload is in progress. Because of the yielding issue mentioned above, output to the gui console does not appear until the entire script is finished.
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: alternative ptp client
« Reply #299 on: 10 / February / 2013, 21:41:03 »
Using the GUI, I connect the camera and double click 'Camera' on the Files tab.
I then select the CHDK directory and right click and select 'Upload directory contents'.
I select the CHDK directory from my build folder and click Ok.

It will then upload some of the files to the camera before locking up chdkptp (shows as 'Not responding' in Windows). Turning off the camera will bring chdkptp back to life; but not all files have been uploaded.

Tested on G1X and G12 so far - happens on both.
Sorry for taking so long to respond, was buried in RL work.

It's normal for chdkptp to show "not responding" if it's busy for a while (lua script currently doesn't yield back to the gui until it's done). Of course, the upload should finish eventually. Uploading lots of small files is quite slow.

I was able to upload the CHDK directory from my SVN tree this way several times without problems.

If it is actually hanging, you can get some output in the cmd window by doing the following in the gui console
Code: [Select]
set gui_verbose=2
!util.util_stdout = io.stdout; util.util_stderr=io.stderr
Then all the normal status output will go to the cmd window, rather than the gui window, which allows you to see it as the upload is in progress. Because of the yielding issue mentioned above, output to the gui console does not appear until the entire script is finished.


Thanks.

It is working - the chdkptp window was showing '(Not responding)' in the title bar as you said.

On my system the file names transferred appear in the gui console as they are transferred for the first dozen or so, then what appears to be blank lines are displayed with the window scrolling up and the scroll bar button getting smaller and smaller (indicating more content).

When it's finished the gui console refreshes with all the file names.

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)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

 

Related Topics