Rolf Kalbermatter

Except going directly the network path? Not really! There might be some obscure registry setting which influences the timeout, but in my experience the default timeouts for accessing remote file paths through Windows file API are rather to long than to small. I don't like to wait for 1 minute to finally get an error that a file path is not currently accessible since the network or remote server is down. Identifying that registry setting is going to be difficult and made extra complicated as it may vary depending on your current setup and logged in credentials. That file API is layered on top of the kernel API which is layered on top of the NetBEUI protocol, which then makes use of Winsock, which then calls into the socket driver and from there in the network card driver. NetBEUI is/was a nice invention back in the days of DOS and got carried over since, but it did not have a rich control interface for things like timeouts, etc. It simply goes and sits for whatever time the developer found reasonable. The Windows file API does only support timeouts on its own level through asynchronous API calls, which is cumbersome and in most cases serves no extra purpose other than freeing up the current thread to do something else while the file API waits for the underlaying resource to become available. LabVIEW does not use the asynchronous file API since it doesn't give LabVIEW anything extra and even if it did, this is entirly seperate from possible timeouts in lower level file system drivers like NetBEUI. Generally I would say your Windows domain setup is somewhat flaky, so that the NetBEUI driver can't always verify the access rights of the current user for the desired network resource in time. This setup used to be fairly straightforward in Win NT 4 times but got tightened up a lot since, so that it is very easy to make errors when configuring domain users and access rights, and this errors often only occur occasionally, depending on network load, actual login mode and various other temporary conditions.

I believe that it should be possible to do, but likely will require to crosscompile the entire NI Linux RT kernel sources in order to configure them for a standard PC rather than the NI specific hardware. Other than that it should be less critical about needing specific hardware (virtualization) than the Pharlap system, since the Linux kernel was and still largely is originally developed on and for the PC. It's been more than 15 years that I compiled my own Linux kernels from scratch and installed them onto a second boot partition so it will be taking some time for sure to figure out all the details. If I ever happen to get some spare time, I'm probably going to try that, but don't hold your breath for it.

What about the LVCompare.exe tool that can be used to automate source code control clients to know how to deal with LabVIEW files more friendly? http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/configlvcomp_thirdparty/ That should do most of the things required here and has various options to ignore certain classes of changes in the comparison.

It's a first step towards 3.0 compatibility but by far not enough. 3.0 changed a lot of things. As to running LabPython 4.0 with Python 2.7 I guess that thanks to the runtime dynamic linking, it may work fine as long as you don't hit code paths that depend on the symbols that changed in 2.7. And that is in fact something that makes me wonder if the dynamic linking is a good idea . Different Visual Studio versions might certainly have some influence. I'm not sure anymore if there are any resources that are shared across the Python-LabPython boundary but that would be totally problematic for sure if the Visual Studio and therefore the C runtime library versions differ.

Native Excel files are using a proprietary format, either binary (pre Office 2012 or so) or compressed XML. Both formats are not something that is easily read in LabVIEW although there is a Toolkit which can read and write XLS files directly. Another approach is to use ActiveX to interface to Excel and access the files like that. There are several libraries out there which wrap the ActiveX nodes to make it easier, since the ActiveX object hierarchy of MS Offce software is rather involved and not trivial to understand. But in order for this to work you need to have Excel installed on the computer you use such a library. For the rest it really would help to give more info as was asked multiple times in this thread already. It's rather frustrating to see multiple requests for extra info and then seeing that you keep providing further information in piece meal fashion and if you keep doing that the readyness to help you further will quickly diminish also for future requests you may have. If the files are however in tab or comma separated text format then the Read Spreadsheet file function will work perfectly.

You should probably not attempt to set the absolute path to the Python27.dll when it was installed in System32 (or more likely SysWow64 as in my case when installing the Python 2.7.11 version from Python.org). In that case just specifying Python27.dll alone should be safer. Also note that the LabPython 4.0.something package that gets installed from VIPM is not compatible with Python 2.7. They changed various things in 2.7 in preparation for 3.x including removing some symbols from the DLL and then the LabPython initialization fails because it can't link to the expected symbols. I have prepared some fixes to the current LabPython code that conditionally links at initialization time to the correct symbols but haven't found time to properly build a new VIPM package for this.

