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 LuaVIEW, 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 LuaVIEW a test executive?
Not quite. LuaVIEW 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 LuaVIEW, 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 LuaVIEW 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 LuaVIEW state probe, a graphical debugger, an interactive console, and a generalized unit tester.
What about future Lua versions?
Since Lua is statically linked into LuaVIEW, nothing will change for existing applications unless you upgrade to and rebuild with a new LuaVIEW distribution that includes the new Lua version. Currently, plans to release a LuaVIEW distribution based on a Lua version newer than 5.0 are on hold because the 5.1 Lua release made changes to the API that could not easily be accomodated in LuaVIEW.
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 LuaVIEW distributions with LabVIEW 7.0 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 LuaVIEW. Therefore, the plan might change.
Will recent Intel-based Macs be supported?
No. Jobs has joined the dark side. We do not support evil.

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 LuaVIEW 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. LuaVIEW 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 LuaVIEW?
LuaVIEW provides some OOPish features. LuaVIEW modules and plug-ins can be instantiated. LuaVIEW 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 LuaVIEW 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 LuaVIEW 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 LuaVIEW 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 LuaVIEW 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 LuaVIEW 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 LuaVIEW, it is thoroughly scriptable. This was achieved by making pervasive use of LuaVIEW. The data logger therefore both requires LuaVIEW and provides an example of a complete application based on LuaVIEW.
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?
No: no time limit, no crippled functionality, no registration wizard, no activation code, no splash screen, no nag dialogs, no removed or password-protected VI diagrams, nor any other such misfeature.
I am using LuaVIEW. When do I need a license?
No license is required for non-commercial or personal use. For commercial projects, a license must have been acquired when the application is deployed or released as a product.
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 license required?
It depends. When providing a LuaVIEW-based solution as part of the consulting job, then yes. When hired to do work on an existing LuaVIEW deployment run by that organisation, then no.
Is a new license required when upgrading a licensed solution or product to a new LuaVIEW release?
No
Is a new license required when revising a licensed product or solution?
When new features are added, the existing license remains valid: a license covers a particular solution deployment or product for its entire life cycle. When rewriting a solution or product so as to solve a different problem, or when deploying a solution at an additional customer, an additional license is required.
When is a site license advisable?
In addition to providing a blanket license for a department or organisation, a site license is advisable when LuaVIEW is used in a manner that matches neither a solution deployment nor product as defined in the licensing conditions. For example, when LuaVIEW 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 LuaVIEW data logger be licensed separately?
No. Acquiring a LuaVIEW license suffices when making commercial use of the data logger. The same licensing conditions apply.

Go to the LuaVIEW home page