Lua Scripting (lua.mo)

Started by dmilligan, March 29, 2015, 04:44:07 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

garry23

David

Can you give idiots like me any addition hints as to when we should consider using task.yield?

I've looked at the Lua examples, but it's difficult to see why task.yield has been inserted, ie good practice or essential at certain times.

Cheers

Garry

garry23

David/Walter

I hope you can help, as I'm so enthused about being able to script.

To me the following is simple and, I believed, coded 'correctly.

It behaves as expected initially, ie move the lens to the macro end and takes a picture.

I then get the LV message repeatedly flashed, ie looks as if it is in an infinite loop, that I'm at the soft end limit. Which I don't understand as I'm driving the lens the other way.

Can you see where I'm going wrong?

-- Simple landscape bracketing script

function main()
-- Close ML menu
menu.close()
-- Move lens to macro end
lens.focus(-10,3)
-- Get DoF info & take first bracket
a1 = lens.dof_near
b1 = lens.dof_far
camera.shoot(64, 0)
-- take remaining brackets to infinity
repeat
repeat
task.yield(100)
lens.focus(1,1)
a2 = lens.dof_near
b2 = lens.dof_far
until a2 > b1
-- move lens back to overlap last capture
lens.focus(-1,1)
a1 = lens.dof_near
b1 = lens.dof_far
camera.shoot(64,0)
until b2 >= 1000000
-- Infinity reached
beep(2, 100, 330)
end

keymenu = menu.new
{
    parent = "Audio",
    name = "Press SET",
    help = "Simple landscape bracket script",
    select = function(this) task.create(main) end,
}

dmilligan

I think the problem is that you are assuming lens.dof_near and far are immediately updated. They are probably not, esp since you aren't "waiting" until the focus move is complete (see the wait parameter to the lens.focus() function). Even if you wait, IDK if they will get updated. They come from Canon properties which can behave in finicky ways at times. You may have to use a prop handler to wait for them to change.

Another thing to keep in minds is that focus step sizes and total number of steps from macro to infinity can vary greatly from lens to lens.

garry23

David

Thanks for the pointer, I do some experimenting and educating  :)

Cheers

Garry

garry23

David

I may have found a bug in lens.focus.

No matter if you put positive or negative values of num_steps or step_size, the lens only moves one way, ie towards the macro end.

If this is a bug, I hope you can fix it   ;)

garry23

David

Have you found time to confirm my testing, that lens.focus has a bug, i.e. Only moves the lens one way?

Cheers

Garry

dmilligan


garry23

David

Thanks. For a while I thought it was me, until I tested every option  :)

Cheers

Garry

Walter Schulz

Feature request:
Autostart Lua script at powerup.

If Lua.mo is activated and cam is started it will lookup for scripts in subdir "Autostrt" and execute them. And/or look for files with a dedicated prefix (for example "AS_xxxx.lua") and execute them.

Licaon_Kter


dmilligan


garry23

David

BTW I see the nightlies were updated the other day, but I couldn't see any Lua tweaks.

Do you know when your Lua fixes will be incorporated ?

I'm particularly keen to see the lens move function working in both directions ;-)

Cheers

Garry

Walter Schulz

Thanks, Dan! <Note to self: RTFM!>

Quote from: Licaon_Kter on February 25, 2016, 12:15:43 AM
Any script in mind?

Sure: Rivaling "The most useless machine EVER" by running Reboot script at startup.

No, seriously, there are applications for running scripts at startup. Unattended cams for instance.

garry23

Walter

I can confirm that the scripts run on start-up.

For example, my script to provide a focus and exposure bracketing helper is by default switched off in the menu, but by changing the default to "On" in the script, it will be running, ready for use when the camera is switch on.

Cheers

Garry

a1ex

I have an issue with a very simple script.


function printf(s,...)
    print(s:format(...))
end

printf("abc%d", 5)


On PC:

lua test.lua
abc5


On camera (60D, lua_fix branch):

ML/SCRIPTS/TEST.LUA:2: attempt to index a string value (local 's')
stack traceback:
   ML/SCRIPTS/TEST.LUA:2: in function 'prin_


That's right - it can't even display an error message...

Tried formatting the card, copying everything from scratch to make sure it isn't some filesystem error... all I could get was different names for the "printf" function in that incomplete error message (for example, once it printed "'glob_" instead of "'prin_")

No other scripts were changed or added - just the default scripts from the repository.

I suspect some memory corruption issues.

(no, it wasn't me who merged it into nightly builds, if you are wondering)

Update: I've reproduced the issue in QEMU as well (with semi-random names on the last word on the error line):


dmilligan

So basically what is happening is that you are trying to call a function in a library that isn't loaded. This is the one situation where the deferred automatic loading of the lua libraries does not work (I did this to try and save every last drop of RAM).

Almost always you have to do say:

local f = io.open

To get an instance. In other words to get an instance of a 'file' you have to reference a global "io" first. After that it's safe to do f:read() or whatever. When you reference a global that is a built-in lua library name, then the Lua backend loads that library at that time (it doesn't load them initially, only 'on demand'). This works pretty well for most situations because it's impossible to create an instance of some particular type without calling the 'constructor' by using the global reference. Strings are the one exception to that. They are the only "type" that you can instantiate without calling "string.<something>()".

