3D scanner with multiple IXUS160 cameras

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #50 on: 19 / September / 2017, 16:40:14 »

Advertisements

Quote from: reyalp on 17 / September / 2017, 22:47:43

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.

Ah, of course.

In

Code: [Select]

function mc:wait_status_msg(cmd,opts)
I actually have

Code: [Select]

 
--changed this:
        --return true, results
        --to:
        --inserted below
        return -- => so will no longer print either true or results to the chdkptp console
        --inserted above

&

Code: [Select]

--changed this:
        --return false, results, 'timeout'
        --to:
        --inserted below
        return    
        --inserted above

and had noticed that control was not returned to the chdkptp cli until after I opened the switch but had not really contemplated the reason (for "true" from camera write_status not getting back to the PC side until then) being because of the tight loop on the camera.

Quote from: reyalp on 17 / September / 2017, 22:47:43

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.

After issuing:

Code: [Select]

!return mc:cmdwait('usb_sync_wait')
it was probably ~~0.5~~ (edit) 1 sec max before opening the switch (i.e.I just waited until all lcd's went black). I never experienced the "Protocol error".

Quote from: reyalp on 17 / September / 2017, 22:47:43

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.

That is the hope.

Thanks.

« Last Edit: 20 / September / 2017, 00:31:40 by andrew.stephens.754365 »

Logged

reyalp

14079

Re: 3D scanner with multiple IXUS160 cameras

« Reply #51 on: 14 / October / 2017, 01:08:35 »

I split discussion of the suba threading bug to https://chdk.setepontos.com/index.php?topic=13267.msg134718#msg134718 as it has wandered pretty far from the original topic. I haven't tried to carry over every related post.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #52 on: 15 / October / 2017, 05:03:18 »

I usually use the following multicam.lua cameraside script to switch modes:

Code: [Select]

function cmds.set_mode()
 
 --e.g. to run from the cli -> !return mc:cmdwait('set_mode',{args=1})
 
 --1 -> AUTO
 --2 -> P
 --3 -> TV
 --4 -> AV
 --5 -> M
 --61 -> Movies
 
 --ensure record mode
     
     if ( get_mode() == false ) then
         set_record(1)
         while ( get_mode() == false ) do
             sleep(100)
         end
     end
 
      local new_mode = tonumber(mc.args)
        
     capmode.set(new_mode)
          wait_timeout_write_status(capmode.get,new_mode,100,mc.mode_sw_timeout)
             
 end

But (using suba build) I get random crashes (among 16 cameras) when switching between M & Movies.

Quote from: srsa_4c on 24 / September / 2012, 16:16:58

@ntstatic
I tried this scripted mode change on my SX100. It doesn't crash on "set", but the shooting menu is inappropriate, as in your case.
However, just tried running this script
Code: (lua) [Select]
set_capture_mode(9) sleep(10) post_levent_to_ui("ModeDialToMovie")from a random mode (Av or Tv), and it's a step closer, meaning the shooting menu is now correct. The jogdial still doesn't do what it is supposed to. Mode 9 is MODE_VIDEO_STD (see the enum in include/modelist.h).
Side note: I had to do the same in my S1IS port to make mode change work.

I haven't read the details of the thread related to that comment but, on a single camera, using the chdkptp gui:

Code: [Select]

=set_capture_mode(9)
=post_levent_to_ui("ModeDialToMovie")

only momentarily switches to Movies before reverting to M.

(
Edit1: as does

Code: [Select]

=set_capture_mode(9) sleep(10) post_levent_to_ui("ModeDialToMovie")

)

Should I have expected that to make Movies persistent or should something else be done?

Edit2

a possible solution:

Quote from: reyalp on 29 / October / 2009, 22:54:27

Quote from: fudgey on 29 / October / 2009, 17:32:04
When camera was booted to REC mode, I can't get any mode change (including movie) to stick (camera announces the change on LCD, but then it changes back to whatever it was). In the mode dial thread http://chdk.setepontos.com/index.php/topic,3228.45.html reyalp's solution for this particular problem is to set set_levent_script_mode(1) first but it doesn't seem to help when PTP is active.
set_levent_script_mode() is only half the solution. The other half is set_levent_active("ModeDailTo...",false) on all the mode dial position events *except* the one you want to use, and set_levent_active("ModeDailToMovie",true)

Will try that out.

« Last Edit: 16 / October / 2017, 14:46:39 by andrew.stephens.754365 »

Logged

reyalp

14079

Re: 3D scanner with multiple IXUS160 cameras

« Reply #53 on: 17 / October / 2017, 22:59:34 »

Quote from: andrew.stephens.754365 on 15 / October / 2017, 05:03:18

But (using suba build) I get random crashes (among 16 cameras) when switching between M & Movies.

FWIW, I would be surprised if the suba fix triggered this, but a romlog might provide insight into the crash.

Logged

Don't forget what the H stands for.

andrew.stephens.754365

461

Re: 3D scanner with multiple IXUS160 cameras

« Reply #54 on: 18 / October / 2017, 13:55:15 »

Quote from: reyalp on 17 / October / 2017, 22:59:34

FWIW, I would be surprised if the suba fix triggered this

Agreed.

The physical mode dial on the SX150IS includes the modes taken into account in my revised mode switching function:

Code: [Select]

function cmds.set_mode()

--e.g. to run !return mc:cmdwait('set_mode',{args=1})

--1 -> AUTO
--2 -> P
--3 -> TV
--4 -> AV
--5 -> M
--61 -> Movies

--ensure record mode
    
    if ( get_mode() == false ) then
        set_record(1)
        while ( get_mode() == false ) do
            sleep(100)
        end
    end
        
    local new_mode = tonumber(mc.args)
    
    --new for movies
    if new_mode == 61 then
            set_levent_script_mode(1)
            sleep(100)
            post_levent_to_ui('ModeDialToM',0)
            sleep(100)
            post_levent_to_ui('ModeDialToAv',0)
            sleep(100)
            post_levent_to_ui('ModeDialToTv',0)
            sleep(100)
            post_levent_to_ui('ModeDialToP',0)
            sleep(100)
            post_levent_to_ui('ModeDialToAuto',0)
            sleep(100)
            post_levent_to_ui('ModeDialToSCN',0)
            sleep(100)
            post_levent_to_ui('ModeDialToEasy',0)
            sleep(100)
            post_levent_to_ui('ModeDialToCreative',0)
            sleep(100)
            post_levent_to_ui('ModeDialToDiscreet',0)
            sleep(100)
            set_levent_active('ModeDialToMovie',1)                
    --new above for movies    
    else    
    capmode.set(new_mode)
    end    
   
    wait_timeout_write_status(capmode.get,new_mode,100,mc.mode_sw_timeout)
         
end

I don't know if the sleep(100) after "disabling" each levent is necessary yet but performance is vastly improved to what it was (although still facing some crashes on changing to movies on 3 cameras only).

Out of interest, is there a way, other than capmode.get, to test for successful change of mode?

« Last Edit: 18 / October / 2017, 14:37:11 by andrew.stephens.754365 »

Logged