Frequently Asked Questions

General questions

What is scripting?
Scripting is a generic term for programming a complex and inflexible system using a relatively easy and dynamic language. Examples are JavaScript for scripting web browsers, PHP for scripting web servers, Visual Basic for scripting many different Windows applications, and so on.
But LabVIEW is easy to program with, surely it does not require scripting?
For small-scale programming this is true: wiring diagrams can be considered a (graphical) form of scripting. However, LabVIEW can also be used for large-scale programming where the challenge is to avoid complexity and retain flexibility. When an application is running or built as an executable, the options for reprogramming it are respectively limited and non-existent. These are examples of circumstances where scripting can help out.
Reprogramming a built executable?
Yes. Scripting languages are interpreted. When you use Lua for LabVIEW, the Lua interpreter (which, for performance, is split into a byte code compiler and a virtual machine) gets included into your application so that scripts can be changed and their execution controlled at run time.
Why Lua?
Lua was chosen because it is the only modern scripting language that could be sufficiently customised to call LabVIEW while running inside the LabVIEW runtime. Calling LabVIEW is a requirement for scripting. Being able to run scripts inside the LabVIEW runtime allows for portability, ease of deployment, and tight integration with LabVIEW. Even if other languages would have been as customisable, Lua would still be a good pick. Competitive scripting languages have more special-purpose features and function libraries, but this makes them harder to learn and use. Since LabVIEW already includes extensive function and VI libraries, adding a large set of mostly redundant functionality would be more taxing than helpful. In short, Lua complements LabVIEW with little overlap.
Is Lua for LabVIEW a test executive?
Not quite. Lua for LabVIEW includes all the hard-to-implement features of a test executive, but instead of a graphical user interface (GUI) a scripting interface is provided. Though more powerful than a GUI, scripts are unsuited for operators without programming skills. To create a GUI-driven test executive based on Lua for LabVIEW, implement front panels that interface to the scripting back end. This can be economical when the test problem is sufficiently out-of-the-ordinary to anyway require a custom GUI. On the other hand, there might well be an existing test executive that provides a close fit when your requirements are fairly standard. For example, TestStand is good at pass/fail manufacturing tests and has integrated report generation features.
How does Lua for LabVIEW relate to the "LabVIEW scripting feature"?
It does not. The "LabVIEW scripting feature", which is still under development by NI, exposes the object embedding hierarchy of the LabVIEW development system, diagrams in particular, as property and invoke nodes. This allows LabVIEW to wire LabVIEW: the "scripting feature" is concerned with code generation, not scripting.
What's up with the version numbering?
Releases are versioned using the major.minor.fix format. The major number will not bump unless the release breaks backwards compatibility. The minor number bumps whenever a release adds new functionality. The fix number will bump for a release that fixes bugs but does not contain new functionality.
What will future releases offer?
Future releases will incrementally add features to the peripheral functionality. These are likely to include additional examples, RT/OS support, a Lua for LabVIEW state probe, a graphical debugger, an interactive console, and a generalized unit tester.
What about future Lua versions?
Since Lua is statically linked into Lua for LabVIEW, nothing will change for existing applications unless you upgrade to and rebuild with a new Lua for LabVIEW distribution that includes the new Lua version. While Lua for LabVIEW 1.2.x and earlier where based on Lua 5.0, Lua for LabVIEW 2.0 is based on Lua 5.1. Currently, plans to release a Lua for LabVIEW distribution based on a Lua version newer than 5.1 are under consideration but no decision has been made.
What about future LabVIEW versions?
In theory, all it takes to carry forward the toolkit to a new LabVIEW version is a recompile. Consequently, the plan is to compile new Lua for LabVIEW distributions with LabVIEW 7.1 for some time to come. In practice, there is a small chance that a new LabVIEW version will break things. Also, there is a risk that the new LabVIEW version will introduce features so compelling that it would be silly not to use them with Lua for LabVIEW. Therefore, the plan might change.

