3D scanner with multiple IXUS160 cameras

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #40 on: 29 / August / 2017, 09:34:38 »

Advertisements

After 9 successful (M mode) cycles of:
preshoot -> usb_sync_wait -> sync shoot (via, reasonably, simultaneous opening of 7 port hub 5v port switches) -> switch to play -> download -> switch to record

on the 10th issue of switch to record, cam 7 stopped responding, however only after download & inspection of the romlog was it apparent that the crash had a 2016 timestamp.

So,
if I delete, on all cameras, romlog.log (before crash testing) is there a simple way, using multicam.lua, that all cameras, that have had previous romlog related crashes, can have that information erased so that it becomes apparent when attempting to download
A/ROMLOG.LOG
that it doesn't exist (via GUI message ERROR: stat source A/ROMLOG.LOG failed: A/ROMLOG.LOG: error or by simply looking in the relevant directory)

Only a nice to have (if easy).

« Last Edit: 29 / August / 2017, 09:39:12 by andrew.stephens.754365 »

Logged

reyalp

14117

Re: 3D scanner with multiple IXUS160 cameras

« Reply #41 on: 29 / August / 2017, 13:30:22 »

Quote from: andrew.stephens.754365 on 29 / August / 2017, 09:34:38

if I delete, on all cameras, romlog.log (before crash testing) is there a simple way, using multicam.lua, that all cameras, that have had previous romlog related crashes, can have that information erased so that it becomes apparent when attempting to download
A/ROMLOG.LOG

The romlog is stored in the camera onboard flash where the firmware is stored. We generally recommend against trying to modify that directly.

That said, there are a couple of related eventprocs related to GetLogToFile:

IsRomLogAvailable
EraseLogSector

From a quick look, EraseLogSector does not appear to take any arguments. If you decide to try it, it's at your own risk.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #42 on: 29 / August / 2017, 14:24:25 »

Thanks.

I'll probably start cutting some of my 3metre cables in half for the next test on the basis that writing some of those off could be a bit cheaper than a camera (or 8 ]

Just to be sure, I use the chdkptp cli for multicam.lua control in case there is any confusion with the "andrew" over at:
https://chdk.setepontos.com/index.php?topic=13226.msg134391#msg134391
(wasn't sure who that referred to).

Logged

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #43 on: 30 / August / 2017, 13:37:47 »

So, because it was an unusually sunny morning here and that I never had got round to examining this:

Quote from: reyalp on 03 / July / 2015, 16:41:25

Just to follow up on this, get_focus_state() (= FOCUS_STATE propcase) should indicate if AF was successful. http://chdk.wikia.com/wiki/PropertyCase has some notes.

I decided to forget about cutting power supply cables in half or moving anything from it's previous position / orientation and, instead, just repeated the same cycle, in M mode, of:

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

After 59 cycles of that cam3 stopped responding. Downloading the romlog showed date from an earlier crash.

I then changed the cameraside sync_wait function to look like this:

Code: [Select]

function cmds.usb_sync_wait()                            
--e.g. to run !return mc:cmdwait('usb_sync_wait')

    if get_focus_state() > 0 then                            
        usb_sync_wait(1)
        press('shoot_full')
        write_status(true)
        sleep(9000)
        release('shoot_full')
        else
        write_status(false)
        release('shoot_half') -->> if get_shooting is true from preshoot this is required 
    end
end

I hadn't set shutter, aperture or iso to anything in particular, related to the conditions, on the cameras & after executing:

Code: [Select]

!return mc:cmdwait('preshoot')noted the following from their lcd's:

Cam1: shake symbol on, green focus box, overexposed
Cam2: shake symbol on, yellow! focus box, overexposed
Cam3: shake symbol on, yellow! focus box, overexposed
Cam4: shake symbol on, green focus box, overexposed
Cam5: shake symbol off, green focus box, under exposed
Cam6: shake symbol on, green focus box, overexposed
Cam7: shake symbol on, green focus box, overexposed

In multicam.lua, I have status directed to file, as follows:

Code: [Select]

preshoot() status:
true, {
 [1]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 [2]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 [3]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 [4]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 [5]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 [6]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 [7]={
  done=true,
  status={
   cmd="preshoot",
   status=true,
  },
  failed=false,
 },
 }

i.e. get_shooting() was true for all cams.

After executing the new usb_sync_wait function, it's status was as follows:

Code: [Select]

usb_sync_wait() status
true, {
 [1]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=true,
  },
  failed=false,
 },
 [2]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=false,
  },
  failed=false,
 },
 [3]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=false,
  },
  failed=false,
 },
 [4]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=true,
  },
  failed=false,
 },
 [5]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=true,
  },
  failed=false,
 },
 [6]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=true,
  },
  failed=false,
 },
 [7]={
  done=true,
  status={
   cmd="usb_sync_wait",
   status=true,
  },
  failed=false,
 },
 }

