L2L
-
Posts
12 -
Joined
-
Last visited
-
Days Won
1
Recent Profile Visitors
1,759 profile views
L2L's Achievements
Newbie (1/14)
3
Reputation
-
Hey guys, Thread is old and haven't checked up on it in awhile. I have been buzy refining my Lua-to-LabVIEW binding library which I call GLue now. The major improvements are: The API is now more simple and consistent Added support for both 32bit and 64bit Windows Does not link with the C runtime, reduces external dependencies (was quite a bit of work) Does not link implicitly with the LabVIEW executable/runtime (portable accross LabVIEW versions) Hundreds of unit tests Multiple large industrial applications already developed and running flawlessly for last couple of years A welcome side effect from this effort is the ability to debug embedded Lua scripts remotely via the excellent ZeroBrain Studio. This allows for first-class Lua development & debugging within LabVIEW.
-
I've looked a bit closer and the hack I described does not work. Will follow your great idea of a post install step - thanks
-
looks like you can do it, but you have to make the path changes without the 64bit version of the dll in the directory you specify in the CLFN - because if it is there LabVIEW will try and load it while your inside the CLFN configuration utility, and then it updates both of your CLFNs paths in the conditional disable structure to point to a single dll
-
Nope... LabVIEW still wants to load the 64bit dll - even in the conditional disable structure, with a TARGET_BITNESS of 64 it then complains it can't find the function/library
-
Wow, didn't know you could do something like that. I'll quickly go check if its going to work
-
Got bit of a problem, the call library function node and LabVIEW can switch between 32-64 dlls by using "*" in the file name when specifying a path. This is fine for a dll that I build.. where I can add '32' or '64' to the name to differentiate between the two, but I also use the lua52.dll that has the same name for both 32bit and 64bit versions. Now if only I could use the "*" in the CLFN to automaticly choose the correct directory which I could name '32\lua52.dll' or '64\lua52.dll' other than that.. I could specify the path from the block diagram, but then I loose automatic dependency detection.
-
Right, I've gathered what I have so far and attached it... been following the guides on how to license/package, but VIPM is getting stuck with "building source distribution" tried changing and fiddling with no success. So trusty old zip it is. Just unzip and go to the public/examples directory and open "MLua Tests.vi" did put some comments in there - but feel free to ask whats going on. oh before I forget, its LabVIEW2010 and up - 32bit. Still have to test it on later versions of LabVIEW though, kinda stuck on 2010. MLua.zip
-
Thanks Daklu, you've really made me think about this. I suppose I will also need to go find out from the partners at my company what their feelings are - if I even have a choice of how to release it. Personally I'm leaning towards opening it up to the community.
-
no, you have a single labview callback VI per MLua instance - different behaviours are achieved by the first three arguments of the call - LV.Call(action num - 0,namespace - 'test', command - 'ToUpper'.. I didnt expand the 'LabVIEW Call' cluster in the example to show this - sorry about that
-
LV.Call is a Lua C function which takes the arguments - converts them to a LabVIEW cluster and then passes it to LabVIEW for processing... after which the variant return data from LabVIEW is converted back into Lua data.
-
The nice thing with lua 5.2 is that you can use coroutines in many more places, hence calling LabVIEW from Lua can be done from within pcalls ... and LabVIEW side errors can be converted directly into Lua errors, which also makes the binding between the two more intuitive. To make the interface easier for me to use, added recursive data translation functions to convert nested LabVIEW types to Lua tables and vice versa. I'm at the stage where I want to share it with the greater LabVIEW community, but dont know how much interest there is for text based scripting inside LabVIEW - I know it realy helped me on some large scale projects of mine. Maybe... I should just consider making it a free addon, but at the same time I feel I spent a good bit of time and effort on it (just thinking out loud)
-
Hi everyone, I have developed over a couple of years my own interface between LabVIEW and Lua (MLua) much like the CIT's pioneering luaview http://luaview.esi-cit.com/index.html. The two key differences are: 1. MLua dynamicly links with the Lua binaries 5.2 distribution, ensuring compatibility and allowing the use of external Lua modules coded in C. 2. A much simpler interface, no need to understand the Lua stack based API. Example: Wondering if I should go through the effort of making it an addon on the tools network... and if so, what type of license and cost. Any input is welcome
