Basic API VIs

Polymorphic data exchange alternatives

Function registration VIs

Advanced API VIs

API objects

License status

LuaVIEW Pull (I16).vi

Retrieves an I16 data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (I32).vi

Retrieves an I32 data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (I8).vi

Retrieves an I8 data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (U16).vi

Retrieves an U16 data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (U32).vi

Retrieves an U32 data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (U8).vi

Retrieves an U8 data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (boolean).vi

Retrieves a boolean data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (flat data).vi

Retrieves the item at the head/bottom of the Lua stack, translates it to a flat LabVIEW data string, and removes the item from the stack, thereby shifting any remaining data items down by one. The most important use for this VI is to transfer compound data from Lua (a table) to LabVIEW (a cluster or array). To perform the translation, this function requires the type descriptor of the LabVIEW type/cluster/array that specifies how the translation is to take place. To use the flat data on the LabVIEW side, unflatten it.

The translation is recursive and thus handles nested clusters and arrays. If no translation is possible, e.g. because a LabVIEW array type is specified but no Lua table is provided, an error is returned. The LuaVIEW manual details which translations are supported.

When the optional default flat data input is wired, its content will be used when either the Lua stack is empty or the Lua data item is nil. Note that allowing an empty stack is somewhat different from the other pull variants. It simplifies the implementation of an optional argument at the end of the argument list such that its omission causes the setting of default data.

When default data is wired and the Lua data item has missing/nil table elements that map into a cluster element that is not inside an array, a partial substition of only these elements is performed so that the Lua-side data need not be fully specified. This is like a bundle by name where some cluster elements are not specified and the default data serves the role of the input cluster.

This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (number).vi

Retrieves a number data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (object).vi

Retrieves an object data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. The returned value is a generic refnum that identifies some LabVIEW side object and must be cast to the appropriate type before use. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (path).vi

Returns the path converted from a string at the head/bottom of the Lua stack. The string is subsequently removed, thereby shifting any remaining data items down by one. Beware that, if so configured, the string to path conversion might treat path seperators in a manner that differs slightly from LabVIEW's string to path conversion. Please refer to the manual appendix describing the various supported data types for details. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (refnum).vi

Retrieves a refnum data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. The returned value is a generic refnum that identifies some LabVIEW side object and must be cast to the appropriate type before use. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Pull (string).vi

Retrieves a string data item from the head/bottom of the Lua stack and removes it, thereby shifting any remaining data items down by one. This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Push (I16).vi

Pushes an I16 data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (I32).vi

Pushes an I32 data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (I8).vi

Pushes an I8 data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (U16).vi

Pushes an U16 data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (U32).vi

Pushes an U32 data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (U8).vi

Pushes an U8 data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (boolean).vi

Pushes a boolean data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (flat data).vi

Pushes a Lua-data item onto the stack after translating it from flat LabVIEW data. The most important use for this VI is to transfer compound data from LabVIEW (a cluster or array) to Lua (a table). To perform the translation, this function requires the type descriptor of the LabVIEW type/cluster/array that specifies how the translation is to take place. The translation is recursive and thus handles nested clusters and arrays. If no translation is possible, e.g. because cluster elements are not named, an error is returned. The LuaVIEW manual details which translations are supported. This VI is part of a polymorphic set that supports pushing various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Push (nil).vi

Pushes a nil data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (number).vi

Pushes a number data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (object).vi

Pushes a LuaVIEW object onto the Lua stack. To Lua it will appear as heavy userdata. This can be used to pass any refnum or other identifier specifying some LabVIEW-side object while attaching a set of methods that can be called, by Lua, on that object. The only requirement is that it can be cast into a generic refnum. Once the object is on the stack, any additional attributes can be attached using the "Set Object Attribute" VI. This VI is part of a polymorphic set that supports pushing various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (path).vi

Converts a path into a string and pushes that string onto the Lua stack. The conversion performed is identical to LabVIEW's "Path to String" conversion function. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (refnum).vi

Pushes a refnum data item onto the Lua stack. To Lua it will appear as light userdata. This can be used to pass any refnum or other identifier specifying some LabVIEW-side object. The only requirement is that it can be cast into a generic refnum. This VI is part of a polymorphic set that supports pushing various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

