You should be able to do that using a slight modification of your existing rawopint_rs wrapper. I think all you need to change is to hardcode anything that's currently initialized from rs_opts.* and then run likeCode: [Select]luar < file.luathen download the images with imdl. If you delete the files using imdl -rm or imrm I'd generally suggest doing that in playback mode.
luar < file.lua
I think saving on the camera is the better test, but if that solves it then trying filedummy would be worthwhile.Looking at the CLI codeCode: [Select]con:exec('rs_opts='..opts_s..' '..shootscript,{libs={'rs_shoot'},execinfo=execinfo})it includes the rlibs when using -script, so you should just need to call rlib_shoot_filedummy() at the appropriate point in rawopint. I think I would put it just before hook_raw.continue()
con:exec('rs_opts='..opts_s..' '..shootscript,{libs={'rs_shoot'},execinfo=execinfo})
Maybe this could be related to the problem as well?
move = copy + delete + reboot.
What I did notice:after callingimdl -d="D:/sunrise/input/${name}" -rm the photos were downloaded and deleted form the camera but I connected with chdkptp GUI and saw that in playback mode the counter of the photos was at 15/15 (this was the 3rd run with 5 photos shot each) in the second screenshot you can see that in files there are no files left. Maybe this could be related to the problem as well? when I click left and then right the camera does not display any thumbnail anymore but only Unidentified Image (also for the 15/15 image).
Also maybe there is a way to "turn off" the sensor also in rec mode? like a native function call?
Thanks, I will try that later on. I had a look into the lib but did not understand how does rlib_shoot_filedummy() know how to name the filedummy if no attribute was passed to the function?
local fn=string.format('%s/IMG_%04d.%s',dir,get_exp_count(),e)
This is normal behavior for most cameras if the files are deleted using CHDK. It does not generally appear to cause problems if the files are deleted in playback mode, but it's not impossible there could be camera specific issues, or specific corner cases that haven't been noticed before.
On most cameras, when the display turns off for power saving, the sensor is also turned off. I don't remember if anyone has found a way to trigger this directly, but you can set the time in the Canon menu, and control whether it happens using the CHDK "disable LCD off" option (cnf_corre alt_prevent_shutdown if you're using set_config_value).Note that Canon firmware display off is different from CHDK set_lcd_display, which only affects the display and not the sensor.
It uses the current image counter and image directory. That's why it needs to be called at a specific point in shooting. See around this line in rlibs.luaCode: [Select] local fn=string.format('%s/IMG_%04d.%s',dir,get_exp_count(),e)
I will keep the same setup for some more days to test some edge cases: Not sure if there will be new problems if there have been taken enough photos that the counter gets an int overflow...
COMMUNICATION ERRORImages could not be transferred to the computer or printed due to the large amount of images (approx. 1000) stored on the memory card. Use a commercially available USB card reader to transfer the images. Insert the memory card into the printer’s card slot to print."
Thanks. You explained it very clear. I think there was still some confusion from my side up to now. This seems to be a simple solution. I have to test it out, I can't remember why I started using the CHDK set_lcd_display instead of relaying on the Canon display turn off option, which is activated in the menu and set to 10 sec right now. I think, I simply didn't know the differences.EDIT: I know now why I started using CHDK set_lcd_display: without set_lcd_display(0) the display stays, also after the rawopint script finished, always on.
What is cnf_corre
The counter wrapping from 9999 to 1 shouldn't be a problem, but, if the camera ever thinks there more than a few thousand images on the card, PTP may stop working with "COMMUNICATION ERROR" displayed on the camera. This is documented in the manuals likeThe actual limit is (usually? sometimes?) significantly higher than 1000.Not sure if your current workflow will hit this, I suspect it won't, but it's something to watch out for.
The default value of alt_prevent_shutdown is for it to be active in alt mode, so if the CHDK was in alt mode after the script finished, that could explain it. IIRC there was some case where using PTP also interfered with the Canon display off logic in some way, but I don't recall the details and didn't find it in quick search Note that if you allow the camera to go into Canon display off mode, you should wake it up with a key press and wait a moment for the screen to turn on before attempting to switch to play. It may crash if you don't.
The "cannon display off" mode would be my goal,
but I don't understand what I'm doing wrong or what is going on in the camera.I have read the CHDK manual regarding ALT mode and some forum posts but I didn't understand.The ALT mode is the CHDK menu opened with the alt "button" but why is this relevant e.g. in the playback mode where alt mode is not visible?Is also the alt_prevent_shutdown settings active when alt mode is closed?Why is alt_prevent_shutdown in this case important? As far as I understand I don't want to shutdown the camera. Also I tried out to set alt_prevent_shutdown to 0 and 1 but there was no difference observable.
but there was no difference observable
=return get_imager_active()
Note that if you are switching to playback between runs, it should not be needed.
alt_prevent_shutdown shutdown is poorly named. It actually blocks both the Canon display off function, and the Canon "shutdown after X minutes idle" function. In the CHDK menu, it appears as "Disable LCD Off"It has 4 possible values: Never (0), Alt (1), Script (2) and Always (3)Setting it to "Alt" means that Canon LCD Off and power down are prevented when CHDK alt mode is active. Script does it only when a script is running. When you execute script over PTP, CHDK goes into alt mode to run it, and tries to restore the previous state when it's done. This means it's possible for the camera to be left in alt mode.Setting it to "Never" should probably be OK for your case, since screen off won't kick in while the script is shooting, but "Script" should also be OK.You should make sure "Auto Power Down" is off in Canon power saving settings, and that the display timeout is something suitable.
How are you checking? When the display turns off, the chdkptp live view will generally continue to show whatever the sensor last saw, so if the scene is static, it's not really obvious.You should be able to useCode: [Select]=return get_imager_active() to check if the sensor is on.If you look carefully at live view, you can also usually see the difference, because there is slight frame to frame variation from noise.
Message systemThe message system can be used to send data to a script running on the camera, or receive data from it. Using the serialize / unserialize functions, Lua values can be exchanged seamlessly between camera and PC code. Lua return values and errors are also sent using the message system, but con:execwait handles them transparently.
how to print live telemetry data to powershell cmd?
os.execute('echo %PATH% &&cd&& dir/b')
function echo(...)local str=string.format(...)os.execute('echo '..str)endecho("%i Photos of %i", count or 0, maxcount or 1000)
Started by cyril42e « 1 2 » General Discussion and Assistance
Started by Dr.Pat « 1 2 3 » Feature Requests
Started by Sedric General Help and Assistance on using CHDK stable releases
Started by Dave the Wave General Help and Assistance on using CHDK stable releases
Started by Hardware_Hacker General Discussion and Assistance