The problem is that when Python is started it determines its home path from a number of possible values and then determines the sys.path value from that. This is then used to find modules that you "import" in a script. It does among other things check values like the PYTHONPATH and PYTHONHOME environment variable, registry entries and finally if that all doesn't lead anywhere the current executables directory. From there it tries to find the Lib directory inside the determined home path. However I just installed Python 2.7.11 from the Python site on my machine and I don't see any environment variable nor registry entry for Python. That forces the Python DLL to rely on two remaining parameters, all of which don't help either. First the location of the Python DLL which has been moved from the Python directory to the Windows system directory in the past, so no way for Python to find out where it got installed, and then as last resort the executable directory, which is the LabVIEW installation directory; no joy to find the Python lib directory from there either. For the Python executable this last one is which saves the butt when running from within the Python console, but leaves any application that embeds the Python DLL in the cold. Possible Workarounds: 1) append the relevant Lib path to the sys.path variable before your import statement (something like sys.path.append("C:\Python27\Lib") 2) Define PYTHONPATH=C:\Python27\Lib;<other possible module directories> or PYTHONHOME=C:\Python27 environment variable 3) Create a registry key HKLM\Software\Python\PythonCore\<version>\PythonPath\<name>" with the value of the Lib path 4) NOT RECOMMENDED: the default sys.path Python uses when everything else fails is a list of relative paths which would resolve to the so called Current Working Directory. This can be set with a call to the SetCurrentDirectory() Win32 API. Setting this to the Python Home path would theoretically work, except that this path is also modified by various other Windows functions, most noticably the File Dialog box, so using it as a runtime reference is a very brittle solutions. Seems like there is actually infrastructure in the Python DLL to work with that, but that the standard installer forgets to set any of the possible values to help this infrastructure to do its work. There is no good way to remedy that from within LabPython itself since it shouldn't inherently know about Python installation specific details.

As you can see in the discussion thread for this download, the author didn't get to implement the ooCalc much and seems not to have found time to work on that further.

AFAIK VIPM pulls the actual packages from the sourceforge servers (and the NI Tools Network server). So besides moving all the content to another site you would either have to leave the build packages on sourceforge or find a way to easily let VIPM reference this new server instead. Am not even sure how binary packages on github work and if they are easily referenced by external package managers like VIPM. I think there doesn't exist a authoritative list like that. It would be possible to create a fairly accurate list with some effort albeit there is no warranty that it would be complete, but so far people only have asked for this. Nobody ever went to the effort to actually start to create something like this. Even if you had that list several people on it have moved on and are not actively involved in LabVIEW work anymore and may not even follow this microuniverse anymore.

Actually there is one point which comes to mind. VIPM including the latest version does pull all the OpenG libraries from Sourceforge. Moving that to another server would render all existing VIPM installations non functional for downloading OpenG libraries. I'm sure there is a way to change a configuration file or something in VIPM that could let it use another server and the Pro version supports arbitrary server locations but that may all have its own trouble and complications.

The merging capability isn't exactly working well, definitely not something to use in automated merging during GIT pull requests. As to that the development of LabVIEW seems to have stagnated I can't deny that. There have been two quite large architectural changes in the last 7 to 8 years. One is the support for 64 bit targets which got substantiated in version 2009 and finished with the 64 bit versions for Linux and Mac in version 2014. Especially the Mac version must have been a major work as more or less everything had to be changed from the Carbon framework to the Cocoa framework. That is a major change in the code base, most likely with the addition of Objective C code specifically for this move (many Cocoa APIs are not really accessible from C or C++ code). The other big change was the introduction of the LLVM compiler backend around 2011. As it is something that works in the background, not much should have been felt from it for the end user. Technologically however it is a major change to the code base. The fact that it has been so largely invisible to the users is in fact a big achievement, as it has huge chances to break lots of things in many places. So it's not like there hasn't been much development going on in LabVIEW, but a lot of the last big changes are almost invisible to the end user. There has been for several years a lot of work going on to modernize LabVIEW. Quite some of it was in the underlying infrastructure such as multiplatform support (not just multi-CPU and -OS as originally developed), LLVM compiler backend and many more things. The UI side of LabVIEW is however burdened with lots of legacy liabilities that can't easily be changed without breaking lots of things and user expectations. Keep an eye out for new developments there. It won't be as invisible as the other changes mentioned and not everybody is going to like them . Breaking old habits is one of the most difficult things to do.