LuaVIEW Push (string).vi

Pushes a string data item onto the Lua stack. This VI is part of a polymorphic set that supports various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu. When "automatic" is checked in that menu, wiring a different type to the top left input will cause the appropriate VI to be selected automatically.

re_LuaVIEW Pull (flat data).vi

Retrieves the item at the head/bottom of the Lua stack, translates it to a flat LabVIEW data string, and removes the item from the stack, thereby shifting any remaining data items down by one. Use this reentrant variant instead of the non-reentrant variant when pulling lots of flat data to prevent the non-reentrant VI from becoming contended. The most important use for this VI is to transfer compound data from Lua (a table) to LabVIEW (a cluster or array). To perform the translation, this function requires the type descriptor of the LabVIEW type/cluster/array that specifies how the translation is to take place. To use the flat data on the LabVIEW side, unflatten it.

The translation is recursive and thus handles nested clusters and arrays. If no translation is possible, e.g. because a LabVIEW array type is specified but no Lua table is provided, an error is returned. The LuaVIEW manual details which translations are supported.

When the optional default flat data input is wired, its content will be used when either the Lua stack is empty or the Lua data item is nil. Note that allowing an empty stack is somewhat different from the other pull variants. It simplifies the implementation of an optional argument at the end of the argument list such that its omission causes the setting of default data.

When default data is wired and the Lua data item has missing/nil table elements that map into a cluster element that is not inside an array, a partial substition of only these elements is performed so that the Lua-side data need not be fully specified. This is like a bundle by name where some cluster elements are not specified and the default data serves the role of the input cluster.

This VI is part of a polymorphic set that supports the pulling various data types. To change the type being pulled, pop up on this VI's diagram icon and use the "Select Type" sub menu.

re_LuaVIEW Push (flat data).vi

Pushes a Lua-data item onto the stack after translating it from flat LabVIEW data. Use this reentrant VI instead of the non-reentrant variant when pushing lots of flat data to prevent the non-reentrant VI from becoming contended. The most important use for this VI is to transfer compound data from LabVIEW (a cluster or array) to Lua (a table). To perform the translation, this function requires the type descriptor of the LabVIEW type/cluster/array that specifies how the translation is to take place. The translation is recursive and thus handles nested clusters and arrays. If no translation is possible, e.g. because cluster elements are not named, an error is returned. The Lua for LabVIEW manual details which translations are supported. This VI is part of a polymorphic set that supports pushing various data types. To change the type being pushed, pop up on this VI's diagram icon and use the "Select Type" sub menu.

LuaVIEW Close.vi

Closes a Lua for LabVIEW reference as returned by "LuaVIEW Open". This closes the Lua state associated with the references and decrements the function registry usage count. When the usage count reaches zero, the function registry is cleaned up.

This function executes irrespective of the input error so that the reference is closed and registry use count is decremented even when one of the preceeding chained VIs failed. It does not execute when a default (nil) reference is provided, as returned by a failed "LuaVIEW Open" or an uninitialized shift register. Do not close or otherwise use an already closed reference. Though Lua for LabVIEW performs checks to avoid operating on closed states, this is only 99.999% safe.

LuaVIEW Compile.vi

Compiles the provided script string so that it can be executed. This is not compilation to native machine code but rather compilation to bytecode that can execute on the Lua virtual machine instance associated with the provided Lua for LabVIEW reference. Multiple scripts can be compiled. These will be executed in order of compilation.

LuaVIEW Open.vi

Open a Lua for LabVIEW state that can call public and export functions as well as the other types of Lua for LabVIEW function. The resulting state (passed via the Lua for LabVIEW reference) is ready for script compilation and subsequent execution. Once the Lua for LabVIEW reference is no longer required, close it using LuaVIEW Close.vi to free the associated resources.

When the public function registry is not yet initialized and the "auto-init registry" global is set, the registry will be initialized first with all Lua for LabVIEW function VIs in the built executable or, when running under development mode, with all Lua for LabVIEW function VIs in the functions directory of the Lua for LabVIEW toolkit.

