Albert-Jan Brouwer

Jack, Improved error handling is definately useful. But using error codes to specify what went wrong is somewhat limited. Oftentimes you would like to include runtime variables in the error. For example, when a function fails to open a file, including a path+filename as part of the error is helpful to the user. With error codes you are limited to generic error descriptions such as "could not open file" or "access denied". This CAN be done at runtime by abusing the source field of the error cluster as a general purpose string. Resolve any error code to a string using the error code database and format any further explanation including runtime variables. Prepend that string to the source string of the error cluster. By marking such "explained" errors with a special error code, your error handler/logger/window can be signalled avoid further resolution and instead display the source string verbatim. There are a couple of VI's in the "source/library/error handling" subdirectory of the LuaVIEW distribution that assist with doing so. The distribution is downloadable here: http://www.citengineering.com/LuaVIEW/download.html The error handling VIs are self-contained (do not depend on Lua) and thus can be used with arbitrary LabVIEW code. If you in addition wrap your LabVIEW code in Lua code, you can have an actual exception mechanism with all the corresponding advantages. For an explanation see: http://www.citengineering.com/luaview/manu...rror%20handling --- Albert-Jan

There is LuaVIEW (http://www.citengineering.com/LuaVIEW/index.html) if you need a scripting language (Lua) but do not need TCL in particular. Note that when tying a scripting language to LabVIEW, a diagram node containing code is the last thing you'd want to use for specifying scripts: such code cannot be changed once your application is running. That defeats half the point of using an interpreter or a compiler/VM pair (the other half being control over execution).

Also, if the VI being referenced is reentrant, you can instantiate it. For running multiple instances, use the prepare for reentrant run option flag of Open VI reference. This does not work for templates though.

After some initial puzzlement, I found static references to be rather useful. Since the VI pointed to by the static reference will be loaded when the containing VI is loaded, and included in a build when the containing VI is built, you can use it to get around the hassle of having to have a proper path for dynamically loaded VIs (at development time) or having to specifically include dynamically loaded VIs in the build script. Just wire the static reference to a property node, read the "VI name" propery, and use that to open an additional reference for running or calling.