CHDK PTP interface - page 107 - General Discussion and Assistance - CHDK Forum supplierdeeply

CHDK PTP interface

  • 1240 Replies
  • 438388 Views
*

Offline tpont

  • **
  • 81
Re: CHDK PTP interface
« Reply #1060 on: 15 / August / 2013, 06:39:57 »
Advertisements
Ok, I misunderstood things. I will testrun the chkdptp snapshot once it is up.

*

Offline reyalp

  • ******
  • 13940
Re: CHDK PTP interface
« Reply #1061 on: 17 / August / 2013, 18:30:03 »
Based on my testing and feedback from nafraf in irc, I've checked a version of this without the debug code (+ fixed vxworks compile error in the previous patch) into the trunk changeset 3026. I'd like to get a bit more testing before moving it over to the release branch.
I merged this and the a490 changes into the 1.2 branch in changeset 3034
Don't forget what the H stands for.

*

Offline lapser

  • *****
  • 1093
Re: CHDK PTP interface
« Reply #1062 on: 19 / August / 2013, 22:42:50 »
Could it be that the wrapping happens earlier than 9999?
From what I understand the canon firmware can create a new folder before 9999 (depending on number of images present, I think?)

I'm not sure if this resets numbering. Honestly I'm not totally clear how all this is supposed to work, and it's a bit annoying to find out by testing.
From the multi-thousands of images I've taken with my time lapse script, I've figured out the number scheme, at least on all my cameras.

The Image number goes from 0001 to 9999 and wraps back to 1.

The camera creates a new folder when there are 2,000 images in the current folder. No folder ever contains more than 2,000 images.

The camera creates a new folder when the image number wraps back to 1. Thus, IMG_0001 is always the first file in its folder. This insures that sorting a folder by filename also sorts by time taken.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline tpont

  • **
  • 81
Re: CHDK PTP interface
« Reply #1063 on: 20 / August / 2013, 15:42:08 »
If you are referring to the error described in http://chdk.setepontos.com/index.php?topic=4338.msg103854#msg103854 this seems like it is just the shooting part of the script failing to take a shot and getting stuck (discussed earlier with the flash related issues). This shouldn't happen with the current chdkptp code in svn, though the shot would still fail. I'll try to get a new chkdptp snapshot build up soon.
Post when you do and I'll try it. nafraf helped me narrow down the problem a bit more. It only appears when sending separate rs commands in a row. So doing rs -jpg pretty rapidly over and over will cause the problem sooner or later. But rs -jpg -cont=200 works fine. But I wish to send single photo rs -jpg commands and vary the time inbetween each command somewhat so -cont=200 won't do.
« Last Edit: 30 / August / 2013, 10:28:33 by tpont »


*

Offline tpont

  • **
  • 81
Re: CHDK PTP interface
« Reply #1064 on: 29 / August / 2013, 12:19:26 »
Hi, I have tested the new chdkptp-r426 with the A2300. The problem with timeout after a variable number of rs commands remains. I get  error "WARNING: capture_get_data error timed out". I then have to restart the camera to get any commands to work again.

*

Offline reyalp

  • ******
  • 13940
Re: CHDK PTP interface
« Reply #1065 on: 31 / August / 2013, 00:18:51 »
Hi, I have tested the new chdkptp-r426 with the A2300. The problem with timeout after a variable number of rs commands remains. I get  error "WARNING: capture_get_data error timed out".
This means that chdkptp never saw remote capture data become available.

Does the camera shoot when this happens?
Quote
I then have to restart the camera to get any commands to work again.
What happens if you try to use other commands? Is it the "script is already running" error, or something else?

If camera side shoot() fails, you would get the timeout but then everything should work normally afterword. If you were using lua files from an old version you might get the behavior you describe.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13940
Re: CHDK PTP interface
« Reply #1066 on: 08 / December / 2013, 19:24:40 »
While writing this description, I've realized there are some unresolved issues, so this should not be considered final :(