Note that the Lua for LabVIEW reference returned by this VI is associated with a new and unique Lua state which entails an instance of the Lua virtual machine as well as the data space involved in compiling scripts and executing the resulting bytecode on that virtual machine instance. Scripts that run on different Lua states therefore have separate variable spaces.

LuaVIEW Pull (poly).vi

Pull a data item of a polymorphic type from the Lua stack. This can be an argument in case of a Lua to LabVIEW call, or a result in case of a LabVIEW to Lua call. The data item is retrieved from the head/bottom of the stack and removed, thereby shifting any remaining data items down by one.

LuaVIEW Push (poly).vi

Push a data item of a polymorphic type onto the Lua stack. This can be a result in case of a Lua to LabVIEW call, or an argument in case of a LabVIEW to Lua call. The data item is placed on the top of the stack.

LuaVIEW Swap Task.vi

Swap the script(s) executing under an existing Lua for LabVIEW task. This VI loads, pre-processes, and compiles the new script(s), and signals the task to be swapped to execute the new script(s). This VI does not wait for the task to commence with swapping: any run-time error that occurs on cleaning up the prior script(s) or on executing the new script(s) is not returned by this VI.

re_LuaVIEW Call.vi

Call a Lua-side function. Any elements pushed onto the stack prior to the call are passed as arguments. When the function returns, the stack holds the function result values, if any. The call is protected so that any errors during the function's execution are caught.

Never make simultaneous calls to the same Lua for LabVIEW state.

To be able to make Lua-side calls, open a Lua for LabVIEW base state using "Open Base State" and compile one or more scripts implementing the function or functions to be called using "Compile". Next, the resulting compilations must be executed using "Execute" so that the functions become defined. After that, "Call" can be used on all defined functions. Functions called via "Call" cannot call LabVIEW-side functions and are not interruptable other than through throwing an error.

re_LuaVIEW Do Script.vi

Compiles and executes a script while also opening and closing the Lua for LabVIEW reference (which creates and destroys a virtual machine instance) required for this purpose. Use the primitives instead of this VI when manipulation of the script execution state is required.

re_LuaVIEW Do Task.vi

Do a Lua for LabVIEW task. This prepares a task, runs it, and waits until the task is done before returning. Any error thrown during the task's execution is returned.

re_LuaVIEW Execute.vi

Execute one or more previously compiled scripts until the last script completes or an error occurs and any cleanup handling has run its course. This simple iterator does not do run-time script management such as probing as tasks do. Neither does this VI allow for indexed functions to be called. To do that a custom iterator must be implemented.

re_LuaVIEW Run Task.vi

Runs a new Lua for LabVIEW task. This prepares a task and runs it. This VI returns when the task has progressed beyond its initialization. When the task fails while initializing, its error is returned.

LuaVIEW Bootstrap.vi

Bootstrap an application that uses Lua for LabVIEW with a Lua script. Note that this VI is intentionally non-reentrant so that only a single bootstrap script can be active at any one time. The bootstrap script can set the global configuration and register functions prior to starting further Lua scripts. To do so, the bootstrap script has access to all C functions and a small set of Lua for LabVIEW functions:

configure(tab:configuration)

str:path=bootstrap_path()

str:path=toolkit_path(str:toolkit,[str:subpath])

str:kind=app_kind()

register.public(str:path)

register.public_dir(str:dirpath)

do_script(str:name,[str:script])

The last four are identical to the standard Lua for LabVIEW functions of the same name. The configure() function is used to set the configuration globals. See the bootstrapping example VI for details. When the bootstrap script was loaded from a file instead of passed as a string, the bootstrap_path() function returns a path to the directory containing the script. This allows the resource base path or script search directories to be configured relative to this path.

Though bootstrapping can also be done with LabVIEW code that sets configuration globals and calls the LabVIEW API to register functions, the advantages of a bootstrap script are that it has convenient error handling and can be changed when deployed with a built executable.

LuaVIEW Cleanup Public Registry.vi

Requests a cleanup of the public Lua for LabVIEW function registry. This will cause the public function VIs as well as the registry daemon to be unloaded. Use of this VI is not necessary when the "Unload Functions ASAP" global is set. If the registry is not initialized, this function will return immediately. If the registry is still in use (there are running scripts that use public functions), this VI will fail. If the registry was initialized but no longer in use, this VI will return after unloading completes. Do not simultaneously register and cleanup.

