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

3D scanner with multiple IXUS160 cameras

  • 54 Replies
  • 47986 Views
Re: 3D scanner with multiple IXUS160 cameras
« Reply #30 on: 22 / August / 2017, 07:34:58 »
Advertisements
Before attempting external to internal battery swap route I decided to update all of the Camera times to that of the PC (via chdkptp) and be in a position to download the romlog(s) via chdkptp. While not yet added as functions to multicam.lua getting relevant romlogs via chdkptp could speed debug up. A single test thereafter was as follows...

I have only seen one crash mention of:
Task name: PTPSessionTA0
on the forum here:
https://chdk.setepontos.com/index.php?topic=6355.msg66633#msg66633http://

I have included my most recent romlog that refers to that same Task Name. The attached CLI also describes the test:

7 Cams connected to 7 port usbhub with per port 5V switch (initially closed) then via multicam.lua (and some function additions to it described at the end of this post):
Code: [Select]
> !mc=require('multicam')
> !mc:connect({list='C:/CHDKPTP/listfile'})
> !mc:start()
> !return mc:cmdwait('rec')
> !return mc:cmdwait('lock_ptp_comms')
> !return mc:cmdwait('set_mode',{args=5}) -> switch to M (camera dial set at Auto)
> !return mc:cmdwait('preshoot')
> !return mc:cmdwait('usb_sync_wait')
> !return mc:cmdwait('play') -> no ChaseFrame worries in play mode
> !mc:download_images({lastimg=1,fmatch='JPG$'})
ERROR: call failed:I/O error

After !return mc:cmdwait('usb_sync_wait') was issued all 7 port switches were opened with a maximum of about 0.2 second variance to provide a (not very) synced shot. The crash occurred on a single camera at jpg download.

Might the romlog provide any hint that the problem could be due to more recent of this:

As I have tried to explain before, *all* of CHDK is a hack, the entire PTP feature is still especially immature and experimental...[]...If you are expecting a stable, mature product you can just run your application on, you are likely to be disappointed.

rather than the "Rats nest" of cabling (etc) that H-H refers to above (I am always conscious though that mphx does not seem (in my memory) to have encountered much in the way of ptp based problems in his multicam build thread).


In addition to the changemode function, the following were added to multicam.lua for quick testing:
Code: [Select]
function cmds.lock_ptp_comms()                           
--e.g. to run !return mc:cmdwait('lock_ptp_comms')                           
    usb_force_active(1) --lock ptp comms ON (+5V line changes do not disconnect)                       
    write_status(true)                   
end 

function cmds.usb_sync_wait()                           
--e.g. to run !return mc:cmdwait('usb_sync_wait')                           
    usb_sync_wait(1)
    press('shoot_full')
    write_status(true)
    sleep(9000)
    release('shoot_full')
end           


FMI:
romlog download currently individually via GUI
con> =return call_event_proc("System.Create")
con> =return call_event_proc("GetLogToFile","A/ROMLOG.LOG",1)
con> d A/ROMLOG.LOG

camera time setting, currently individually via GUI
con> =return call_event_proc('FA.Create')
con> =return call_event_proc('InitializeAdjustmentFunction')
con> !return con:execwait(string.format("return call_event_proc('SetHour',%d),call_event_proc('SetMinute',%d),call_event_proc('SetSecond',%d),os.date()",os.date('%H'),os.date('%M'),os.date('%S')))
« Last Edit: 22 / August / 2017, 08:32:01 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 14119
Re: 3D scanner with multiple IXUS160 cameras
« Reply #31 on: 22 / August / 2017, 17:40:19 »
After !return mc:cmdwait('usb_sync_wait') was issued all 7 port switches were opened with a maximum of about 0.2 second variance to provide a (not very) synced shot. The crash occurred on a single camera at jpg download.
Based on the PC and LR values, the crash looks like it's in CHDK code, but I can't tell which specific code crashed from the available information.

If you built CHDK yourself, then the main.bin.dump from that build might be enough to figure out where the crash was.

If not, I can provide a build I would be able to get more information from. Are all your cameras sx150? What CHDK version are you currently using?

Don't forget what the H stands for.

Re: 3D scanner with multiple IXUS160 cameras
« Reply #32 on: 23 / August / 2017, 03:42:57 »
Based on the PC and LR values, the crash looks like it's in CHDK code, but I can't tell which specific code crashed from the available information.

If you built CHDK yourself, then the main.bin.dump from that build might be enough to figure out where the crash was.

If not, I can provide a build I would be able to get more information from. Are all your cameras sx150? What CHDK version are you currently using?

Thanks.

It is stock: version 1.5.0, revision 4755, firmware 100a.

