CHDKPTP File Downloading - page 3 - General Help and Assistance on using CHDK stable releases - CHDK Forum
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 10   Go Down

CHDKPTP File Downloading

  • 92 Replies
  • 36094 Views
*

Offline jdstech

  • **
  • 52
Re: CHDKPTP File Downloading
« Reply #20 on: 03 / January / 2018, 14:24:21 »
Advertisements
Quote
The lua files in the current SVN (r798) allow you to use ${s_sub,...} to do the equivalent of lua string.sub(). So to name using the last 3 digits of the serial number, you could use
mc:download_images{dst='${s_sub,${serial},-3}${ext}'}
As always, it's a good idea to use pretend=true to verify that you are getting what you want.
Note the above example would only work if you have one image per cam, otherwise you need to include something that is unique per shot like ${imgnum} or ${shotseq}

Perfect thanks!

So I'm encountering a strange problem. I've been troubleshooting for hours and hours and I've got a lot of data but I'm having trouble piecing it together. I'll start with the modified program I'm using,

Naming just determines the name of the folder the images are downloaded to, so if I take one shot I can save it as shot 1 all the way up to shot 6.

Connect, shoot, download, and clear are fairly self explanatory, prepare switches to record mode and focuses, initialize starts the camera side script, and rescue stops it.

So here's my bug testing procedure:

