3D scanner with multiple IXUS160 cameras - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply

3D scanner with multiple IXUS160 cameras

  • 54 Replies
  • 24182 Views
Re: 3D scanner with multiple IXUS160 cameras
« Reply #20 on: 17 / August / 2017, 07:20:37 »
Advertisements
H-H,

could you provide a useful hint perhaps?

Having uninstalled libusb (nirsoft usbdeview right click uninstall selected devices then delete all relevant files/directories created by the inf-wizard i.e. no attempt to edit the registry manually) for 2 cameras, they appear in Win 7 as portable devices (supported by the regular canon driver).

It seems a useful exercise to attempt to automate the image download with the regular drivers & AutoIt e.g:
https://www.autoitscript.com/forum/topic/189569-copy-files-from-portable-device-to-pc-folder/ https://www.autoitscript.com/forum/topic/174338-get-portable-devices/

(Edit: or perhaps Multi Commander http://multicommander.com/docs/multiscript/languagesyntax)

If that should prove successful, can you imagine an (automated) method whereby the cameras are directed to pick either libusb or the regular driver at camera power on? (rather than uninstalling / reinstalling libusb for each).

For my record:
How Windows determines the most suitable device driver to install during Setup
https://support.microsoft.com/en-us/help/279112/how-windows-determines-the-most-suitable-device-driver-to-install-duri
« Last Edit: 17 / August / 2017, 09:45:07 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 12793
Re: 3D scanner with multiple IXUS160 cameras
« Reply #21 on: 17 / August / 2017, 14:06:43 »
So, for mc:init_sync(), the attached logs included:
minimum sync delay 128 (for M)
minimum sync delay 267 (for Auto)
I had (mistakenly) used syncat of 100 for both. Increasing that to 300 and, in Auto mode, mc:init_sync() followed by 15 consecutive preshoot -> shoot_hook_sync cycles worked without crash.
I very much doubt the sync time has anything to do with the crash. If the crash is an electrical problem, then it's possible that more closely synced shots would be more likely to crash, since the cameras would be shooting closer together.
Quote
My current suspicion is as per your quote at the top of this message.
I don't understand why you would think that problem was in any way related to yours.

Quote
On the off-chance there's something useful in a crash example please find romlog attached (on camera time is not current).
Did you verify that the timestamp in the romlog matches the time the crash occurred? I.e. is the camera date something close to April 2015?

The crash is in ChaseFrame which has something to do with face tracking. Auto mode generally has face tracking features enabled, where it would be optional in manual mode. There have been some other cases where these features interacted badly with CHDK.


Quote

It seems a useful exercise to attempt to automate the image download with the regular drivers & AutoIt e.g:
https://www.autoitscript.com/forum/topic/189569-copy-files-from-portable-device-to-pc-folder/ https://www.autoitscript.com/forum/topic/174338-get-portable-devices/
Why would you want to do this rather than using chdkptp to download? Switching back and forth between drivers just seems like asking for trouble. Also, if the cameras are accessed by the native windows PTP driver, you need to reboot them before you can use chdkptp to shoot, because using normal PTP commands puts them in a state where they can no longer switch to rec mode.
Don't forget what the H stands for.

Re: 3D scanner with multiple IXUS160 cameras
« Reply #22 on: 17 / August / 2017, 18:01:19 »
I very much doubt the sync time has anything to do with the crash.

Agreed.

I had become confused (without sufficiently examining the code) that if the value "tonumber(mc.args)" [in multicam.lua "function cmds.shoot_hook_sync()"] was less than the current camera tick at the time the value was passed to "function wait_tick(synctick)" the logic of that function could not handle this case and would cause the crash.

I now see that if that is the case then function "wait_tick(synctick)" calculates "local s" as a negative number and control is immediately passed back to "cmds.shoot_hook_sync()" which then immediately allows the shooting process to continue from the hook point.

If the crash is an electrical problem, then it's possible that more closely synced shots would be more likely to crash, since the cameras would be shooting closer together.

By increasing the Auto syncat from 100 to 300 (in light of mc:init_sync() minimum sync delay 267) it seems more closely synced shots would result. Since the crash did not then occur until the download stage it seems likely, from what you say, that the crash is not an electrical problem.   

In summary, I understand why my lowball syncat would not be involved in the crash but don't understand why better sync (via higher syncat) solved the crash (if it was that).
 
I don't understand why you would think that problem was in any way related to yours.

Because the current crash while downloading the larger Auto (cf M) generated images involves greater data transfer time & therefore more time for possible electrical glitches or libusb glitches or... 

Did you verify that the timestamp in the romlog matches the time the crash occurred? I.e. is the camera date something close to April 2015?

Yes (same date as romlog file)

The crash is in ChaseFrame which has something to do with face tracking. Auto mode generally has face tracking features enabled, where it would be optional in manual mode. There have been some other cases where these features interacted badly with CHDK.

Ok, thanks - i'll look into that

Why would you want to do this rather than using chdkptp to download? Switching back and forth between drivers just seems like asking for trouble. Also, if the cameras are accessed by the native windows PTP driver, you need to reboot them before you can use chdkptp to shoot, because using normal PTP commands puts them in a state where they can no longer switch to rec mode.

I don't - it's a nightmare option of last resort.

*

Offline reyalp

  • ******
  • 12793
Re: 3D scanner with multiple IXUS160 cameras
« Reply #23 on: 18 / August / 2017, 00:57:59 »
Because the current crash while downloading the larger Auto (cf M) generated images involves greater data transfer time & therefore more time for possible electrical glitches or libusb glitches or... 
FWIW, the poster of the previous issue (gaphill) had very clear reasons to believe they had electrical problems, and my comment was that file transfers would be a lot more likely to hit such problems than other PTP operations like running script.

Running some test on battery power like gaphill did could help determine whether power supply issues are involved.

Do you get the ChaseFrame crash happen when shooting, or downloading? If it does happen while downloading, you could try switching to play mode (or a shooting mode other than auto) before downloading. If some other crash happens when downloading, a romlog from that would be useful.

Previous ChaseFrame crash discussion https://chdk.setepontos.com/index.php?topic=7934.80 does not seem obviously related, although cmds.shoot_hook_sync does use the remote hook.  You could try using cmds.shoot instead. The sync is probably a little bit worse, but it might be a helpful diagnostic.
Don't forget what the H stands for.


Re: 3D scanner with multiple IXUS160 cameras
« Reply #24 on: 18 / August / 2017, 01:35:35 »
Do you get the ChaseFrame crash happen when shooting, or downloading?ic.

To the very best of memory, my previously attached (ChaseFrame) romlog was from the filetransfer crash.

Thanks for your other helpful comments / suggestions - i'll take them all on board in further testing & get back.   

Re: 3D scanner with multiple IXUS160 cameras
« Reply #25 on: 18 / August / 2017, 05:19:18 »
Quick update:

In Auto (8 connected cameras), 10 cycles of 
  • record -> preshoot -> shoot_hook_sync -> play -> last image download
worked without crash.

As expected, attempting download immediately after that in record resulted in the ChaseFrame crash.

For the record, cli & romlog attached

Thanks again for your suggestion.


Still facing other instability, so will try to use this thread to report on those.

(currently haven't figured how to turn off face detect in Canon Menu while in Auto)

Re: 3D scanner with multiple IXUS160 cameras
« Reply #26 on: 18 / August / 2017, 21:05:46 »
H-H, could you provide a useful hint perhaps?
Its all about the overall multi-cam system design and multi-cam rig construction.
i.e. NO RATS NESTS when wiring the multi-cam rig.
As per pervious multi-cam posts the multi-cam rig doesn't scale up without additional
trivial issues becoming NEW and significant problem's.

So to eliminate problems, due to the multi-cam power supply related issues :-

## Gradually Substitute camera battery's in-place of the common power supply.
## Use well proven "Industrial Wide" techniques, such as in post #17,
      i.e. "Distributed" power supply filtering in the dummy power DC-Coupler's.
## Try to avoid ground loops by rewiring or adding ferrite cores.
## Try to avoid accidental ground loops via USB cable and 1/4 inch camera mount's.
      i.e use photo-couples for camera sync as per pervious posts.
## Use a slightly higher supply voltage and Voltage regulators, such as in post #17,
## Try to avoid potential "Common Mode" power supply problems.

If all the above stuff fails you the need to attempt to measure the problem some other low cost way.

## Use a low band radio receiver to detect any RF-Noise.
## Use a simple, low cost transient dector, details later if required.
## Use a passive simple, low cost current to Audio, converter.

H-H
« Last Edit: 18 / August / 2017, 21:12:15 by Hardware_Hacker »

Re: 3D scanner with multiple IXUS160 cameras
« Reply #27 on: 18 / August / 2017, 22:27:33 »
## Gradually Substitute camera battery's in-place of the common power supply.
This is a really good idea.  If it works with a battery in place then you know that your power supply setup is the issue when you switch away from the battery to your external power sources.

Quote
## Try to avoid ground loops by rewiring or adding ferrite cores.
Avoiding ground loops is crucial!  All your grounds on the DC side need to originate from a single common physical point or terminal. Ensuring there is only one electrical path (including cable shields!) to each camera from that point is crucial.

But using ferrite cores has nothing to do with ground loops.  That's a solution to a different problem - RFI interference.
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline reyalp

  • ******
  • 12793
Re: 3D scanner with multiple IXUS160 cameras
« Reply #28 on: 18 / August / 2017, 23:30:39 »
Quick update:
As expected, attempting download immediately after that in record resulted in the ChaseFrame crash.
So don't do that ;) Switch to playback mode, or a different shooting mode if that avoids the crash.

Quote
(currently haven't figured how to turn off face detect in Canon Menu while in Auto)
You probably can't. That's why it's Auto. P is much like auto, but lets you change more settings.
Don't forget what the H stands for.

Re: 3D scanner with multiple IXUS160 cameras
« Reply #29 on: 19 / August / 2017, 10:57:46 »
Thanks H-H & waterwingz for useful comment.

For the record, the power supply is no loger for sale but seems functionally equivalent to the 20A / 5V version of this:

http://www.ebay.co.uk/itm/SA-AC-110-220V-to-Voltage-Transformer-UK-/142434970856?var=&hash=item2129c92ce8

(I have a wire physically connected between V- of that & supply earth).

So don't do that ;)

You're right - if that was the only inconvenience i'd be a very happy man  :)

PS: I can no longer replicate the Auto sync shooting crash (as now understood, reducing syncat back to 100ms did not restart the problem ... a romlog of that might have been useful).
 
« Last Edit: 19 / August / 2017, 11:48:19 by andrew.stephens.754365 »

 

Related Topics