Using ptp and remote operations for full body scanner - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum

Using ptp and remote operations for full body scanner

  • 23 Replies
  • 2497 Views
Re: Using ptp and remote operations for full body scanner
« Reply #20 on: 20 / September / 2017, 00:52:00 »
Advertisements
Quote
was libusb installed for all cameras at that time?
For some reason libusb didn't like ptpdrive and wouldn't work with it, the cameras were just running winusb.

Do you think the "usb trigger that appears to be an and gate" simply switches mains power on/off to the single powered hub into which the 3 manhattan hubs are plugged?
Strangely enough the switch works with both powered and unpowered hubs, you just have to hold it a bit for it to work on the powered ones.
When I used (windows) PtpDrive, some time ago, the "...reason libusb didn't like ptpdrive and wouldn't work with it...".
Was that PtpDrive used its custom PtpDrive-Service that communicates directly with the canon camera. 
i.e.  A direct conflict with the LibUSB-Service.
Also windows uses a driver "Rank" scheme, so windows may rank the drivers:-
1/ PtpDrive, 2/ WinUsb, 3/ LibUsb. i.e "...Windows has determined the best Driver...is used..."

Ref:- Reply #4 on: 15/September/2017
Re:- "...via a "Powered" USB-Hub switch, there are several major problems to consider..."

"...Strangely enough the switch works with both powered and unpowered hubs,..."

This probably because the manhattan hubs have an alternate +5 volt (low) power source via the
host computer USB-Ports.
They will usually have some type of current limiting, most probably a polyswitch (polyfuse).
IF you are shorting out the USB's +5 volt power via your "usb trigger" there will be all kinds of problems including
very poor camera sync because you are now also attempting to discharge any internal filter capacitors.
AND also possibly tripping the polyfuse's.

Edit, Option #1:- Using a Serial Port as a output to sync/trigger all the cameras. i.e. via a "HOT-Key"
Here  https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/faq.en.htm
"...I want to control some hardware (e.g. camera shutter, telescope positioner, LC display) with some output lines.
Seems that USB2LPT is the perfect solution? 
https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/root/hs/sht11.zip/seriell.png?bin=PNG
No, USB2LPT is not perfect, however, suitable..."