LuaVIEW Register Private Function Directory.vi

Tries to register all VIs ending in "_lua.vi" in a directory or llb and, recursively, in any subdirectories or llbs, or, alternatively, inside a built executable as private Lua for LabVIEW functions with the provided Lua for LabVIEW state.

LuaVIEW Register Private Function.vi

Open a reference to a Lua for LabVIEW function VI and add it to the Lua for LabVIEW state's private registry so that any script running under that state can call the function.

LuaVIEW Register Public Function Directory.vi

Tries to register all VIs ending in "_lua.vi" in a directory or llb and, recursively, in any subdirectories or llbs, or, alternatively, inside a built executable as public Lua for LabVIEW functions.

LuaVIEW Register Public Function.vi

Open a reference to a Lua for LabVIEW function VI and add it to the public registry. Any Lua for LabVIEW states that are opened after the function was registered will be able to call the function (unless "Use Public Registry?" was reset to false on opening the state). If the function VI was already registered, no further resources will be allocated.

LuaVIEW Register and Set Indexed Function.vi

Registers an indexed function with the Lua for LabVIEW state's private function registry and sets the function as part of the state's variable space so that it can be called by name. Indexed functions are functions whose LabVIEW-side functionality is specified via an index instead of a function VI reference. When an indexed function is called, "LuaVIEW Execute Iteration" will return and leave the handling to its caller. Thus, indexed functions can be implemented as part of anything that allows selection via an index (typically a case of a case structure).

LuaVIEW Register and Set Module Function.vi

Registers a module function with the Lua for LabVIEW state's private function registry and sets the function as part of the state's variable space so that it can be called by name. When the function is to be exported, as denoted by an exclamation mark prefix to its synopsis, it is also registered with the public function registry. If an exported module function of that name and table is already present, it will be replaced. This implies that the module or module instance called via an exported module function can change while a script is running. Replace exports only when they offer equivalent functionality.

LuaVIEW Revoke Exports.vi

Revokes the functions exported from a module or module instance. When your module performs cleanup actions after which calls to export functions result in erroneous or undefined results, and there is a risk that scripts that use the export functions are still active when your module cleans up, it is necessary to revoke the export functions before performing those cleanup actions. To do so, first call this VI from a dedicated module function, say "revoke_exports()". It is not fully safe to call this VI inside the cleanup function since an export call might be made in the short timespan between entering that function and revocation.

Note that if you want the scripts that use the export functions to switch over to using a subsequently initialized module instance without their ongoing calls being in risk of failing, the new module instance must be initialized within the (configurable) "export timeout" period after this VI is called. This VI only throws an error when it is NOT called as part of a non-export module function.

LuaVIEW Cast Gen Ref to VI Ref.vi

This VI casts between incompatible refnum types. Refnums passed to Lua only carry their value and not their type. It is therefore required to cast them to a generic type on passing them to Lua and back from the generic type to their actual type on retrieval from Lua. Since LabVIEW does not allow this for safety reasons, code such as contained in this VI is required to trick the LabVIEW compiler.

LuaVIEW Cast VI Ref to Gen Ref.vi

This VI casts between incompatible refnum types. Refnums passed to Lua only carry their value and not their type. It is therefore required to cast them to a generic type on passing them to Lua and back from the generic type to their actual type on retrieval from Lua. Since LabVIEW does not allow this for safety reasons, code such as contained in this VI is required to trick the LabVIEW compiler.

LuaVIEW Clear Stack.vi

Clears the stack. This can be used to remove any remaining arguments from the stack before starting to push results. This VI is rarely required since the argument pull VIs already remove their arguments from the stack. It might come in handy after performing an in-place operation on a stack argument.

LuaVIEW Register Callback Event.vi

This advanced function allows to register or unregister a debug callback event that can be registered with an event structure and will report the current line number in a script.

LuaVIEW Callback Event Record.ctl

This is the data cluster that passes event information into the user event frame for handling the according event.

Controls and Indicators

LuaVIEW reference The Lua for LabVIEW reference with which this event is associated.

name The name of the current script, if it is a line count event and the event was registered with "user event with name (3)".