In trunk changeset 3266 I added the ability to cleanly kill a running script, or return an error if you try to execute a script while one is already running.

This is a minor protocol change (2.6), backwards compatible with existing clients.

The corresponding chdkptp changes are in changeset 467

In addition allowing you to kill a script remotely, this allows compatible to clients to run a script without first doing a ScriptStatus query, which should improve performance slightly.

Up to now, PTP_CHDK_ExecuteScript param2 has been defined as "script language" which currently only accepts 0 for lua. In 2.6, only the lowest byte indicates language, and the remaining bits are flags.

If no flags are set, the behavior is equivalent to the old behavior, so earlier clients can connect to 2.6 cameras without any change. As in prior versions, calling PTP_CHDK_ExecuteScrip will cause any running script to be killed. However, in 2.6 this is safe, and does not cause memory corruption. Setting any of the flags for a pre-2.6 camera will result in an error, because it will be interpreted as an unknown scripting language. 2.6 aware clients should only send flags cameras running 2.6 or greater, since the error for a bad script language does not handle the data phase.

The added flags are
PTP_CHDK_SCRIPT_FL_NOKILL
If set, this causes PTP_CHDK_ExecuteScript to return PTP_CHDK_S_ERRTYPE_INIT in param2, and add a script message of the same type with the string "script running".

PTP_CHDK_SCRIPT_FL_FLUSH_CAM_MSGS
If set this causes the camera to discard any existing unread cam->host messages before starting the new script.

PTP_CHDK_SCRIPT_FL_FLUSH_HOST_MSGS 
Discard unread host->cam messages before starting.

The flush flags only take effect if the new script is started, if PTP_CHDK_SCRIPT_FL_NOKILL finds a script running, it's messages will not be affected.

The flush flags are added because the most common case is to not want any messages from old scripts floating around, and getting rid of them would otherwise require additional PTP calls to check state and read the messages (for cam->host) or leave them in memory until the script reads messages (for host->cam).

Issues:
Unsafe for ptp task to add a message when a script is running
Script ID will get incremented in the PTP_CHDK_SCRIPT_FL_NOKILL case
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13940
Re: CHDK PTP interface
« Reply #1067 on: 08 / December / 2013, 20:40:27 »
I updated this in chdk changeset 3268 and chdkptp changeset 468

PTP_CHDK_SCRIPT_FL_NOKILL now makes  PTP_CHDK_ExecuteScript return a status value PTP_CHDK_S_ERR_SCRIPTRUNNING without adding a script message. This makes more sense anyway, because unlike a syntax or runtime error, it doesn't really need additional information.

The script ID is not incremented in this case.
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #1068 on: 15 / February / 2014, 20:31:52 »
I have to correct my earlier statement.
Quote
It looks like that
- filewritetask only writes jpeg files (!), native raw is written elsewhere
Native RAW files are also written by filewritetask. In RAW + JPEG case, native RAW is saved first - the code doesn't currently handle this, rs -jpg will simply retrieve the native RAW file and let the camera save the JPEG to the card.

I wonder whether I manage to submit this post, the forum is nearly unusable in recent days/hours...

*

Offline reyalp

  • ******
  • 13940
Re: CHDK PTP interface
« Reply #1069 on: 15 / March / 2014, 01:10:14 »
I have to correct my earlier statement.
Quote
It looks like that
- filewritetask only writes jpeg files (!), native raw is written elsewhere
Native RAW files are also written by filewritetask. In RAW + JPEG case, native RAW is saved first - the code doesn't currently handle this, rs -jpg will simply retrieve the native RAW file and let the camera save the JPEG to the card.
Late reply :-[ I guess it would be nice to support this. Right now we don't have a consistent way to tell if a port supports canon raw, or if it is enabled. We'd also need a way of selecting Canon raw for remote shoot, while running through the same code jpeg.

An unrelated remotecap note, working on the rsint stuff made me realize there should be a way to tell on the camera side if remotecap has timed out, so a script can end gracefully if the PC side goes away.
Don't forget what the H stands for.

 

Related Topics