Frequently Asked Questions
- What is scripting?
- Scripting is a generic term for programming a complex and inflexible system
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
- 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
- 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
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
- How fast do scripts run?
- For a review of performance considerations, see this
- 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
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
- 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
- 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
- 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
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.
- 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.
- 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
Go to the Lua for LabVIEW main page