I think I used stick to get that on an SD card but then used Win 32 Disk Imager to create an image & used that to create the SD cards for all other SX150IS used during this testing.

Would very much appreciate any further assistance.

*

Offline reyalp

  • ******
  • 14119
Re: 3D scanner with multiple IXUS160 cameras
« Reply #33 on: 24 / August / 2017, 23:28:32 »
It is stock: version 1.5.0, revision 4755, firmware 100a.
OK, attached is a build of the current trunk. It's r4900, but almost all the intervening changes have been specific to other ports or digic6, so it shouldn't be significantly different from what you are using now. You could upload just the diskboot.bin and modules.

This is a stock build, I just will just have more information to debug any crashes that happen.

If you turn on module logging and post modules.log with any crash, that may also be helpful. You can turn it on from Lua using
Code: [Select]
set_config_value(require'gen/cnf_core'.module_logging,1)
Don't forget what the H stands for.


Re: 3D scanner with multiple IXUS160 cameras
« Reply #34 on: 25 / August / 2017, 06:34:49 »
OK, attached is a build

Thanks a lot.

Will get on this asap.

Re: 3D scanner with multiple IXUS160 cameras
« Reply #35 on: 26 / August / 2017, 07:35:49 »
Here are details of a first test with r4900. My suspicion tends toward a "rats nest of wiring" etc but there's not yet much to go on (no romlog).

So, with multicam.lua, after chdkptp connection to all cameras, I uploaded diskboot bin via cli:
Code: [Select]
!savecon=con for lcon in mc:icams() do con=lcon  cli:print_status(cli:execute('mup C:/CHDKPTP/REYALP-DEBUG/DISKBOOT.BIN A/')) end con=savecon&
MODULES via cli:
Code: [Select]
!savecon=con for lcon in mc:icams() do con=lcon cli:print_status(cli:execute('mup C:/CHDKPTP/REYALP-DEBUG/MODULES A/CHDK/MODULES/')) end con=savecon
After starting all remote scripts I, somehow, failed to add a remote function for module logging, on the fly, with:
Code: [Select]
!return mc:cmdwait('call function cmds.modulelogging() set_config_value(req
uire'gen/cnf_core'.module_logging,1) write_status(true) end')
ERROR: compile failed:[string "return mc:cmdwait('call function cmds.modulel..."
]:1: ')' expected near 'gen'