I'm not sure that is desirable! Bigger companies have failed very badly to provide a working source code control system (anyone ever tried to use Visual Source Safe?), so I don't have high hopes that an SCC offering from NI would be better than what we can get now with openly availabe Open Source tools. That smoother and more effective merge tools for LabVIEW would be a good thing is unquestionable. But the task of comparing vectors and directed graphs with each other is a magnitude or two more complex than simple text code comparison and to automate that would seem a really complicated task that whole generations of computer science programmers could spend years on. Given the closed source nature of LabVIEW that is however not going to happen.

Shaun wasn't talking about zipping up code for source code control purposes. Just that the additional benefits of GIT compared to SVN, which is currently used for OpenG, basically diminish to nothing, since merging is a highly manual process. Seeing so many GIT clones abandoned quickly on "normal" languages, where automatic merging is at least a possibility albeit even there never without thorough manual review of any merge, the collaborative advantages of GIT simply get lost when it comes to LabVIEW code. SVN works for that just as good if not better thanks to very intuitive and easy to use clients like TortoiseSVN. Yes there is a TortoiseGIT client too, and I tried it but it does show regularly the unix origins even when using it as Windows shell extension. Not the type of seamless integration that makes these things easy to use for people who want to program rather than read manuals. Sourceforge having issues is undeniable and that might be indeed a reason to consider to change the provider for the source code control repository for OpenG, but GIT has definitely not any serious advantage in comparison to using SVN when it comes to LabVIEW code. Also I really doubt there will be suddenly any inrush of new people reviving the OpenG initiative because of such a change. LabVIEW is a nish product, used mostly in industry applications, and most users have paid jobs that makes collaborating on OpenG like initiatives kind of hard. And the others have moved on to Python and the like since. The popularity of LabVIEW won't change because of moving OpenG to things like Github. The popularity of LabVIEW is at the point of what it is, because of decisions made by NI about how to market this language. They are or have been fairly agressive about getting it into educational institutions to get future engineers acquainted with it before they move into the industry, but they were and are very reluctant to loosen the control on LabVIEW in any way. As such it has been and still is a proprietary and a single source application development program, rather than a general purpose programming language, despite the fact that it is technically a fully functional programming language. From a commercial point of view history has shown that their decision was in fact a very successful and profitable one. For the academical purpose of graphical programming languages it was less favorable, but you can't fault a stock market traded company for choosing the profitable approach.

Well I see a GZipStream in there, but not knowing the actual language you use it is hard to judge what specifics that may imply. Are you sure you did proper preparation of the byte stream, namely first removing the "Zipped:" string from the stream and then doing the correct Base64 decoding before trying to pass the resulting byte stream to the GZIP function?

Well I'm sure the GIT system was exactly developed for what you see as original idea. And it works amazingly well for certain projects with a central maintenance like the Linux kernel or the Wine project. However lacking such centralized maintenance it tends to get the cloning mess you allude to. Because most developers are just wanting to get this new awesome feature into the software and not worry about integrating it in the main branch. I still follow the Wine project a bit and it is the single most problem there, some contributor has a great new idea and drops a patch, but then when faced with the trouble of integrating it into the whole and complying with common styles, formatting and following proper error handling and making sure the modified code passes all unit test, the majority just starts to complain about the stringent rules and eventually abandons it. Even in text programming, merging a software branch back into the trunk is often a very tedious, and work intense process, that even advanced code merging algorithms never will be able to fully automate, since it is not always enough to just look at the factual differences in code, but the whole context often has an influence too. And with even basic automatic LabVIEW code merging being still a pipe dream, this makes the distributed development model of GIT more of a liability to LabVIEW source code control rather than an advantage.

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.