Indicating that focus had not been achieved for Cams2&3.

The cli-trace shows that current PC hard disk images were, of course, not overwritten for cams2&3:

Code: [Select]

___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
8E0A647E9AC0179DDC30582D5
+ 2:Canon PowerShot SX150 IS b=\\.\libusb0-0002--0x04a9-0x3234 d=bus-0 s=689D500
5104943C09E988E4EA8301E22
+ 3:Canon PowerShot SX150 IS b=\\.\libusb0-0003--0x04a9-0x3234 d=bus-0 s=E21B7D7
37E5D4291B5DD048230963CF6
+ 4:Canon PowerShot SX150 IS b=\\.\libusb0-0004--0x04a9-0x3234 d=bus-0 s=449A58C
8297A4CCDAD05327C6BDD6FC2
+ 5:Canon PowerShot SX150 IS b=\\.\libusb0-0005--0x04a9-0x3234 d=bus-0 s=A42727D
40A154E39945D810173405135
+ 6:Canon PowerShot SX150 IS b=\\.\libusb0-0006--0x04a9-0x3234 d=bus-0 s=6C13E0E
B6FF04FEF9D0F50BFAB5B9420
+ 7:Canon PowerShot SX150 IS b=\\.\libusb0-0007--0x04a9-0x3234 d=bus-0 s=F5C3101
2304A49F4B4D84B8736A8714C
___> !mc:start()
___> !return mc:cmdwait('rec')
rec
___> !return mc:cmdwait('lock_ptp_comms')
lock_ptp_comms
___> !return mc:cmdwait('preshoot') 
preshoot                                 -->> get_shooting() result in status file "true" for all cams
___> !return mc:cmdwait('usb_sync_wait')
usb_sync_wait                            -->> get_focus_state() is not greater than zero for Cams 2&3
___> !return mc:cmdwait('preshoot')
preshoot
___> !return mc:cmdwait('usb_sync_wait')
usb_sync_wait
___> !return mc:cmdwait('rec') 
rec
___> !return mc:cmdwait('play')
play
___> !mc:download_images({lastimg=1,fmatch='JPG$'})
skip existing: 02/139___08/IMG_3203.JPG   -->>because Cam2 did not take a shot 
skip existing: 03/139___08/IMG_2180.JPG   -->>because cam3 did not take a shot
___>

Subsequently, running 100 cycles (with the new usb_sync_wait function) of:

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