type The type of event: count (0), single step (1), line break (2), call break (3). NOTE: Currently only count will be returned.

line The current line count on which the execution of the script execution on this Lua for LabVIEW reference is.

LuaVIEW Get Current Line.vi

This function retrieves the line number at which the script is currently. This only returns a valid number if the reporting of line numbers has previously been enabled through an according call to the LuaVIEW Register Callback Event.vi.

LuaVIEW Get Object Attribute.vi

Gets an attribute of a Lua for LabVIEW object. The object must be located at the bottom of the stack. The retrieved value is pushed onto the top of the stack for later pulling.

LuaVIEW Get Task Script Directory.vi

Returns the directory holding the task script. When not a task, task script remote, or task script provided as a string, an empty path and error is returned.

LuaVIEW Get Task State Reference.vi

Returns a reference to the task state object when the Lua for LabVIEW state is part of a task context. Otherwise an error is returned. This VI is used by Lua for LabVIEW functions that operate on the task state of the calling context.

LuaVIEW License Status.vi

Query the state of the Lua for LabVIEW license on the local machine. This function allows an Lua for LabVIEW application to query the current license state of the Lua for LabVIEW library and to optionally display the license activation dialog.

LuaVIEW Open Base State.vi

Opens a Lua for LabVIEW base state which is essentially an instance of the Lua virtual machine with associated storage, and returns a reference to it. A base state lacks the infrastructure and preparations required for calling LabVIEW from Lua. Instead it is intended for hosting functions to be called from LabVIEW via the "Call". To define callable functions, compile and execute a script containing function definitions for a base state.

Closing a base state is not required when it is only opened once during an application run: open base states are closed when the Lua for LabVIEW VIs unload. When repeatedly opening a state for the same purpose, the "close identifier" can be used to automatically close stale states.

LuaVIEW Open Private State.vi

Open a Lua for LabVIEW state that does not make use of the public function registry nor any module export functions. To use the returned state, register and set any private and indexed functions, compile a script, and execute it. Once the Lua for LabVIEW reference is no longer required, close it using "LuaVIEW Close" to free the associated resources.

Though anything that can be done with a state returned by this function can also be done with a state returned by "LuaVIEW Open", it is sometimes desirable to use this VI to prevent the loading of the infrastructure associated with the public function registry.

The opened Lua for LabVIEW state holds a new instance of the Lua virtual machine. Scripts that run on different Lua for LabVIEW states therefore have separate variable spaces.

LuaVIEW Poll Print Buffer.vi

Each Lua for LabVIEW state is provided with a private print buffer. Using the lv.print() function, text can be printed to this buffer on a per-script or per-task basis. This VI allows polling of the content of these print buffers for display purposes. One option is to empty the entire content, and display that. This limits the amount of displayed text to the size of the circular print buffer (32768 characters). Alternatively, the read index can be used to return only the newly printed text, if any. By frequently polling the buffer and appending the returned text to previously read text, you can display more text than fits inside the buffer.

This VI is exceptional because it is designed to poll the print buffer of a Lua for LabVIEW state while other operations on that state are ongoing: normally actions on the same Lua for LabVIEW state must be serialized. This implies that it can be used inside a loop that is asynchronous from the script or task execution.

LuaVIEW Push Value.vi

Pushes the value located at the bottom (front) of the stack onto the top of the stack without removing it. This can be used to duplicate a stack element. A likely use is to duplicate a table or Lua for LabVIEW object (which Lua passes by reference) for later in-place modification.

LuaVIEW Set Object Attribute.vi

Sets an attribute on a Lua for LabVIEW object. When calling this VI, the value to set (any type) must be at the top of the stack and be preceded by the object on which to set the attribute. The value being set is removed from the stack. The function's documentation should list these attributes. Note that attributes are read-only on the Lua side. Object attributes can be read from in the very same way as table attributes.

Attributes can be used to adorn an object being returned by a Lua for LabVIEW function with invariant object properties. An alternative use is for an attribute to maintain some object-instance specific variable that changes between method calls, e.g. something like the read/write/seek offset associated with a file handle.

LuaVIEW Stack Elements.vi

