Rolf Kalbermatter

Please provide some sample data and VIs. As you refer to the GZIP VIs on the NI thread you need to make sure you have a proper GZIP stream you want to deflate. If you rather have a ZIP file stream you will need the ZIP functions in the ZLIB library instead. The Inflate algorithm simply assumes that the incoming data stream is a properly compressed (deflate) stream and if it is something else it certainly can get upset and cause all kinds of possible problems.

I can only speak for myself, but I do find the GIT workflow not really very easy. I'm sure there are some tools nowadays that make it quite a bit easier to use, but the impressions I got when comparing SVN to GIT several years ago, was that SVN was simply there to use while with GIT you had to learn a whole bunch of magic incantations and remember arcane commands and specific sequences or you ended up with a bigger mess in your project than when using the simple old ZIP-it-all-up source code control system. That all said, if there are people who really want to use GIT and are eager to revive the OpenG initiative if it is moved to a GIT based site, they shouldn't be blocked from it. I don't have much to say about that as my current submission rate to OpenG is just very slightly above 0 and hardly can drop much even if I should decide to not like the new workflow.

There is a small chance that the software originated from the original developer or copyright holder who of course would have the right to relicense his or her work in any way he or she likes. I definitely have used VIs in some of my projects which I have also submitted to OpenG at some point and they don't carry the OpenG license text as that was often added after the initial submission to OpenG. Will be interesting to hear the outcome of this.

Sorry, for answering so late. I was with vacation for the last two weeks. You got a few details not exactly right. 1) LuaVIEW 1.x onl;y supports LabVIEW for Windows 32 bit, LabVIEW for Mac PPC (can be considered obsolete by now as the last OSX version that supported that was around 10.5 Leopard), and LabVIEW for Linux 32 bit. 2) Yes Lua for LabVIEW is copyrighted and we have not given anyone else the right to distribute it on their own. 3) Not sure how VIPM could automatically show it, but you probably mean that you downloaded the 2.0 VIPM package from http://ww.luaforlabview.com and tried to install it through VIPM. The current package tells VIPM specifically to only support the Windows platform since it lacks the shared libraries for the other platforms entirely and wouldn't be able to run there. 4) Lua for LabVIEW 2.0 does currently support LabVIEW 32 bit and LabVIEW 64 bit for Windows. Support for LabVIEW for Mac for OSX 10.8 and higher for 32 bit and 64 bit is under testing and should be released soon. Same for support for LabVIEW for Linux 32 bit and 64 bit. Also support for the NI realtime targets will be added in that release too. Lua for LabVIEW 2.0 supports LabVIEW versions from 7.1 onwards but this is likely to be changed to a higher version in the next major release; most likely 8.5 or possibly even 2009. Since Lua for LabVIEW 2.0 makes use of Lua 5.1 as engine, there were a few minor changes in the Lua syntax itself that could make modifications to Lua scripts necessary. However in the whole unit test suite that comes with Lua for LabVIEW there were only two incidents like that and they were related to the changed long string syntax. Lua for LabVIEW is compiled with the option to still allow the old long string format without equal signs between the brackets for single level long strings but when embedding long strings inside long strings, Lua 5.1 does explicitly disallow using the old syntax. If you have any other questions please don't hesitate to contact me directly here or under info@luaforlabview.com

When you execute a Open VI reference node you ALWAYS receive a new and unique VI reference. This VI reference manages the data space, calling mechanism and also flags like how the VI can be invoked (asynchronous, clone, type of clone, etc, etc). As such it is indeed a completely independent instance of the VI from your original static VI reference. Basically the behavior you expect about VI references used to be true in a far ago past when LabVIEW did not support reentrancy, clones and asynchronous call, but it has changed dramatically under the hood with the introduction of these features. You usually don't feel much about those fundamental changes under the hood, but can run into it in such situations where the current behavior can sometimes surprise you. And there is something else to this. The datatype input to the Open VI Reference node is only there to define the type of the outgoing strict VI reference. The actual VI to instantiate is defined by the VI Path or VI Name input. The VI Open Reference function will then inspect the VI connector pane to match the datatype input and throw an error if they don't match. But nothing of the refnum instance passed to the datatype input is used, except the connector pane info. Not even the name or path as you would otherwise not have to provide that for a static VI reference.