operated without failure (Cam2&3 being ignored by the function from the sync'd shot).

Might it be reasonable to imagine that previously reported failures (at the sync'd shot stage) without romlog could be due to focus failure?

« Last Edit: 30 / August / 2017, 15:20:24 by andrew.stephens.754365 »

Logged

reyalp

14117

Re: 3D scanner with multiple IXUS160 cameras

« Reply #44 on: 30 / August / 2017, 16:38:18 »

Quote from: andrew.stephens.754365 on 30 / August / 2017, 13:37:47

Might it be reasonable to imagine that previously reported failures (at the sync'd shot stage) without romlog could be due to focus failure?

I thought you described the cameras as crashing or freezing, so I don't understand the connection to focus failure? When you say "After 59 cycles of that cam3 stopped responding" does "stopped responding" mean the camera shut down, or something else?

Is your theory that when AF fails, that is somehow connected to the camera crashing later? I don't recall anyone reporting this before, but it's not totally implausible.

It would be good to have a clearer idea of what the actual state of the camera is in the failed case.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #45 on: 30 / August / 2017, 17:08:30 »

Edit:
see Reply #47

« Last Edit: 31 / August / 2017, 02:49:26 by andrew.stephens.754365 »

Logged

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #46 on: 30 / August / 2017, 17:23:16 »

Edit: see Reply #47

« Last Edit: 31 / August / 2017, 02:49:59 by andrew.stephens.754365 »

Logged

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #47 on: 31 / August / 2017, 02:26:22 »

Quote from: reyalp on 30 / August / 2017, 16:38:18

I thought you described the cameras as crashing or freezing

I did, but that was prior the latest 100 test cycle. Using the updated usb_sync_wait function that I provided the code for, there were no crashes/freezing.

Describing that 100 cycle test, hopefully, more clearly, when:

Code: [Select]

!return mc:cmdwait('usb_sync_wait')is issued from the cli, a small amount of time is allowed to pass to ensure

Code: [Select]

function cmds.usb_sync_wait()
if get_focus_state() > 0 then

has executed on all cameras before the 7 port usbhub 5V switches are manually opened.
The if condition ensures that cam2&3 miss the

Code: [Select]

usb_sync_wait(1)
press('shoot_full')
etc

steps and just provide "false" status - they do not take a shot / no new image name is saved to SD which, after switching to play mode, results in the subsequent cli command:

Code: [Select]

!mc:download_images({lastimg=1,fmatch='JPG$'})
reporting back:

Code: [Select]

skip existing: 02/139___08/IMG_3203.JPG   -->>because Cam2 did not take a shot 
skip existing: 03/139___08/IMG_2180.JPG   -->>because cam3 did not take a shot

This same sequence was repeated (via cli) 100 times:

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

and the cli continued to report the same file skip download for cams2&3 (signifying no focus).

All cameras continued to operate (as expected, in the circumstances) going in/out of play/record as the cycles progressed (no freezing/crashes).

Quote from: reyalp on 30 / August / 2017, 16:38:18

When you say "After 59 cycles of that cam3 stopped responding" does "stopped responding" mean the camera shut down, or something else?

at switch from play mode to record mode the usb disconnect sounded, no romlog (that with the pre-updated usb_sync_wait function).

Quote from: reyalp on 30 / August / 2017, 16:38:18

Is your theory that when AF fails, that is somehow connected to the camera crashing later? I don't recall anyone reporting this before, but it's not totally implausible.

I don't yet know when it could become statistically significant. I guess I need 100 cycles of get_focus_state() > 0 on all cams and no crashes to help that theory along though.

For easy reference, the updated usb_sync_wait function is:

Code: [Select]

function cmds.usb_sync_wait()                            
--e.g. to run !return mc:cmdwait('usb_sync_wait')

    if get_focus_state() > 0 then                            
        usb_sync_wait(1)
        press('shoot_full')
        write_status(true)
        sleep(9000)
        release('shoot_full')
        else
        write_status(false)
        release('shoot_half') -->> if get_shooting is true from preshoot this is required 
    end
end

« Last Edit: 31 / August / 2017, 05:36:53 by andrew.stephens.754365 »

Logged

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #48 on: 31 / August / 2017, 09:44:46 »

Latest test description:

to ensure successful focus was obtained, I directed all 7 cameras (M mode) toward a cushion with a cat's head design. After preshoot all lcd focus boxes were green.

Using the usb_sync_wait function listed at the foot of Reply #47 above, 100 repetititons of:

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

resulted in no freezing/crashes and no skipped jpg download.

I then (physically) pointed all cameras to a plain section of wall and changed the usb_sync_wait function back to the original:

Code: [Select]

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

having executed preshoot, status file revealed all get_shooting() as true & all lcd focus boxes were yellow with an exclamation mark.

usb_sync_wait() & play() executed without drama but the subsequent download (the first attempt) caused the usbdisconnect noise & cli i/o error (Cam1), as per cli-trace:

Code: [Select]

___> !mc=require('multicam')
___> !mc:connect({list='C:/CHDKPTP/listfile'})
+ 1:Canon PowerShot SX150 IS b=\\.\libusb0-0001--0x04a9-0x3234 d=bus-0 s=9A95243
8E0A647E9AC0179DDC30582D5
+ 2:Canon PowerShot SX150 IS b=\\.\libusb0-0002--0x04a9-0x3234 d=bus-0 s=689D500
5104943C09E988E4EA8301E22
+ 3:Canon PowerShot SX150 IS b=\\.\libusb0-0003--0x04a9-0x3234 d=bus-0 s=E21B7D7
37E5D4291B5DD048230963CF6
+ 4:Canon PowerShot SX150 IS b=\\.\libusb0-0004--0x04a9-0x3234 d=bus-0 s=449A58C
8297A4CCDAD05327C6BDD6FC2
+ 5:Canon PowerShot SX150 IS b=\\.\libusb0-0005--0x04a9-0x3234 d=bus-0 s=A42727D
40A154E39945D810173405135
+ 6:Canon PowerShot SX150 IS b=\\.\libusb0-0006--0x04a9-0x3234 d=bus-0 s=6C13E0E
B6FF04FEF9D0F50BFAB5B9420
+ 7:Canon PowerShot SX150 IS b=\\.\libusb0-0007--0x04a9-0x3234 d=bus-0 s=F5C3101
2304A49F4B4D84B8736A8714C
___> !mc:start()
___> !return mc:cmdwait('lock_ptp_comms')
lock_ptp_comms
___> !return mc:cmdwait('rec')
rec
___> !return mc:cmdwait('usb_sync_wait')
usb_sync_wait
___> !return mc:cmdwait('play')
play
___> !mc:download_images({lastimg=1,fmatch='JPG$'})
ERROR: call failed:I/O error

___>

Related ROMLOG.LOG (Task name: PTPSessionTA0) & MODULES.LOG are attached.

Anything from those (or anywhere else for that matter) which may give a hint would be appreciated.

ROMLOG.LOG (3.96 kB - downloaded 29 times.)

MODULES.LOG (1.73 kB - downloaded 28 times.)

« Last Edit: 31 / August / 2017, 16:43:03 by andrew.stephens.754365 »

Logged

reyalp

14117

Re: 3D scanner with multiple IXUS160 cameras

« Reply #49 on: 17 / September / 2017, 22:47:43 »

Working on integrating hardware remote with multicam, I noticed that USB communication fails if the camera spends too much time waiting for the hardware remote.

Seeing the write_status before the end of the function in the usb_sync_wait code posted above, you may already know this, but this seems like a good thread for the details.

I hadn't really thought about this before, but it is expected behavior, because the only way to get status messages from the camera is by polling, and the USB hardware remote code uses a tight loop that doesn't allow the camera PTP code to run. Getting high precision sync requires the tight loop, so this is not easily fixable in CHDK code.

If it spends too long in this sate (~seconds in my experience), attempting to communicate via USB results in errors like
ERROR: call failed:Protocol error: data expected

The exact behavior may be camera and host OS dependent. A short waits for the remote seem OK, probably because the underlying USB layer allows some wiggle room.

The simplest way to avoid this is for your shoot command to use mc:cmd() instead of mc:cmdwait()

mc:cmd() will return as soon as the commands are sent, so if you want to do something after shooting is finished like displaying status messages, you will need to trigger that manually.

If you want to get any status messages generated by the shoot, you can use wait_status_msg with the name of your command,

mc:print_cmd_status(mc:wait_status_msg('my_shoot_command'))

Alternatively, you could adjust initwait option passed to mc:cmdwait to ensure that polling doesn't start before you've had time to trigger the USB remote, like

mc:cmdwait('shoot',{initwait=10000})

to wait 10 seconds before starting to poll. Note this means the cmdwait command will wait at least 10 seconds no matter what you do.

writing status messages on the camera side with write_usb_msg is not a problem, because they just go in a software queue waiting for the host to poll.

If the host is also controlling the hardware remote (e.g. using GPIO on a raspberry pi or something) then you could just wait until after you've sent the USB pulse to check status.

Logged

Don't forget what the H stands for.