So either:

require("string")
function printf(s,...)
    print(s:format(...))
end

printf("abc%d", 5)

or

function printf(s,...)
    print(string.format(s,...))
end

printf("abc%d", 5)





The truncated stack traceback is a separate problem. I've noticed that myself and I'm not sure what's going on. I remember in the past it's given the whole thing just fine, so I'll have to investigate that.

dmilligan

So the stacktrace issue I've narrowed down to this changeset:
https://bitbucket.org/hudson/magic-lantern/commits/2279fb4bd843d32969f63827f5f17142a84d0faf

So it appears to be a problem with ML's 'printf'
This does not work:

#define err_printf(fmt,...) console_show(), printf(fmt, ## __VA_ARGS__)


This works fine:

#define err_printf(fmt,...) console_printf(fmt, ## __VA_ARGS__)

a1ex

Fixed it locally.

Still, wondering why I've got random names for the last word, both in QEMU and on the camera. Could be a bug in Canon's vsnprintf as well.

dmilligan

so I'm wondering if we should load string lib by default for this reason, thoughts?

a1ex


a1ex

Getting close to a major bugfix update for the Lua scripting engine, including an API testing script (which already revealed a few bugs in the ML core). I'd like to ask everyone interested to take a look at this pull request:

https://bitbucket.org/hudson/magic-lantern/pull-requests/683/lua-scripting-lots-of-fixes-plus-api/commits

I'm tempted to include this one as well (C stdio routines from dietlibc, which give a major speedup on text file I/O because of buffering), so I'd like some review and/or testing here as well:

https://bitbucket.org/hudson/magic-lantern/pull-requests/689/lua-stdio-routines-from-dietlibc-with/commits

After merging those two, the next big thing on the Lua side will be lua_touch, where dmilligan is working on some really nice stuff for touch-screen cameras (interactive console, touch keyboard, gestures, IME integration...)

lumenmikie

I've been trying my hand with Lua and trying to write a script that would allow me to record a series of video clips at particular intervals. I used recdelay as a template. I did get something working but then wanted to apply it to RAW video recording. So I'm looking for a way to dynamically select the correct function to call, depending on whether raw_rec or mlv_rec or neither is loaded. Currently I've just hot wired the 2 functions in lua_movie.c to call raw_start_stop(0,0) unconditionally, e.g.

static int luaCB_movie_start(lua_State* L)
{
    if (shooting_type != 3 && shooting_mode != SHOOTMODE_MOVIE)
    {
        return luaL_error(L, "Not in movie mode");
    }
    else if (RECORDING)
    {
        return luaL_error(L, "Already recording");
    }
    else
    {
    raw_start_stop(0,0);
        //movie_start();
    }
    return 0;
}


Is there a way to determine which modules are loaded when the lua module is loaded? If someone can point me towards an area of the code that does this sort of thing, I'll try to make a more reliable patch to these functions.

Magic Lantern and now Lua are fantastic tools. I've used it for HDR and astro imaging with my 500D for over a year and really find it allows me to do things I otherwise couldn't possible do.

Thanks for the help,

Mike Hayford

PS: here's an example time lapse of Jupiter that I made from data acquired by the time lapse video script.
https://goo.gl/photos/2TzkUxBGMEisTjVH9

a1ex

Here's a code snippet that may help you, from this script:


    if menu.get("Movie", "RAW video") ~= 1 then
       print("Please enable RAW video recording (raw_rec).")
       return
    end


menu.get returns 0 or 1 for boolean menu items (on/off), or nil if the menu was not found (in other words, the module was not loaded).

BTW, movie.start() applies to RAW/MLV as well, with no other changes needed (the same script I've linked above uses this feature).

lumenmikie


a1ex

Just merged lua_fix. What's interesting:

- strict.lua (this may break your scripts, but should be easy to fix)
- api_test.lua: this is intended to test the entire functionality; feel free to add tests for any API that is not yet covered, or for new APIs
- example scripts now working (tested on 5D3)
- exposure setters now working (with pretty harsh tests passing in api_test.lua); max roundoff error is 1/8 EV for integer raw requests, and 1.5/8 EV for arbitrary requests
- focus backend: fixed a crash when Step Delay was disabled (fix also applies to core functionality, e.g. follow focus, raw focus)
- stdio routines (io.write, io.stderr:write, placeholder for implementing io.read)
- file I/O API more or less functional (append, seek, buffering, delete)
- logger: module that prints to console and also saves to a log file (dmilligan)
- a handy macro for integer reversible scaling: RSCALE(RSCALE(x,num,den),den,num) = x for any num > den > 0 (except overflows); tested for 1 <= den <= num < 1000, -1000 < x < 1000
- running "make" in the modules/lua directory will also check all the scripts for syntax errors
- complete list at https://bitbucket.org/hudson/magic-lantern/pull-requests/683/lua-scripting-lots-of-fixes-plus-api/commits

Sorry for the rushed merge from 3 months ago (when I actually got time to try it, I found it unusable*), but it wasn't something I could fix quickly...)


*) the best example is this changeset, which shows the ISO setter was never tested (I'm not talking about model-specific differences; it simply did not work from the beginning). To me, that's really basic functionality that should be tested before merging pull requests...


Anyway, I'm sure there are still rough edges, but at least the basics should be working now.