The first LabVIEW to have a native 64 bit version was LabVIEW 2009 for Windows. So this software definitely never was tested with that and the DLL is most likely only a 32 bit DLL too. That all said the OP has provided very little information to allow anyone to say what the real problem may be. From the description it would seem that it is not a 64 bit version. 64 Bit Windows XP was never really used outside of specific use cases as there were indeed many problems with it. So it would seem unlikely that he is using such a system and even more unlikely that he decided to install LabVIEW 64 bit on it. Also if it was a bitness incompatibility the VI would be simply broken and couldn't be run, but what he describes is that the VI returns some number rather than 1 as he expects. So the DLL can be loaded and executed by LabVIEW. As to IOS going 64 bit, that is not exactly the same. You can't really install arbitrary applications on an IOS device. It's either from the Apple App Store or nowhere at all! The App Store will only provide you with apps that are known to be compatible with your particular device. If you want to do your own thing you are all on your own and actually have to jailbreak the device; whoever does that is not going to be bothered by strange errors and incompatibilities! He rather sees them as a welcome challenge to get it working anyhow.

Actually that setting is inherently used by the application builder. Whatever you define as top level VI in there gets intrinsically set this flag and will cause the VI to launch your application.

Auto handle menus at launch: never used that and not sure exactly what it does Run when opened: When the front panel is opened the VI is automatically started. "Show front panel when called": When the VI is called as subVI, this will open the front panel automatically "Show front panel when loaded" . When the VI is loaded into memory, this will open the front panel automatically. so basically they are all related in some ways but do different things at different moments.

I have my own error handler loop in every app. This loop polls a queue for new error messages, displays them in an automatic scrolling string control (that in some applications is optional), logs the error to a log file (and at the same tome looks for really old log files that can be deleted) and also optionally shows a floating but non modal dialog. I have an Error Handler VI which looks just like the standard Error Handler and which does all the things about optional filtering of the errors, looking up appropriate error messages, before sending the error to the queue and also by default clearing the error from the error out cluster. Works pretty neat, quite scalable and has provided me many times with helpful log files about what errors the customer encountered.

I'm sorry to inform you that the library as posted in the first post has several issues in the compiled DLL. Some are caused by newer LabVIEW versions, some by newer Windows systems and some are simply bugs that initially didn't cause issues for some reason. I'm at the moment busy with other work and can't immediately make this work. I do plan to revise the library to work on newer systems and fix some of the bugs but since this is a hobby project that I do in my spare time, this will not be a high priority.

You made a copy paste error with your rinocloud link!

I'm excited to announce that Lua for LabVIEW 2.0 for Windows has been released. Please go to http://www.luaforlabview.com to find out more about this. This release supports the 32 bit and 64 bit versions of LabVIEW for Windows. Support for other platforms including NI relatime targets will follow shortly.

Someone certainly has a very unrealistic view about me here! Your problem are most likely the embedded pointers inside the structure pUiInfo, While it's possible in LabVIEW to allocate memory buffers and assign the resulting pointer to the entry in the cluster it is a big hassle. Also the structure needs to be different for 32 bit and 64 bit LabVIEW since pointers and Handles in Windows are of the size of the system too. An extra problem might be that on the MSDN page there is a user comment that claims that the ANSI version of this function is not working properly. Since LabVIEW uses ANSI strings everywhere this would require your strings to be translated to widechar UTF16 and then to call the W function. All in all it is a lot more work than 30 seconds for sure. And I'm not even sure it is so much safer. The Windows dialog uses Windows controls and they can be targeted from a different process with enough privilege escalation. The LabVIEW controls on the other hand are a lot harder to target from outside the LabVIEW process since they are fully implemented in LabVIEW itself. It would actually help to see what you have done so far. If it is something minor I'm certainly willing to point you into the right direction but I have no inclination at all to build this from scratch.

