I've implemented the messaging with the long running script and fleshed out my application so it will take two pictures simultaneously from both cameras using ptp over usb.
Just in case it isn't obvious, only one lua script can run at a time. If you use lua... while another script is still running, it will ungracefully terminate whatever was running. I'm not sure just how ungraceful it is, but I'd avoid it. This also includes some ptpcam commands that actually just send lua.
This was the main problem, it was pretty ungraceful. Once I ensured the long running script was shut down after the actual capture, all the crashes and memory problems went away.
1) I got an out of memory exception after about 3 cycles of shoot-delete, I think I was warned about this. The cameras are hopefully going to be unattended so really hoping this is something I'm doing wrong. I had to write a horrible lua statement to get the most recent filename for the download/delete operations:
Seems like you should get more than that.
Note that if you have a lua script that runs indefinitely, it can eat up all available memory when it doesn't need to, because of how the garbage collector works. You can use the collectgarbage function to query how much is used or force collection http://www.lua.org/manual/5.1/manual.html#5.1
If each script ends normally and you start a new one, this shouldn't be an issue.
Thanks
" is escaped with \"
lua os.remove(\"A/DCIM/\"..os.listdir(\"A/DCIM\")[#os.listdir(\"A/DCIM\")]..\"/\"..os.listdir(\"A/DCIM/\"..os.listdir(\"A/DCIM\")[#os.listdir(\"A/DCIM\")])[#os.listdir(\"A/DCIM/\"..os.listdir(\"A/DCIM\")[#os.listdir(\"A/DCIM\")])])
This look crazy. Rather than try to figure out what it does, I'll suggest some other options
* do listdir once, and then use os.stat to check the timestamps
* as above, but use string functions on the returned names to work out the numbers and go from there
* use get_exp_count to query the cameras file counter directly.
* only allow one file at a time, and delete it before the next shot.
* as above, but in batches, e.g. shoot N shots, download them all, delete them.
Keep in mind that you have lots of images, a single os.listdir might be enough to eat up all available memory. Writing a proper directory iterator that doesn't just dump the whole thing into memory is on my todo list.
That builds and returns a A\DCIM\IMG02___05\IMG000023.jpg path by using os.listdir and the last item in the arrays for the DCIM and the IMG?
? folders.
Yes it's horrible.
I might be able to use the sequencing number get_exp_count and simplify this down, but figuring out what the IMG?
bit is will be tricky without a statement like above.
2) I can't seem to reliably repeately shoot/cycle.. 50% of the time, either the delete fails, the filename retrieve fails or the script won't start up again after the capture
There was a bug recently introduced in the "shoot()" command, maybe you are hitting this ? http://chdk.setepontos.com/index.php?topic=6351.msg66002#msg66002
Think this was the multiple script thing instead, not using shoot()
3) I have to wait an arbitary amount of time for the image to get written to the flash, there doesn't seem to be any way to know when this actually happens?
Nope, not at this time.
No worries.
To summarise, I now have 4xA495 and they're all being controlled by a bit of C# software. We're doing our final testing before purchasing the entire batch of 40.
We're using a long running lua script (based off the ptpmsg.lua script) which makes available half shutter and full shutter messages.
When a full shutter message is received it quits the script.
This script is started up over the ptp interface using loadfile, and then a message is sent using putm to lock the focus and then when a button is pressed in the winforms app, a putm capture causes the shutter to be fully depressed and the script to exit.
The most recent file is then located, downloaded and deleted from the camera and the script is started, focus lock applied ready for the next shot.
We're getting about 10 seconds per sequence, which isn't super fast but I have to introduce lots of sleeps/delays to ensure commands have executed correctly before I do the next step.
e.g. jpg saved to flash
I'm personally quite happy but as the A495 has no manual mode, there's no easy way to set the TV and AV. I tried using proptable and set_prop but I either used the wrong magic numbers (for the values) or it's not implemented in the a495 alpha chdkde firmware i'm using.
Most of the time I got an error from the camera.
Same with trying to turn the flash off with a setprop of flashmode - errors.
I *think* the iso might have worked.
Unfortunately, despite my best efforts of having an application with multiple threads and a pulseall to signal those threads to send the putm capture, we're still getting too much delay.
I can't rely on the camera timestamps, so I timestamp the files once they're received. There is 300ms between the first shot and the last shot, but not in order. It's kinda scattered.
I think the actual photos are closer, but the USB transfers (after which I timestamp the files) is causing this number to appear bigger than it actually is.
The subject's foot visibly moves though.
Anyone got any ideas how I can speed up the release at all?
We were using the wired release over USB but then there's no way of getting the photos off.
At the very least, the PTP option here gives me a way of programatically getting the photos off the camera.
We were hoping to not have to dismantle the cameras to wire the shutter button.
I'll post another update shortly with 4 jpgs resized into one square of the results of my timing tests from last night.