(before enabling it with mc:cmdwait('modulelogging)

So, for each camera I just enabled it through the GUI.


The test was then similar to the last test described. On 7 cameras in M mode, 7 successful cycles of:

preshoot -> usb_sync_wait -> sync shoot (via, reasonably, simultaneous opening of 7 port hub 5v port switches) -> switch to play -> downlad -> switch to record

(clitrace attached)

On the 8th change of the port switches from 5V to 0V I heard the familiar usb disconnect sound and Camera 7 became unresponsive (its lcd remained black after change back to 5v).   

Subsequently, using the chdkptp gui:
Code: [Select]
romlog download currently individually via GUI
=return call_event_proc("System.Create")
=return call_event_proc("GetLogToFile","A/ROMLOG.LOG",1)
d A/ROMLOG.LOG
provides:
Code: [Select]
ERROR: stat source A/ROMLOG.LOG failed: A/ROMLOG.LOG: error
Here, fwiw, are the contents of MODULES.LOG:
Code: [Select]
Tick    ,Op,Address ,Name (2017:08:26 10:09:30)
   85860,LD,00365f98,lua.flt
Tick    ,Op,Address ,Name (2017:08:26 10:23:12)
  447790,LD,0035ff30,lua.flt
Tick    ,Op,Address ,Name (2017:08:26 10:36:12)
  254150,LD,0035ff78,lua.flt
Tick    ,Op,Address ,Name (2017:08:26 10:45:50)
  404810,LD,03cc55f0,lua.flt
Tick    ,Op,Address ,Name (2017:08:26 10:58:56)
  140250,LD,00360018,lua.flt

In case there could be useful comment i'll wait before trying for a romlog crash test.

 
« Last Edit: 26 / August / 2017, 11:17:44 by andrew.stephens.754365 »

*

Offline reyalp

  • ******
  • 14119
Re: 3D scanner with multiple IXUS160 cameras
« Reply #36 on: 26 / August / 2017, 14:55:35 »
After starting all remote scripts I, somehow, failed to add a remote function for module logging, on the fly, with:
Code: [Select]
!return mc:cmdwait('call function cmds.modulelogging() set_config_value(req
uire'gen/cnf_core'.module_logging,1) write_status(true) end')
ERROR: compile failed:[string "return mc:cmdwait('call function cmds.modulel..."
]:1: ')' expected near 'gen'

(before enabling it with mc:cmdwait('modulelogging)
This is a quoting error, you used ' in both the mc: command and the camera side require.
Quote
:
Code: [Select]
ERROR: stat source A/ROMLOG.LOG failed: A/ROMLOG.LOG: error
This most likely means ROMLOG.LOG doesn't exist, either because there is something incorrect in your romlog calls, or that particular camera has never crashed in a way that generated a romlog.
Quote
Here, fwiw, are the contents of MODULES.LOG:
The modules log tells what RAM address modules were loaded at, which is only useful if there is a romlog.
Don't forget what the H stands for.

Re: 3D scanner with multiple IXUS160 cameras
« Reply #37 on: 26 / August / 2017, 15:13:32 »
or that particular camera has never crashed in a way that generated a romlog.

which is, I believe, the case.

which is only useful if there is a romlog.

Suspected that (unfortunately).

Thanks.

Will now continue to attempt to create/document what might be useful -
  • crash info with romlog
  • repeatable challenging patterns.


Re: 3D scanner with multiple IXUS160 cameras
« Reply #38 on: 27 / August / 2017, 20:58:59 »
If you suspect that there is a wiring or power supply related problems.
I am looking at some simple testing method's but might take some 4-8 weeks to do and attempt prove.

"...My suspicion tends toward a "rats nest of wiring"..." Some details would be helpful:-

a/ Are you using "figure 8" type cable for the multi-cam power supply.
b/ The camera(s) that crash how are they physically positioned in relation to the power supply.
     i.e. at the Start, end, middle, etc.
c/ What happens if you re-order camera(s) that crash with the ones that don't crash.

As posted, some time ago, the canon camera battery's or the Canon DC-Couplers have a short wiring length
and also the Canon DC-Couplers have a RF ferrite on the power cable as well as two inside canon's DC-Coupler's.
the Clones don't internal RF ferrite (or any other filtering components) as per the prior post.

Also as per Bug Splater's A590 power-2 study in the  "Others Section" of CHDK DSLR FW dumps repository:-
This shows what happens for a "Single" legacy camera with a short wiring length. (25cm)
So if you have some camera power supply cable left over what happens with just one sx150 with a relatively
long wiring length's.
No need to repeat the original measurements just to attempt to determine if there is a critical PS-cable length.
i.e. (25cm) x2, x4, etc.

H-H
« Last Edit: 27 / August / 2017, 21:27:59 by Hardware_Hacker »

Re: 3D scanner with multiple IXUS160 cameras
« Reply #39 on: 28 / August / 2017, 06:10:18 »
I am looking at some simple testing method's but might take some 4-8 weeks to do and attempt prove.

That would be very appreciated H-H. I have no deadline for this project.

Bank holiday here so will continue tests tomorrow. One of the first ones will be to turn the camera scripts off before shooting to see if that has any positive impact on the prior reported crash without romlog i.e after:
Code: [Select]
usb_sync_wait(1)
press('shoot_full')
cmds.exit()
then open 5V switches, restart scripts and issue:
Code: [Select]
release('shoot_full')
ISome details would be helpful:-

a/ Are you using "figure 8" type cable for the multi-cam power supply.
b/ The camera(s) that crash how are they physically positioned in relation to the power supply.
     i.e. at the Start, end, middle, etc.
c/ What happens if you re-order camera(s) that crash with the ones that don't crash.


Please see 2 images attached from about a year ago. The 2nd one shows strain relief added to the connectors - that was provided by isopon encapsulation. The transformer & distribution board (with 2A fuses) were subsequently screwed inside an mdf enclosure. To bring the voltage down (after diode), to what seemed like a reasonable value, all cable lengths are approx 3m in length (4mm single core single screen audio cable (16 x 0.1mm Cu & 28 x 0.1mm Cu)).

The mdf enclosure is sat on the floor 2ft distant from a 7ft vertical camera pole with equidistant cameras thereon. The 7 port usbhub (with per port usb switches) is at approx half that height on a table beside the pole. USB cables are stock Canon that came with the cameras.

re c/:
relatively little testing done from which to draw firm conclusion however observation seems to be random positioning of various crashes along the pole.



So if you have some camera power supply cable left over what happens with just one sx150 with a relatively
long wiring length's.
No need to repeat the original measurements just to attempt to determine if there is a critical PS-cable length.
i.e. (25cm) x2, x4, etc.


A lot to do here  :xmas

As a test, I also plan to uninstall all the libusb drivers to see if image download under the normal Canon (WIA framework) drivers (cameras then as portable MTP devices), are any more reliable with the current hardware configuration... but getting a bit of software to do that sequentially is not straightforward (and the Windows Portable Device API doesn't look the easiest thing for me to mess with).

 

Related Topics


SimplePortal 2.3.6 © 2008-2014, SimplePortal