I think copying a higher version vi.lib to a lower version device driver installation is almost certainly asking for trouble. While the newer version may use new APIs for enhanced operations, the lower version system driver would not support that. That can cause immediate trouble when loading the VIs as they might attempt to link to non-existing APIs in the old driver, or it may be only later at runtime apparent when certain low level device driver methods are invoked with new extended parameters that it does not support. So personally if you want to do such an installation chances are bigger that it will work if you install the highest level driver package with support for as many LabVIEW versions as possible and leave the vi.lib on the older LabVIEW versions with the highest supported driver version. In your example this would most likely mean to install DAQmx 14.0 etc. on the computer to get it install the daqmx and other drivers into the LabVIEW 2011 installation, then rename the LabVIEW 2011 folder temporarily to something else, so that the DAQmx 15.0 installer won't see it anymore and won't remove the DAQmx support from it. This leaves a pretty big change that it will still work after renaming the LabVIEW 2011 folder back after the new drivers have been installed. But as explained earlier I would not recommend that solution for a production quality build system at all as you may end up with obscure errors that are very hard to debug and a bug report to NI won't help much as you work with an unsupported installation.

Theoretically, the shared resources would be upwards compatible such that the 2011 VIs "should" be able to work with the 2015 binary resources (shared system libraries and device drivers). Practically anyone who has written such drivers knows that this is VERY difficult to do and absolutely impossible to guarantee without explicitedly testing it all in every detail. Now take into account that many of the NI drivers are for multiple platforms (Windows 32-bit and 64-bit, Mac OS X 32-bit and 64-bit, Linux 32-bit and 64-bit, Pharlap ETS, VxWorks, NI Realtime Linux) and NI does provide usually backwards compatibility for the last 3 LabVIEW versions and you see quickly that adding even one more version to this is definitely going to have a huge extra impact in testing. And everytime there is an incompatibility on any of those combinations someone has to go in and make a fix and then testing again all around. If you don't limit the scope there somehow you end up testing, fixing and testing again for unlimited amount of times and no product is released anymore. I have tried such installations in the past but not for production type development. It was mostly to be able to look at older source code without having to load it into a newer LabVIEW version. Never really executed anything substantial on real hardware. The recommendation about using Virtual Machines is actually the most sensible in this case, aside from having dedicated hardware for each version.

Does anyone know who maintains the labviewwiki.org site and if the service is temporarly down or should be considered discontinued?

They work fine if you use them without authentication or from LabVIEW to LabVIEW. Otherwise you run into trouble since NI has so far refused to document their NIAuth mechanisme used in them!

Just a short heads up. There is going to be a new release of Lua for LabVIEW 2.0 in the next few days. The initial release will be for LabVIEW for Windows 32 Bit and 64 Bit only. Linux, MacOS X and NI realtime target support will follow begin of next year. Currently I'm testing the software and cleaning up the documentation for it. Keep an eye on http://www.luaforlabview.com for more news about this.

