Leaderboard

Hey LAVAmaniacs! It's been a while since I poked at the LAVA server. There seems to be a lot cobwebs and dust in the server room. The LAVA software hasn't been updated in a couple years. That's way too long. I'm going to jump in and see what I can do about upgrading the LAVA back-end to the latest and greatest. This will fix many issues. Last time I tried this, it failed and I had to revert back. I didn't plan on it failing and didn't allocate time for getting tech support from Invision. This time I'm planning for the upgrade to fail and then getting Invision support involved. This means the site might be offline for a few days beyond the weekend. Sorry, but it's a small pain we have to go through for long-term stability and security. Don't worry though. This time I have a crack team to help me out:

Automatic error handling is for noobs.

Well, the idea behind the original LabVIEW Wiki was to create a Wikipedia for LabVIEW. So linking to external content was welcome, using similar rules as Wikipedia uses. Mainly as cross-reference material or at the bottom of a page where further research could be done. Having said that. A page with all the LabVIEW blogs (which we had before) would definitely be ok. However, creating a dedicated sales page, for example, for your new Modbus toolkit would be forbidden. But a page dedicated to how Modbus works and used in LabVIEW is fine. Where then you could create a section on that page linking to all the Modbus toolkits and code available. There's a fine line that needs to be walked. The Wiki needs too have a definite purpose. It's ok if that purpose changes. But if it's just left wide open, then it will serve no purpose and be just another dumping ground on the web.

The trial gets extended to 45 days if you login with your NI credentials which is free to sign up for. Also there are are VMs with snapshot features. Beyond that a home edition of LabVIEW is pretty cheap but I think that is still stuck on LabVIEW 2014. There were experiments in getting and viewing VIs as a series of PNGs, or flash which meant changing case structures to see other states. If the developer is aware of it, snippets are useful and can mean posting an image, with the VI embedded in it. You wouldn't want to do this on a whole project of course. But in general Shaun is right. Keep your code base in the oldest version of LabVIEW you want to support, and make decisions about upgrading as needed for newer hardware support, or feature sets.

BTW, the ability to connect a NULL reference is intended. This way, you can switch off certain events by modifying the Event Registration Refnum entries with NULL values. I have code where I register for certain events outside of a loop with exclusively NULL references, only to have a different event actually deliver the correct event references to listen to. This way the Event registration refnum is created at initialisation but remains essentially inactive until "primed".

The main reason that I want to support syminks comes from the fact that under Linux when installing shared libraries you normally are creating various symlinks all pointing to the actual shared library in order to have a versioning scheme. Without support for symlinks in the package itself you have to do some involved Münchhausen trick by using post install hooks to create them through the command line, which is also OS and even OS version specific sometimes. Also a shared library on OS X is in fact a whole directory structure with various symlinks pointing to each other for the resource and version information and the actual binary object file. Without support for this you have to zip the shared library package up, add the zip file to the OpenG package and on install unzip it again to the right location. Support for links under Windows was mostly just a fun to have addition to make the symlink functionality work on all LabVIEW platforms but the practical benefit under Windows is fairly limited in terms of support for install packages. And in hindsight the effort to implement it under Windows was pretty heavy. But it does allow to test the library also under Windows without special exceptions.

The comment that the automatic error handling is satisfied if one of the two terminals is connected seems incorrect. Please see the image below. I have tested this both in 2015 and 2017. The errors are the same at this point in time, but I don't think there's any guarantee that that will not change in the future. I plan to always connect both.