I found out that the "ASSERT!! MotionVector.c Line 338" error doesn't happen if I can ensure that all images (or dummies) are deleted after max 2 consecutive timelapse ( at the moment 720 photos each).
Hmm, it would surprise me that the files / dummies trigger this crash. But I've been surprised before
The downside was that the command "imrm -quiet" never worked (this command would be prefered). Instead the code
luar click'menu'
exec sys.sleep(500)
...
only works some times? (this would be the steps I use for deleting the images via the GUI). That's why I tried to use longer sys.sleep times but with no real success up to now. I'm trying now even longer sys.sleep times between click commands.
If you can watch it doing this and see what happens on the when it fails, that provide some clues, but I understand this could be difficult in your configuration.
One possibility is that it's the click command itself that fails, rather than the sleeps between. "click" is a press and release with a built in delay (I think 60ms in the current G1 X port, though there may be some additional delay), and there can be cases where the delay isn't long enough. So you could replace the click with something like
luar press'down' sleep(200) release'down'
Note:
1) If the delay is too long, a command like this could move multiple items in the menu. 200 was OK in a quick test on one of my cams, but YMMV. 300 seemed too long.
2) You must put the press and release in the same luar command with a camera side sleep, as shown above, rather than a separate chdkptp side exec sys.sleep(), because any keys pressed in luar are automatically released when the luar command completes.
3) When in playback after connecting USB, the camera will ignore all key presses until it has either been switched to rec (and back, if you want play mode) or you've posted an unlock event like luar post_levent_to_ui(4484). In your normal workflow, deleting should happen after shooting (which means the keyboard will already be unlocked by going to rec and back), but this could be relevant if you try to delete after a crash or reboot.
If that doesn't work, there are also a couple other ways you could navigate the menu with chdkptp commands:
1) Simulating the jogdial instead, using wheel_left() / wheel_right(). These should consistently move exactly one menu item. You'll still need to key presses for menu and set, of course.
2) Using
events. This simulates key presses at a different level in the firmware. So you could simulate a menu press with
luar post_levent_to_ui('PressMenuButton') post_levent_to_ui('UnpressMenuButton')
The events for the other keys are as you'd expect: PressSetButton, PressUpButton etc. In a quick test, sending the press/unpress like the above with no delay worked, but again, YMMV.
maybe click'erase' would be more stable but I'm not sure if there is a setting to make sure all images are deleted and not just one single photo.
Not that I'm aware of.
I recall in an earlier discussion (
https://chdk.setepontos.com/index.php?topic=11481.msg146783#msg146783) you were using PT_EraseAllFile. Did this end up causing problems? Note it must be used in rec mode, and you'd need to avoid switching to play until it finished (I think the function should block, but I haven't tested).
Also, the example I posted in that thread used con:call_function(...). It's possible this will fail if a function takes a long time. Since you have native calls enabled now, you can use call_func_ptr in a camera side script instead, which should be both clearer and less likely to have timeout problems. I can post the equivalent code if you want.
For this one, it's possible that trying to set user av immediately after mode switch could cause problems. I would probably put a few hundred ms sleep between them, but given the other crash, I don't have high expectations.
I don't think so as this code part was working fine before I started to change to playback mode after each timelapse.
FWIW, I would recommend a delay in any case, because there are known issues related to mode switches not being fully complete when when the mode switch command returns.
What's interesting on this part is:
!print(con:execwait[[if get_zoom() == 15 then return 'zoom ok' else set_zoom(15) return 'ERROR: zoom wrong - set to 15%' end]])
always return "zoom ok", which is correct (as the lense doesn't retract. instead
!print(con:execwait[[if get_focus_mode() == 1 then return 'focus mode ok' else set_mf(1) return 'ERROR: focus mode wrong - set to mf' end]])and
!print(con:execwait[[if get_focus() == -1 or get_focus() == 33079 then return 'focus distance ok' else set_focus(-1) return 'ERROR: focus distance wrong - set to infinity' end]])always returns
"ERROR: focus mode wrong - set to mf"
"ERROR: focus distance wrong - set to infinity"
Maybe after switching back from playback mode to rec mode the focus mode is always changed to AF?
What also didn't help was to set AF to MF manually in the GUI after a restart as the setting is not permanent after the change to playback mode.
It is normal for the MF setting to be cleared when switching to playback on some cameras, though my impression is this mostly affects much older cameras. Turning the display off through the Canon UI also generally turns off MF. CHDK set_lcd_display generally does not affect the focus setting but the Canon auto display/sensor off power saving mode can.
You once wrote:
In the camera log for these, I see a lot of lines with "SS:SetFace". If the Canon menu AF setting is set to something Face, AiAF, or Tracking, I'd suggest trying setting it to Center instead.
maybe this is related to this.
From the manual it looks like "FlexiZone" is the normal/non-face setting. If the face related messages appear in that mode, I'd assume that's normal Canon firmware behavior. We've observed elsewhere that a lot of the face stuff runs all the time, even when it's not in use.
You mentioned the setting being reset in
https://chdk.setepontos.com/index.php?topic=14302.msg147124#msg147124One thing to be aware of is if you reboot with CHDK reboot, Canon settings are not saved. You should shut down with the physical button or post_levent_to_ui('PressPowerButton') to ensure they are saved.