Usage and programming

How fast do scripts run?
For a review of performance considerations, see this appendix.
How can I debug scripts?
Errors produced by scripts contain helpful information. Read them. A full GUI debugger might be added in a future release. Until that time, the "retrieve scripts" option of the "Task Manager", print or lv.print statements, and the functions in the "debug" C library can help out.
I tried to run an example script on my Mac, but it failed. What gives?
Probably, a path specified in the script requires adjustment. Add a leading separator to create a relative path that works on the Mac. See the discussion of the path data type for an explanation.
When I use Lua for LabVIEW and exit LabVIEW, there is a delay. Why?
This is caused by the public function registry being cleaned up. By default, public functions are held in memory by a background daemon when the last script is done so as to not have to reload them the next time a script is started. This behaviour can be disabled by setting the "unload functions ASAP" configuration Boolean. To programmatically or manually unload the registry, use the Cleanup Public Registry API VI or the "Function Manager" user interface.
But why does this daemon and the registered functions not show in the VI hierarchy?
They are marked as "system" VIs. These do not show up in the VI hierarchy. This was done to reduce the amount of hierarchy clutter. To view the loaded functions, use the "Function Manager" user interface instead.
Can pre-compiled scripts be used?
No. Lua has features for caching compiled byte code (actually, the Lua VM uses 32-bit opcodes) so that compilation can be skipped when scripts are executed more than once. Lua for LabVIEW does not expose this functionality so that script execution is always preceded by compilation. This keeps things conceptually simple. The Lua compiler is pretty fast so that systems able to run LabVIEW should have no trouble with compiling typical scripts in a fraction of a second. The compilation memory overhead is negligible relative to what LabVIEW gobbles up.
Can I do object oriented programming (OOP) with Lua for LabVIEW?
Lua for LabVIEW provides some OOPish features. Lua for LabVIEW modules and plug-ins can be instantiated. Lua for LabVIEW objects and modules allow for encapsulation. This enables a convenient OOPish calling style from Lua scripts that use LabVIEW, but there is no inheritance, no interfaces, and no abstract classes. Consequently these Lua for LabVIEW features do not support a  full OOP design capability. When structuring a design with LabVIEW, you can use frameworks (GOOP, OpenGOOP, etc.) that intend to provide a more complete OOP capability. Since these use VIs as objects, and VIs come with a lot of instantiation and resource overhead, do not expect to be able to write applications that scale beyond lowish instance counts or rates using such a framework. When structuring a design with Lua, you can use tables as objects with methods, attributes, and inheritance as explained here. Since tables are very light-weight, applications that require lots of instances are eminently feasible. Before going OO, consider that the price paid for gaining its abstraction capabilities is loss of explicitness and readability. With some deliberation, it instead tends to be possible to refactor a design into a shallow hierarchy glued together with scripts that use an easy-to-read imperative or data-driven programming style.
Can Lua for LabVIEW serve as a "sandbox"?
A "sandbox" is a protected environment that allows users to play around without being able to damage the rest of the system. The default configuration of Lua for LabVIEW is not optimised for such use. The assumption underlying the default features accessible to scripts is that script writers are not malicious. The "io" library is one obvious tool with which to do damage, but more subtle means exist. Usually, leaving these features enabled is worth more than protection from hypothetical malicious users that should not have access to the system anyway. Still, the scripting environment goes some way towards being a sandbox because it makes it difficult to do accidental damage: only the parts of the system exposed via functions are accessible, and scripts execute inside independent virtual machine instances that can fail without affecting each other. To turn the system into more of a sandbox, you can configure a mandatory import script that sets to nil those functions and libraries whose use you deem undesirable.
I looked at the examples, read the manual, but still find Lua for LabVIEW mystifying. What programming practices should I follow when using it?
To anyone with Unix programming experience, this will hold no mystery since there is a strong similarity between the features of the Unix platform and the features that Lua for LabVIEW brings to the LabVIEW platform. Lua scripts serve the same role as shell scripts, tasks serve the role of processes, "Run Task" is like fork(), the LabVIEW runtime has the role of the OS, G code has the role of C code, the LabVIEW development environment serves the role of a C editor/compiler/debugger, message queues are similar to pipes, signals are like signals, and so on. This similarity is not the result of trying to emulate Unix as such. Rather, it the result of trying to bring the pragmatic and effective programming practices that first evolved with the Unix platform to the LabVIEW platform. Books have been written that detail those practices. See for example Eric S. Raymond's "The Art of Unix Programming", an online version of which can be found here.
Can I use Lua to implement [...]?
Yes. Lua is Turing-complete.