.Net is in some ways better than ActiveX in the areas Shaun mentions. ActiveX is an extension of OLE and COM which have their roots in old Windows 3.x times. Back then preemptive multitasking was something reserved for high end unix workstations and PCs had to live with cooperative multitasking. So many things in Windows 3.1 and OLE and COM assumed single threading environment or at best what Microsoft called apartment threading. This last one means that an application can have multiple threads but any particular object coming from an apartment threading component always has to be invoked from the same thread. LabVIEW having started on Mac and then ported to Windows 3.1 heavily inherited those single threading issues from both OSes. It was "solved" by having a so called root loop in LabVIEW that dispatched all OS interactions such as mouse, keyboard and OS events to whatever component in LabVIEW needed them. When LabVIEW got real multithreading support in LabVIEW 5 this root loop was maintained and located in the main thread that the OS starts up when launching LabVIEW. It is also the thread in which all GUI operations are executed. Most ActiveX components never supported anything more than apartment threading as that kept development of the component more simple. LabVIEW does honor that by executing the methods and property calls for those ActiveX components from the main thread (called usually UI Thread). That can have certain implications. Out of context or remote ActiveX components are thunked by Windows through the OLE RPC layer and the according message dispatch for this OLE thunking is executed in the Windows message dispatch routine that is called by LabVIEW in its root loop. Any even slight error in the Windows OLE thunking, ActiveX component or the LabVIEW root loop in how to handle the various events properly can lead to a complete lockup of the message dispatch and with that the root loop of LabVIEW and absolutely nothing works anymore. Theoretically other threads in LabVIEW can continue to run and actually do, but without keyboard, mouse and GUI interaction an application is considered pretty dead by most users. .Net is less suspicable to such problems but not entirely free as it still inherits various technologies from COM and OLE deep down in its belly. My personal issue with both is that they involve a very complex infrastructure in addition to the LabVIEW runtime that is: 1) has to be loaded on application startup delaying the startup even more 2) while very easy to use when it works, almost impossible to understand when things go wrong 3) being a Microsoft technology has a big chance of being obsoleted or discontinued when Microsoft tries to embrace the next hype that hits the road (DDE while still present is dead, OLE/COM superseded by ActiveX, and ActiveX is highly discouraged in favor of .Net now, Silverlight has been axed already) Betting on those technologies has had a very good chance of being siderailed so far, as NI had to find out several times including with Silverlight the last time.

That's right. Before LabVIEW 5, Booleans were 16 bit integers and Boolean arrays were packed into 16 bit integers too. That had however several performance penalties in several places and was anything but standard to anything else except some MacOS precedences, so was dropped in favor of a more standard implementation with bytes for each boolean. Reality is that there is no such thing as a perfect implementation for every possible use case. Your packed array solution you assumed LabVIEW to use, had severe performance limitations in LabVIEW 3 and was therefore dropped in favor of a more common way that did consume more memory when boolean arrays were involved but made conversion between boolean arrays and other formats simpler and generally more performant. But there is a simple rule: If you are concerned about this kind of performance optimization then don't use boolean arrays at all! They involve memory manager operations all over the place and those are magnitudes slower than a few hundred CPU cycles with which you can do just about any boolean operation you might ever dream up. For such performance optimization you need to look at properly sized integers and do boolean arithmetic on them. And if your "boolean array" gets over 64 bits you should definitely look at your algorithme. Most likely you have chosen the easy path of working with boolean arrays in order to not have to think about proper algorithme implementation but if you go that path, worrying about sub microseconds optimizations is definitely a lost battle already. One of the worst performance killers with the packed boolean array implementation in LabVIEW 3 was autoindexing. Suddenly a lot of register shifts and boolean masking had to be done on every autoindex terminal for a boolean array. That made such loops magnitudes slower than a simple adress increment when using byte arrays for boolean arrays.

srvany is not the same as sc.exe or srvinstw.exe. The first is a sort wrapper that allows to wrap a standard executable in a way that it will run as a service and at least properly respond to service control requests (although things like stopping the service really will more or less simply kill the process so it isn't a very neat solution, but it works for many simple things. sc.exe is THE standard Windows command line tool to the service control manager almost for as long as Windows services exist. The interface to the service control manager is really located in advapi32.dll and can be also directly called from applications (but many functions will require elevated rights to work successfully). Not sure about Srvinstw.exe but the standard way of interacting with the service control manager through a GUI is through the MMC snapin for services which you can reach through the Control Panels->Administrative Tools. While srvany works reasonably well for simple tasks, for more complicated services it is really better to go through the trouble of integrating a real interface to the service control manager in an application meant to be executed as a service.

I second everything Matt said here.

Not really removed LabVIEW 2013 is the first to officially support any of the Linux RT targets. So it was simply never added.

Yeah after rereading it a few more times I got the feeling that something like that had happened. I think it's not worth the effort. Things are pretty clear now and editing posts substantially after the fact is something that is generally not considered helpful nor correct. We all write sometimes things that turn out later to be badly written. For myself I usually limit editing for posts to fixing typos and adding an occasional extra information that seems useful.

If you look at the link from Fab, you can see that you should probably use LocalAppDataFolder instead if you want the non-roaming version of it.