Hi, can somebody please help me understand and confirm the 'hierarchy' and priority of camera setting options and settings when using CHDK and scripts?
When CHDK is loaded, it intercepts the launch of some of the
"tasks" from the base Canon firmware and replaces the tasks with its own version. The new tasks perform the same functions as the old tasks but are modified / augmented to include new CHDK functionality.
One of the things added to the existing tasks is the script interpreter you use. When you ask CHDK to run your script, the other Canon task and the ones with CHDK things added still function normally. They run in parallel - a process known as
multitasking.
From a hierarchy point of view, priority is essentially a question of which task made the most recent change. It's slightly more complicated than that of course. With things like exposure setting changes, CHDK grabs priority by making sure it makes the last change before each shot. The Canon firmware does not even know it happens - it assumes its setting were used. Also, when a CHDK script is running, CHDK intercepts all camera button presses so that the Canon firmware does not see them, thereby allowing the script to interact with them.
1. There are the normal Canon firmware options which can be accessed when the card write protect tab is off and the camera doesn't boot to CHDK. When the camera then auto boots to CHDK does it use the Canon settings or replace/overide them in its own menus?
Mostly the Canon menu settings and CHDK menu settings are independent. So both are used as they don't overlap. CHDK does override a few of the Canon settings though - "Disable LCD Off" for example. The big exception is exposure settings - as I've hopefully explained above.
2. Mode options can be set using the Canon function wheel - AUTO, MAN, etc. Can I assume CHDK doesn't interfere with these pre-sets?
Normally it does not. However, a script can change the active mode for example, or other Canon settings (via setting
Property Case or
Param variables, or by calling
Event Procedures). This gets tricky as there is no coordination with the Canon firmware - the things changed by CHDK are done "blind" - and sometimes the results may be inconsistent or just plain wrong. And we don't know how to change every Canon settings - just the ones discovered via painful trial and error.
3. Many new options can be set with CHDK, but do the Canon settings have priority if set before CHDK loads?
Where options overlap, CHDK wins.
4. If a script is loaded and running, does the script replace CHDK settings? i.e is the CHDK base firmware still running and a script interacts with it or does a script replace CHDK. When I'm switching back and forth between a script menu and the CHDK menu, I'm not sure what is running or what has priority?
A running script essentially has priority over CHDK settings. But if it does not explicitly change a setting, the base CHDK software actions will still happen.
I'm trying to get my head around these three ways of changing camera 'variables': Canon firmware settings, CHDK, and Scripts and how each interacts. At a very basic level I need to know if scripts just change what CHDK does as default by reading the status of settings then changing them, or scripts have to initialise settings from scratch?
The basic guideline is that scripts change only what they want to change in order to achieve their purpose. However, once things are changed they will stay changed after the script terminates until the next camera restart, unless the script is well behaved and records the initial state of what it is going to modify and then resets to that state when the script exits.
Incidentally, I've finally found out why these Canon Powershot 'A' series cameras give so much trouble with low battery warnings after testing my A560 on a bench power supply: The Canon firmware does more than just measure battery voltage. At power on it measures battery internal resistance by measuring the peak current against some reference value. The A560 takes about 350mA with the lcd lit and 80mA unlit so it must be calculating a peak value which will support flash recharging. I think the flaw is in the Canon firmware, because many low battery situations will support loads more shots. It's a shame the Canon algorithm appears to be responsible for dumping loads of re-chargeable batteries. Even a 2.5Amp bench supply can max out their internal resistance algorithm and put up occasional low battery warnings. The warnings remain persistent until the camera is re powered. I can stop this behaviour by adding a large capacitor to the supply wiring. I now test all my niMh batteries for internal resistance and the variation between brands is surprising. I also re-test after a few charge discharge cycles because some do not stay good. My battery of choice for consistent performance is the non-rechargeable Lithium AA. When I find Canons current sense resistor on my camera I will change its value. When people try to fix this problem by cleaning battery terminals, they are just trying to lower the battery internal resistance which the camera measures at power on. I think the real problem is with Canons measurement algorithm? The low battery voltage threshold set by Canon was for 1.5V cells like high capacity Duracells. There is a greater voltage margin for these cells than NiMh which start at 1.35V fully charged.
This is a very interesting development! Can I suggest you edit your post, cut this out, and start a new thread based on just this paragraph? That way it does not get buried here in a
"script newbie" thread.
FWIW, I suspect the camera does not have the sophistication to measure battery internal resistance directly. What it does see is the brief voltage dip caused by that internal resistance during high current loads (i.e. at startup, or when recharging the flash, moving the lens, writing to the SD card). The firmware is not very smart though - if it did several measurements over a few seconds (i.e. when the average current draw was only 350mA) it would probably make a different decision about low battery status.