Data logger

What does the data logger have to do with scripting?
Though the data logger solves a different problem than Lua for LabVIEW, it is thoroughly scriptable. This was achieved by making pervasive use of Lua for LabVIEW. The data logger therefore both requires Lua for LabVIEW and provides an example of a complete application based on Lua for LabVIEW.
Do I need to learn Lua in order to use the data logger?
Most features that can be scripted can also be accessed through a LabVIEW API and LabVIEW-implemented graphical user interfaces. Operators therefore do not need learn how to script. Application programmers need to adjust some scripts in order to configure the system, but can choose to stick with LabVIEW for customisation.
What instrumentation or data-acquisition interfaces are supported?
Anything that LabVIEW can access. Since the system runs inside the same LabVIEW runtime as any LabVIEW driver code, signals can be efficiently written to tags, once acquired.

Copying and licensing

Are there any built-in restrictions?
Yes: this release of Lua for LabVIEW adds a license check feature to help control who is making use of it. It will not run without acquiring a valid license from Test & Measurement Solutions. Other than that, no splash screen or nag screens are present, no removed or password protected VI diagrams are used. Without a valid license the creation of a Lua state will simply fail with an error.
I am using Lua for LabVIEW. When do I need a license?
You will always need to acquire a license from Test & Measurement Solutions for the computer you intend to use Lua for LabVIEW on. There are evaluation licenses available for trying out and testing Lua for LabVIEW. But you need to request such a license by using the License Wizard located under Tools->Lua for LabVIEW->License Info. Such evaluation licenses will generally be limited to a 30 day period but there is room for negotiations. After that you need to acquire a valid time limited or unlimited development license for every computer you intend to use Lua for LabVIEW for development.
My application will only be used inside our company, does that still count as commercial?
Yes it does.
I consult for a non-profit organisation, is a commercial license required?
It depends. When providing a Lua for LabVIEW based solution as part of the consulting job, then yes. When hired to do work on an existing Lua for LabVIEW deployment run by that organisation, then that organization or company would normally be responsible to acquire the necessary licenses.
Is a new license required when upgrading a licensed solution or product to a new Lua for LabVIEW release?
No. The licenses are connected to the computer on which you want to develop or run a Lua for LabVIEW solution. As long as you don't also upgrade to a newer release of Lua for LabVIEW the existing license will remain valid on the same computer.
What about building applications that use Lua for LabVIEW?
The build application will run fine on the development computer that has a valid development license. One runtime license is required per computer or realtime target on which you want to run applications that make use of the Lua for LabVIEW functions, independent how many such applications you intend to run on that computer.
When is a site license advisable?
In addition to providing a blanket license for a department or organisation, a site license is advisable when Lua for LabVIEW is used in a manner that matches neither a solution deployment nor product as defined in the licensing conditions. For example, when Lua for LabVIEW is to be used frequently for small projects for which the acquisition of individual licenses would not be economical. The pricing and coverage period of a site license is negotiable.
Should the Lua for LabVIEW data logger be licensed separately?
No. Acquiring a Lua for LabVIEW license suffices when making commercial use of the data logger. The same licensing conditions apply.

Go to the Lua for LabVIEW main page