First I connect
there should be 48 cameras but one is turned off (you'll find out why in a second).

Then I start by ending the script, this makes sure all the cameras are on the same page and it's a good way to weed out troublesome cameras as it tends to crash them. This is what's supposed to happen,


Then I repeatedly start and stop the script, I call each start and stop a "cycle". If all the cameras behave themselves they shouldn't give me any trouble
.

If the cameras make it through 5 cycles successfully I call it a pass, and generally if they pass 3 times in a row (15 cycles) I know they're good.

Now for my camera system. I have 8 tripod towers with 6 cameras each. I have 4 USB hubs, each one is connected to 2 towers and has 2 switches that allows me to cut connections of individual towers. The 4 hubs are Alpha, Beta, Gamma, and Delta (which I just abbreviate to A, B, G, and D), the towers are given a number depending on which switch they're controlled by, so for example Alpha1, or just A1, is the first tower on hub A. The reason I'm telling you this because otherwise what I'm about to say won't make much sense. Also if I refer to something as just a letter and no number, like B instead of B2, I'm just talking about the entire hub.

So through extensive testing I've found that all cameras on both B and G function well. I've never gotten errors when running my tests on those two hubs*, and they could pass all tests indefinitely

However, running B G and D would give me what I call an ED error (named after hub Delta, it stands for Error Delta). Which means it passes the first part of my test where I stop the script, but prints this error when I try to start it again and completely crashes CHDKPTP when I try to end the script again (or anything for that matter)
.

That I/O error is also what I get in the case of E errors, which just stands for Error. E is when the program crashes immediately upon stopping the script the first time. I don't know if that makes any sense so here's an example. I start the program, connect, then hit rescue, if it just gives me the harmless warnings "send exit cmd failed: no script running" I'm good, if it crashes it's considered E. Assuming it doesn't crash I press initialize and "script started" gets printed to the console. If "failed I/O error" is also printed to the console I'm about to get an ED. Then I press rescue and it should print "script ended", and I give it an N(No error), but in the case of an ED it shows me this


So B and G give me N consistently (which means it gives me no errors. Sorry if I'm being repetitive but I've been told my methods are a bit convoluted)

B G and D give me an ED

B G and A give me an E

A on its own also gives gives me an E, and likewise D on its own still gives me the ED (on occasion D would give me an E and A would give me an ED)

So upon further testing I find that one camera in particular on D was causing the Errors and after turning it off D works fine, both on its own and with B and G

A on the other hand is more problematic. If I had B G D and A2 it would pass 95% of the time, but the second I threw A1 in there with it I'd get crashes. I identified 3 problematic cameras on A1, and after turning them off the remaining cameras on A1 worked more often but still caused problems.

I gathered these results last friday, and today I started working on it again but with some inconsistent results. Now when I run all of A (including the bad cameras) it works about 90-95% of the time, but upon adding extra towers the success rate begins to drop. A plus 1 other tower works ~80-90% of the time, A plus 2 towers is ~60-70%, and A plus all 3 other towers is ~10%.

A few cameras have also been shutting off randomly today. This happened to me maybe once or twice on Friday but today it's already happened like 5 times, all with different cameras. I started thinking maybe it was a power problem. the whole system is running off 2 large power strips, which are plugged into adjacent outlets along with another power strip running my computer.

Earlier this morning I thought maybe the power strip that A was plugged into was overloaded so I moved the power supplies for the cameras and the usb hub to an extension cord plugged into the remaining wall outlet and I'm not sure if it helped or not, but I'm definitely still having problems. I thought maybe I'm trying to draw too much power from the circuit but I doubt this setup is that power hungry.

I've also had this error pop up a few times, sometimes many times at once but it doesn't seem to have much of an effect.

I've also just started testing picture downloading today, which worked flawlessly before and now seems to be giving me trouble. That error is from hub Beta (one of the notoriously good hubs) when I tried to download images off of only 6 cameras, and now downloading only works like once every three times I try it.

Sorry to unload all this on you at once, but I feel like I'm getting nowhere here. I have 5 pages of reports from bug testing of me trying different combinations of towers and solutions but I doubt they'll help you much.

Any advice?

Quick edit: I'm also getting this error when I try to download pictures . Also formatting
« Last Edit: 03 / January / 2018, 14:39:35 by jdstech »
Logged
*

Offline reyalp

  • ******
  • 14128
Re: CHDKPTP File Downloading
« Reply #21 on: 03 / January / 2018, 16:28:57 »
I haven't had time to digest that whole post yet, but regarding stability in general: What version of CHDK are you running on the cameras?

Philmoz somewhat recently fixed a bug which impacted multicam significantly on some cameras, see discussion starting around https://chdk.setepontos.com/index.php?topic=13267.msg134857#msg134857 

tl;dr: you should be using 1.5 build >= 4924  or 1.4 build >= 4924.

This only affects CHDK builds that use ARAM or EXMEM, so if your camera groups are different models that could explain some differences. If you can list which camera models and firmware versions you are using, that would be helpful. Assuming you are using affected cameras, you should update before proceeding, because that bug will certainly bite you eventually even if it isn't the cause of your current problem.

The "attempting to close non-present..." message is generally not significant by itself. It just means that camera chdkptp thought was connected wasn't actually connect when it tried to clean up the connection. This can happen if the camera crashes, for example.

Also, as a general rule, I'll be much less likely to be able to give useful input without seeing the specific code you are using.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14128
Re: CHDKPTP File Downloading
« Reply #22 on: 04 / January / 2018, 23:49:14 »
Quote from: jdstech on 03 / January / 2018, 14:24:21
Then I start by ending the script, this makes sure all the cameras are on the same page and it's a good way to weed out troublesome cameras as it tends to crash them. This is what's supposed to happen,
I don't understand why the screenshot shows "no script running" errors. Are you sending the exit command without starting the script? Why?

Quote
That I/O error is also what I get in the case of E errors, which just stands for Error. E is when the program crashes immediately upon stopping the script the first time.
"I/O error" should be exactly what it says on the tin. Something in the USB layer failed, likely either hardware related or the camera on the other end crashing.

What is the state of the cameras when this happens? Are they crashed, or hung, or working normally? In any case where you get an error like "I/O" error or the 0x2ff error, I'd suggest looking the affected camera.

Quote
Any advice?
First, A3400 does use exmem, so the advice in my previous post applies. It could explain at least some of the problems you've seen, though not the apparent association with specific hubs.

If the errors really only happen on certain hubs, that obviously points to a hardware issue. Are they different models or revisions? Do they have different power supplies? Different cabling?

If you only use one of the bad hubs alone with none of the others powered on does it still have problems?
Quote
I thought maybe I'm trying to draw too much power from the circuit but I doubt this setup is that power hungry.
For a mains circuit, I'd think you are fine until you pop a breaker, but I'm no electrician.
Logged
Don't forget what the H stands for.
*

Offline jdstech

  • **
  • 52
Re: CHDKPTP File Downloading
« Reply #23 on: 06 / January / 2018, 12:02:35 »
Quote
I don't understand why the screenshot shows "no script running" errors. Are you sending the exit command without starting the script? Why?
The first reason is because I want to be sure the script is stopped on all cameras in case one instance went funky, and also ending the script happens instantly where as starting it takes a few seconds. I've found that starting and stopping the script have an equal chance to give me a crash so I start by stopping it because it tells me immediately whether or not something is seriously wrong.

Quote
"I/O error" should be exactly what it says on the tin. Something in the USB layer failed, likely either hardware related or the camera on the other end crashing.
That's what I suspected. All cameras have USB cords from the same supplier, I've tried switching usbs, power supplies, and hubs for all problematic cameras but there doesn't seem to be any change. The confusing part for me is how inconsistant my results are. Sometimes I can't get a single shot in before a crash, and other times everything works fine. I weeded out the cameras I found problems with and the system worked really well for a bit but now it's giving me errors again, though it isn't quite as unstable.

Quote
If you only use one of the bad hubs alone with none of the others powered on does it still have problems?
It does occasionally. It's really hard to give any definitive answers because these problems are so tempermental.

Quote
you should be using 1.5 build >= 4924  or 1.4 build >= 4924.
Yeah I installed 1.3 on all the cameras, I'll definitely try updating. Is there a way to update CHDK without individually removing the SD cards from each camera, say through CHDKPTP? Also I've been using STICK to install CHDK and the only versions it gives me are 1.3(stable) and 1.4(development). I'm guessing this means stick hasn't been updated recently?

Quote
What is the state of the cameras when this happens? Are they crashed, or hung, or working normally? In any case where you get an error like "I/O" error or the 0x2ff error, I'd suggest looking the affected camera.
When I get I/O error the cameras causing trouble usually aren't doing anything out of the ordinary. The only way I can identify buggy cameras is by turning them off individually until I stop getting crashes.

Quote
Are they different models or revisions? Do they have different power supplies? Different cabling?
At first all 48 cameras were 3400is's, but after plucking out a few bad cameras I'm running on 45 3400's and 3 4000's. I checked the firmware version on the bad camera's; two had 101a and one had 100f. I also checked the firmware versions on two cameras I know are working well and had one with 101a and one with 101b.

I'll attach the modified CHDKPTP files, the only files I modified are multicam.lua and gui.lua.

Logged
*

Offline reyalp

  • ******
  • 14128
Re: CHDKPTP File Downloading
« Reply #24 on: 06 / January / 2018, 16:55:02 »
Quote from: jdstech on 06 / January / 2018, 12:02:35
Quote
you should be using 1.5 build >= 4924  or 1.4 build >= 4924.
Yeah I installed 1.3 on all the cameras, I'll definitely try updating.
OK, you definitely need to be using a current 1.4 or 1.5 build before attempting to diagnose this further. This bug may not explain all your current problems, but it almost certainly explains some.

Quote
Is there a way to update CHDK without individually removing the SD cards from each camera, say through CHDKPTP?
Yes. Your cards are already bootable, so you just need to update the files. You can do this with the chdkptp mupload command. Unzip the CHDK zip, and then do
Code: [Select]
mup <unzipped directory> A/
You can do this over multiple cameras with multicam by manipulating the con global (see below), but you need to ensure the CHDK you upload is for the correct model and firmware version. I should probably allow "select" based on model/firmware.

For the simple case where all the connected cameras are the same model/firmware, you can use something like
Code: [Select]
!mc:cmd('exit') -- mup needs to run it's own script, stop multicam
!for lcon in mc:icams() do con=lcon cli:print_status(cli:execute('mup c:/temp/chdkfiles A/')) end
If you want to automatically detect the model and firmware, you can query buildinfo in the loop and use that to modify the source path, like (expanded to multiple lines for clarity)
Code: [Select]
for lcon in mc:icams() do
 con=lcon
 local bi=con:execwait('return get_buildinfo()')
 local cmd=string.format('mup c:/temp/%s_%s A/',bi.platform,bi.platsub)
 cli:print_status(cli:execute(cmd))
end
This assumes you've extracted to the files to c:/temp/<chdk platform name>_<firmware version>

Note the above are off the top of my head, not tested.
Some earlier related discussion:
https://chdk.setepontos.com/index.php?topic=12325.0
https://chdk.setepontos.com/index.php?topic=11478.msg112611#msg112611

Quote
Also I've been using STICK to install CHDK and the only versions it gives me are 1.3(stable) and 1.4(development). I'm guessing this means stick hasn't been updated recently?
I suspect you are using an old version of stick or something, because 1.4 has been the "stable" build for more than a year.

Quote
Quote
What is the state of the cameras when this happens? Are they crashed, or hung, or working normally? In any case where you get an error like "I/O" error or the 0x2ff error, I'd suggest looking the affected camera.
When I get I/O error the cameras causing trouble usually aren't doing anything out of the ordinary. The only way I can identify buggy cameras is by turning them off individually until I stop getting crashes.
In case it wasn't clear what I meant was physically examine the camera that encountered the error. You can identify the camera using the multicam 'id' command. You could do this at the start (so all cameras are showing ID), or display IDs on all the non-crashed cameras to identify the crashed ones. Once you've identified them, verify that the screen isn't frozen and that you can manipulate the CHDK menus using the physical controls.

As I mentioned before, you can use lists to maintain stable ID <=> serial mapping between sessions.
Logged
Don't forget what the H stands for.
*

Offline jdstech

  • **
  • 52
Re: CHDKPTP File Downloading
« Reply #25 on: 09 / January / 2018, 12:54:49 »
Awesome, I'm installing 1.4 now. Should I update my chdkptp mod to 195? Is there anything super useful in 195 I'm missing out on? Also this is slightly off topic but I'm curious, what's your proffesion?
Logged
*

Offline reyalp

  • ******
  • 14128
Re: CHDKPTP File Downloading
« Reply #26 on: 09 / January / 2018, 13:30:57 »
Quote from: jdstech on 09 / January / 2018, 12:54:49
Awesome, I'm installing 1.4 now. Should I update my chdkptp mod to 195? Is there anything super useful in 195 I'm missing out on?
Assuming you mean 795? There are have been no changes in the C files from the previous version (r785), so if you are using the latest lua files from svn there is no need to update.
Quote
what's your proffesion
Code monkey.
Logged
Don't forget what the H stands for.
*

Offline jdstech

  • **
  • 52
Re: CHDKPTP File Downloading
« Reply #27 on: 09 / January / 2018, 17:01:16 »
So I'm pretty sure auto exposure is causing problems with image alignment, is there a way to change camera settings remotely?

edit: Also, is there an easy way to download the source files from svn, or should I just copy and paste each file individually?
« Last Edit: 09 / January / 2018, 17:20:05 by jdstech »
Logged
*

Offline reyalp

  • ******
  • 14128
Re: CHDKPTP File Downloading
« Reply #28 on: 09 / January / 2018, 21:19:12 »
Quote from: jdstech on 09 / January / 2018, 17:01:16
So I'm pretty sure auto exposure is causing problems with image alignment, is there a way to change camera settings remotely?
You can use pretty much any of the function in http://chdk.wikia.com/wiki/CHDK_Scripting_Cross_Reference_Page from the "call" command in multicam.

Quote
edit: Also, is there an easy way to download the source files from svn, or should I just copy and paste each file individually?
You can use a subversion client to check out the whole tree. The assembla web interface also provides a download option, the arrow button next to where it says checkout https://app.assembla.com/spaces/chdkptp/subversion/source/HEAD/trunk

Using svn is nice because you can update without losing local modifications, as long as the actual changed lines don't conflict.
Logged
Don't forget what the H stands for.
*

Offline jdstech

  • **
  • 52
Re: CHDKPTP File Downloading
« Reply #29 on: 10 / January / 2018, 13:41:04 »
So even after installing 1.4 onto the cameras I'm still getting I/O errors and a lot of "message from unexpected script id" errors. Is it possible I'm getting some of these problems because I'm using the 785 lua's? I feel like that probably isn't the case for the I/O errors though. Also I'm trying to turn off flash on the cameras but the only commands I can find relating to flash is get_flash_mode and get_flash_ready which I'm assuming are read only.

edit: Also how do I format call? I tried
Code: [Select]
mc:cmd('call get_flash_mode')
mc:cmd('call', 'get_flash_mode')
mc:cmd(call(get_flash_mode))
mc:cmd('call(get_flash_mode))
etc.
and they didn't seem to work
« Last Edit: 10 / January / 2018, 14:02:52 by jdstech »
Logged
Pages: 1 2 [3] 4 5 6 7 8 ... 10   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal