Jan 24 06:45:08 zeus kernel: [721933.564704] usb 1-2: usbfs: interface 0 claimed by usbfs while 'chdkptp' sets config #1Jan 24 06:45:08 zeus kernel: [721933.564731] usb 1-2: usbfs: process 21919 (chdkptp) did not claim interface 0 before useJan 24 06:45:08 zeus kernel: [721933.730040] usb 1-2: reset high-speed USB device number 99 using xhci_hcdJan 24 06:45:18 zeus kernel: [721944.331886] usb 1-2: USB disconnect, device number 99
Hi all,Using chdkptp build 694 pulled from assembla.com/svn/chdkptp/trunk, running it on Ubuntu 15.10 x86_64. I have a script giving chdkptp commands every n minutes. Script works 100% correctly about 95% of the time.. Failure symptom at most basic level is, chdkptp cannot connect to the IXUS160. It sees no devices on the USB bus. Occasionally, I see this error in /var/log/syslog at same time my script fails (eg chdkptp fails to connect to the camera)
Code: [Select]Jan 24 06:45:08 zeus kernel: [721933.564704] usb 1-2: usbfs: interface 0 claimed by usbfs while 'chdkptp' sets config #1Jan 24 06:45:08 zeus kernel: [721933.564731] usb 1-2: usbfs: process 21919 (chdkptp) did not claim interface 0 before useJan 24 06:45:08 zeus kernel: [721933.730040] usb 1-2: reset high-speed USB device number 99 using xhci_hcdJan 24 06:45:18 zeus kernel: [721944.331886] usb 1-2: USB disconnect, device number 99
Confirm that I do have the udev rule in place which prevents libGphoto from grabbing the cam.. I did not see the cam's signature in /lib/udev/hwdb.d/20-libgphoto2-6.hwdb, but I could have missed it..
I don't really have an idea what could be going on. Some search results mention problems with USB 3 - is the port you're using USB 2.0 or 3?
Can you give a bit more information about how the script works? Do you have an external process (shell script, cron job etc) launching chdkptp for each command?How much time is there between commands? If you try to connect very soon after disconnecting, you may run into trouble.What state is the camera in after the script fails? Is the the camera still on, or has it crashed? If it's on, can you interact with it using the physical keyboard?
/usr/bin/screen -p 0 -S remoteshoot-c -X stuff "!status,msg=cli:execute'connect -b=001 -p=0x32aa -s=5B362D50A2E345DB8EE3558CFD0A7030' if msg then print(msg) end if not status then os.exit(1) end$CRLF"ERRLVL1="$?"#echo "$(timestamp) canon_job: exec chdkptp connect via lua, errlvl $ERRLVL1"if [[ "$ERRLVL1" -ne "0" ]]; thenexit 1fisleep 4
When it fails like, is the number always 99?One thing that comes to mind is that the chdkptp code does a USB reset on disconnect. This is something I blindly copied from the the original ptpcam code.
It is USB 3.0 - Intel NUC 54250WYK http://www.intel.com/content/www/us/en/nuc/nuc-kit-d54250wyk.html
Script is a wrapper to execute chdkptp commands. (2) cameras are connected via USB bus; cameras have a shorted ON/OFF switch; powered on via wrapper script -> who calls an arduino application to close a relay.Chdkptp is run " -i " inside a gnu 'screen' session. Chdkptp operational commands are fed into the screen-session. Wrapper script sleeps between 3-5 seconds between chdkptp commands - to give the camera a chance to respond.
Example of wrapper script executing chdkptp command below; I do not yet pass the camera serial number as a variable (it's on the list.)
Jan 24 06:45:08 zeus kernel: [721933.564704] usb 1-2: usbfs: interface 0 claimed by usbfs while 'chdkptp' sets config #1Jan 24 06:45:08 zeus kernel: [721933.564731] usb 1-2: usbfs: process 21919 (chdkptp) did not claim interface 0 before use
Re: the dev id number 99; No, that number increments once each time the usb device is seen by the host PC. After a few hundred iterations and no NUC reboot, the number is, well, a few hundred, I guess.
It may be that the chdkptp usb-reset you mentioned is what's biting me..
I played a little with multicam, but got hung up on making it exec 'remoteshoot' - which is quite handy for me. I *could* simply have my wrapper let multicam save to SDcard, then go get images from SDcard instead of remoteshoot, but it was more code.. gotta not be lazy..
connect -s=<cam 1 serial>!cam1_con=conconnect -s=<cam 2 serial> -nodis!cam2_con=con
!con=cam1_conremoteshoot ....!con=cam2_conremoteshoot...
I'm still a little unclear how this works. You start one chdkptp session in each screen, end then feed individual CLI commands periodically?
If this is correct, does the chdkptp connect only happen when the screen is first started, or do you connect/disconnect for each command?
In general, I'd suggest leaving the connection open, but this may cause problems connecting by serial number.
Example of wrapper script executing chdkptp command below; I do not yet pass the camera serial number as a variable (it's on the list.) Note that connecting by serial number attempts to make a connection to every camera on the USB bus, to get the serial number (the same is true for connecting by name, but not bus, device or product id). If there are other instances of CHDKPTP with active connections you will probably see messages like you reported:Code: [Select]Jan 24 06:45:08 zeus kernel: [721933.564704] usb 1-2: usbfs: interface 0 claimed by usbfs while 'chdkptp' sets config #1Jan 24 06:45:08 zeus kernel: [721933.564731] usb 1-2: usbfs: process 21919 (chdkptp) did not claim interface 0 before usein the log. I would not be surprised if this caused problems. I thought it completely killed the other connection, but in a quick test on ubuntu 14.04 it didn't seem to. It may depend on the specific linux verion, distro, hardware etc. In any case, I would not recommend connecting by name or serial number when using more than one instance of chdkptp.This makes connecting to multiple cameras of the same model awkward. One option would be to do a "list" in one instance of chdkptp, and then use the device and bus info to connect the remaining instances. However, the device number may change if the camera is reconnected, rebooted etc.
If your application doesn't require the cameras to shoot at the same moment with the exact same settings, multicam may not be a very good solution.If you want to control multiple cameras, without shooting at the same time, you can just swap the global connection object (named con) around and use normal cli commands. e.gCode: [Select]connect -s=<cam 1 serial>!cam1_con=conconnect -s=<cam 2 serial> -nodis!cam2_con=conThe -nodis option tells chdkptp not to close the existing connection when it connects to the new camera.Now you have two connection objects, and you can just set con to point to the one you want to control, likeCode: [Select]!con=cam1_conremoteshoot ....!con=cam2_conremoteshoot...Within a single chdkptp session, it's OK to connect to multiple cams by serial number, because it's aware of the existing connection.If you do want to trigger the shutters at the exact same moment, remoteshoot is probably not good solution. While you could theoretically implement it with multicam, the actual data download would be sequential anyway so there wouldn't be much advantage over shooting and doing a image download/delete after.
I believe I am leaving the chdkptp connection open in the manner that I think you suggest.
chdkptp post_levent_to_ui Off command is given, sleep 1
Yes, I understand now. I thought that using serial number would be the way to avoid contention / disruption on usb bus (in the case where >1 cameras are present, and >1 instances of chdkptp were running.)
Yes, I can see now, after this information, (Thanks, btw! :-D) that the way I've implemented chdkptp operations is likely the cause of the error.
QuoteQuoteWithin a single chdkptp session, it's OK to connect to multiple cams by serial number, because it's aware of the existing connection.If you do want to trigger the shutters at the exact same moment, remoteshoot is probably not good solution. While you could theoretically implement it with multicam, the actual data download would be sequential anyway so there wouldn't be much advantage over shooting and doing a image download/delete after.Yes, I can see now, after this information, (Thanks, btw! :-D) that the way I've implemented chdkptp operations is likely the cause of the error. I'm going to experiment with multicam, but with info you've given, I can also see how to continue with 'chdkptp remoteshoot' - by implementing a single chdkptp session that is speaking to multiple cameras - rather than having multiple chdkptp sessions speaking to a single cam. Thanks again for the help.I confirm that the strange usb error was due to multiple instances of chdkptp 'remoteshoot' colliding with each other. I fixed my code to use a single chdkptp instance; no errors since. Substituting multicam for remoteshoot also works fine.
QuoteWithin a single chdkptp session, it's OK to connect to multiple cams by serial number, because it's aware of the existing connection.If you do want to trigger the shutters at the exact same moment, remoteshoot is probably not good solution. While you could theoretically implement it with multicam, the actual data download would be sequential anyway so there wouldn't be much advantage over shooting and doing a image download/delete after.Yes, I can see now, after this information, (Thanks, btw! :-D) that the way I've implemented chdkptp operations is likely the cause of the error. I'm going to experiment with multicam, but with info you've given, I can also see how to continue with 'chdkptp remoteshoot' - by implementing a single chdkptp session that is speaking to multiple cameras - rather than having multiple chdkptp sessions speaking to a single cam. Thanks again for the help.
Within a single chdkptp session, it's OK to connect to multiple cams by serial number, because it's aware of the existing connection.If you do want to trigger the shutters at the exact same moment, remoteshoot is probably not good solution. While you could theoretically implement it with multicam, the actual data download would be sequential anyway so there wouldn't be much advantage over shooting and doing a image download/delete after.
Started by andre117 General Discussion and Assistance
Started by toby LUA Scripting
Started by JvdP « 1 2 » General Discussion and Assistance
Started by axman General Help and Assistance on using CHDK stable releases
Started by STEREO_A General Help and Assistance on using CHDK stable releases
