MLua - Lua for LabVIEW

[L2L]

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

[Rolf Kalbermatter]

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

Looks a bit like what I have done with LabPython . I think it has some merits to have a more simple interface but LuaVIEW was developed to allow both calling Lua scripts from LabVIEW as well as calling back into LabVIEW from Lua scripts. And that was actually a requirement not just a wish for the project at hand. And LuaVIEW 2.0 will support binary modules too (could be made to work in LuaVIEW 1.2.1 as I have created luavisa and luainterface for a project of a client that integrated LuaVIEW 1.2.1, but it was indeed not exactly trivial to do).

[L2L]

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)

[viSci]

In your example code I am having a hard time understanding how the LV.Call is working. Could you describe the mechanism in more detail?

[L2L]

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.

[viSci]

I still do not understand the lv.call parameter list that you show in your example. How is lv.call referencing a particular vi, can you have more than one lv.call in a script?

[L2L]

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

[Daklu]

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)

Whether you charge for it or not is up to you. I'm biased, as I may occasionally have uses for something like that and would like to see it open sourced. There are some things to consider:

-If somebody pays for it they will expect professional level support. And I can almost guarantee you will get support requests for things that are outside your responsibility. Just last week I had a customer send me a pc because the windows tcp stack had been corrupted. It had nothing to do with my software or Labview, but they expected me, not their IT dept, to fix the problem. (Which I did.)

-Open sourcing it will probably expose it to more people, providing you with more feedback for improvements.

-You might attract developers who want to contribute to the project.

-Good open source tools strengthen he community as a whole.

-It would put pressure on Rolf to continue improving LuaView.

I appreciate the desire to be compensated for your time, and it's not a bad thing. However, there are lots of people in the Labview community who give tremendous amounts of time with no expectations of monetary gain. Ask Jon Green or Jim Kring how much time they spent on OpenG. Ask Omar how long it took him to do VI Tester. Ask Christian or Ben (or any other champion) how much time they spend on the forums helping people out. I spent a year on the Interface Framework before releasing it to the CR.

I'm not trying to pressure you into releasing it open source, just pointing out that there is an established history of friendly sharing in the LV community. Personally I think the community would get a lot of benefit from an easy-to-use, open source scripting tool.

[L2L]

I'm not trying to pressure you into releasing it open source, just pointing out that there is an established history of friendly sharing in the LV community. Personally I think the community would get a lot of benefit from an easy-to-use, open source scripting tool.

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.

[Daklu]

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.

I, like many others, pay my bills by writing LV code for customers. Frequently people/companies want to keep knowledge in-house to preserve a competitive advantage. I believe that by sharing information and techniques we can increase the problem space for which Labview is a viable solution, thereby creating more business opportunities for everyone. (I don't have any data to back up my belief... it's just something I want to be true. It allows me to keep posting on Lava.)

Another aspect to consider is the advertising benefit. How many people would have heard of JKI if not for the excellent free software they have provided to the community? There are other companies on the Tools Network that have released free libraries as well. How much is it worth to have potentially every licensed Labview developer using your product and learning your company's name? Marketing departments drool over that kind of exposure, and you can have it for the cost of the time it takes to prepare the code for public consumption.

To be fair, I don't release *everything* I create that might be useful to others. It can be a difficult decision and I wouldn't fault you or your company if you didn't release it. Nevertheless, I'll hope the partners do allow it.

[L2L]

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

[viSci]

Just poking this old thread to see how things are going with the MLua project...

[eberaud]

Is LuaVIEW going to support Lua 5.1 or higher at some point? I read that LuaVIEW 2.0 was in the making, but that post is 2 years old, and the LuaVIEW website shows that 1.2.2 is the latest version, and uses Lua 5.0. I'm not using Lua for now, so this is not a request, I'm just trying to understand what is going on

 

Edit: sorry to post about LuaVIEW in the MLua thread, the thing is that I'm quoting a post about LuaVIEW that was posted here...

Edited December 13, 2014 by Manudelavega

[L2L]

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.

[madscientist_42]

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.

 

Well, lad, don't be such a tease.  Lua, done right, would be a wonderous addition to  LabView.  (For many tasks, G's good enough.  The problem is, as the sophistication of operations increases, oftentimes you're better off with a little scripting/text language duct tape or processing...because it's easier)

Is it something we can license or are you and your partners inclined to FOSS it?  When can we actually lay our hands on it?

[viSci]

Just curious to know if any capability has been added to allow Lua to call multiple LV vi's within a single script. 

Also is it possible from within LV to single step a Lua script?