The disadvantages are:-
  • relatively unstable operation due to hardcore driver programming
  • currently not portable to non-Windows systems
  • driver installation necessary on target systems (it's annoying to most users)
  • USB2LPT is not in mass production, it's hand-made in low counts
There are also some very similar software and hardware options using the legacy serial port.

Edit, Option #2:- A USB-Serial adapter, plugged into your USB-Hub can also be used.
        As per Option #1, a output is then used to trigger/sync all the cameras via a
        +5 volt control wire common to all the cameras but independent of the USB-Hubs.
        Some additional control software and interface electronics will then be required.

#1 & #2 Are very similar to the usual +5volt Chdk trigger method, but modified for use
             the all the cameras in your multi-cam array.

H-H

Continued in post #21 - more about the USB Canon Cameras and LibUSB Drivers ...problem
« Last Edit: 22 / September / 2017, 00:41:56 by Hardware_Hacker »

Re: Using ptp and remote operations for full body scanner
« Reply #21 on: 21 / September / 2017, 20:40:41 »
Continued from the above post #20 - ... (a wip)

More detail about the above windows USB Driver conflict/rank problem and what to do.
(Occasionally this type of windows LibUSB driver problem is in various CHDK posts.)

If you luck-in the solution is usually very simple, just un-install PtpDrive (or similar Ptp/MtP) and then re-install LibUSB.

If you luck-out the solution can become very complex and some of this windows stuff below can occur:-

a/ Windows, the "Trusted Installer" system, will place "Restricted Access" on the USB Driver's files and registry.
b/ Windows, the "Trusted Installer" system, will create multiple/hex copies of the USB Driver's files.
c/ Windows, the "Trusted Installer" system, will insist on only installing/using the "Trusted/Approved/Restricted"
    USB Driver's files.
d/ Windows the "Trusted Installer" system will refuse to delete the "Trusted/Approved/Restricted" the USB Driver's
     files.

There are various ways to then ensure LibUSB is the correctly installed for your canon cameras.
The simplest is just to do a new and clean windows installation, most of the others are just to complex
to describe in this post.

However if you have a "Special/Stand-Alone" multi-cam project, a possibility, is to stop windows from
generically recognizing the "Generic Imaging/Camera Class" this can be done via a simple, reversible, edit in the
*:\windows\inf\Ptp/MtP.inf files.
The effect is then to, permanently, stop windows recognizing the canon cameras then re-installing the "Trusted/Approved" generic USB Mtp/PtP Driver's files.

The correct installation and maintenance of the LibUSB drivers is then much simpler.

Example #1:- In Win-8 & 10, WinUsb.inf  "...pnplockdown=1                       ; Third Party Protected..."

Ref & Example #2:- https://docs.microsoft.com/en-us/windows-hardware/drivers/install/inf-version-section.

"... If the PnpLockDown directive is set to 1, PnP prevents applications from directly modifying the files..."
"....To ensure the integrity of a PnP driver installation, applications should not directly modify driver files that are copied by the driver package INF file. Applications should only use the device installation mechanisms provided by Windows to update PnP drivers...."

Ref & Example #3:-  https://msdn.microsoft.com/library/windows/hardware/ff553419
                                 "..System-Defined Device Setup Classes..."

i.e. If you luck-out the solution's can become EXTREMELY complex.... etc, etc.

Note #:- This is the important part for LibUSB,  and also the generic part to be disabled.
Here https://msdn.microsoft.com/en-us/library/windows/hardware/ff553426
"...System-Defined Device Setup Classes Available to (CHDK Multi-Cam)  Vendors..."
"....Imaging Device  Class = ImageClassGuid = {6bdd1fc6-810f-11d0-bec7-08002be2092f}..."
"....This class includes still-image capture devices, digital cameras, and scanners...."
 
"...Generic....Imaging Device...."      Compatible ID:-
USB\CLASS_06&SUBCLASS_01&PROT_01
USB\CLASS_06&SUBCLASS_01
USB\CLASS_06

Disable this "MTP, USB\Class_06&SubClass_01&Prot_01"

It worked OK for me, some time ago, But should only be used, as a last resort, if everything else fails.

To be continued ..... (a wip)

H-H
« Last Edit: 22 / September / 2017, 03:03:39 by Hardware_Hacker »

Re: Using ptp and remote operations for full body scanner
« Reply #22 on: 22 / September / 2017, 02:40:41 »
This could also be useful.

Sometime last year I experienced a problem on a Win 7 Pro machine.

When libusb had been installed for a particular camera then chdkptp would only subsequently connect if the camera was inserted to the same physical usb port when libusb had been originally installed.

If I wish to now connect a camera to a different usbhub (or even a different port on the same hub), I:
  • use nirsoft usbdeview to delete the libusb driver
  • delete all files created by libusb in the relevant directory it had originally requested they be installed in
  • turn camera on & reinstall libusb 

*

Online reyalp

  • ******
  • 11895
Re: Using ptp and remote operations for full body scanner
« Reply #23 on: 22 / September / 2017, 17:12:10 »
When libusb had been installed for a particular camera then chdkptp would only subsequently connect if the camera was inserted to the same physical usb port when libusb had been originally installed.
FWIW, I have seen this behavior consistently on older cameras the do not report a serial number over USB. In that case, to make it work on another port libusb setup just needs to be run again. It's actually kind of nice to be able to switch between standard OS access and chdk this way.

I have never had do any of the things described in H_H's post, as far as I can understand.
Don't forget what the H stands for.


 

Related Topics