Returns the number of elements on the stack. This is typically used to determine the number of arguments remaining on the stack in case of a function that accepts a variable number of arguments. Functions with a fixed number of arguments can simply assume those arguments to be present on calling, provided that their documentation/synopsis is in sync with their implementation, because automated argument checking ensures this.

LuaVIEW Stack to String.vi

Removes the elements present on the stack and converts them into a space-separated string terminated by a linefeed that is suited for printing. This VI is used by print() and similar functions. When converting an element to a string, this function uses the "tostring" function, which respects "__tostring" metamethods. You can therefore customize the print formatting by overriding "tostring" or defining meta methods.

re_LuaVIEW Execute Iteration.vi

Execute compiled script(s) for a single "resume" iteration and return to LabVIEW when the last script completes, a LabVIEW-side call is made, a yield is performed, an error occurs, and so on. Iterating over resumptions allows LabVIEW-side stuff to be interspersed with virtual machine execution. Any custom LabVIEW-side stuff, such as indexed functions or execution management must be implemented as part of the loop inside which this VI is called.

re_LuaVIEW Incite.vi

Incite a task to send a reply. This is done by sending the task to be incited a message containing the task identifier of the current task. The incited task can then perform whatever service it is designed to provide and use that identifier to send a reply message when it is done. This VI returns on receiving the reply unless an error occurs.

An error occurs when the provided Lua for LabVIEW reference is not associated with a task (this VI is not called inside a task) or when the task being incited does not exist, is in error mode, or fails to reply before the timeout expires. BEWARE: the task doing the incitation should not be receiving other types of messages at the same time lest these get confused with the incitation reply.

Incitation provides an easy means of synchronously using a service provided by an asynchronous task. More complex message/reply mechanisms can be coded in similar fashion: this VI merely constitutes a convenience implementation of the instigating side of the simplest conceivable message/reply mechanism. Module export functions also allow a synchronous service to be offered and involve less overhead on account of not requiring a context switch. The advantage of a message/reply mechanism is that the service can be implemented as a task script that can also add asynchronous actions such as periodic updates into the mix.

re_LuaVIEW Plug-in Handler.vi

This VI can be used inside a plug-in to assist in handling task signals. Examine the plugin template to see how it is deployed. The built-in handling of task signals does not work while called into a plug-in. Using this handler or similar code allows a plug-in to nevertheless respond to task signals. This handler limits itself to waiting for the timeout to expire when the plug-in was not started from a task.

obj_LuaVIEW Task List.vi

Lists Lua for LabVIEW tasks and allows operations on tasks in the list. A particular task is specified through its identifier and manipulated through a reference to its state object.

This VI is only marginally part of the API: those methods that are in common use by function VIs can be deemed safe for use provided that typedefs are used so as to be forward compatible with extension of the method enum or typedef clusters (only use unbundle/bundle by name, and so on).

Beware that when using this VI to send a request or message, the receiving task's request occurrence, as returned by this VI, must be set. This unfortunate inconvenience was made mandatory to avoid the superfluous context switches that can occur when occurrences are set from within a non-reentrant object.

main script

identifier

class

description

mode

handler

LuaVIEW reference

scripts

hide

active

error msg

defer

launch

main path valid

start time

swap time

task VI

prefsys

priority

signal flags

allow mask

handle mask

disallow manual

main script

identifier

class

description

mode

handler

LuaVIEW reference

scripts

hide

active

error msg

defer

launch

main path valid

start time

swap time

task VI

prefsys

priority

signal flags

allow mask

handle mask

disallow manual

path

description

text

parent index

version

re_obj_LuaVIEW Task State.vi

Instantiated per task. Holds the state of a task and allows for asynchronous communication with a task. Must be called by reference. A reference can be obtained from the task list.

This VI is only marginally part of the API: those methods that are in common use by function VIs can be deemed safe for use provided that typedefs are used so as to be forward compatible with extension of the method enum or typedef clusters (only use unbundle/bundle by name, and so on).

main script

identifier

class

description

mode

handler

LuaVIEW reference

scripts

hide

active

error msg

defer

launch

main path valid

start time

swap time

task VI

prefsys

priority

signal flags

allow mask

handle mask

disallow manual

path

description

text

parent index

version