Leaderboard

Well, here are a couple: http://lavag.org/topic/16235-organizing-your-projects-on-disk/ http://lavag.org/topic/15271-lvclasses-in-lvlibs-how-to-organize-things/ There are others but these are the most recent and likely have the better content. I guess I haven't collected my thoughts on this in one easy-to-find place. Sorry!

You do know that your managers will probably read this, right? I think consolidation is your key argument in this kind of environment. The premise is that it is cost effective to rationalise/consolodate the myriad of versions into one version for production benfits. As NI don't sell any other versions than the latest, that means upgrading to 2014 at time of writing. Shame eh? First step. Talk to the NI rep and find out how much it will cost to consolidate all the versions and how much discount he can apply (important for the bean counters later). Push him hard as he will want the sale as much as you want to upgrade so he is a great ally here and you can use some of his sales BS when you argue later internally. Get him to give you two quotes. One with the prices for upgrading individually (which is a single seat full licence per person-don't forget all your addons) and the other with his best offer. This is the accountancy "saving" you can show the bean counters later Make sure an SSP is also included as an optional line item. Then onto the convincing Espouse the merits of a single platform and the advantages of having a single version in terms of maintenance, deployment and upgrading test facilities. A powerful argument here for production is downtime. Center the argument around cost saving in terms of product not being produced (rather than programmer effort -you are cheap, product is not ). Point out that whilst upgrades are being tested; they have to be tested for each version (multiplying test station downtime by LV versions). The corollary is that a single platform only needs to be verified and signed off once and can be deployed to multiple stations (Replication of effort across multiple disciplines). Really emphasise the effective cost of sign-off too. That multiple disciplines must be involved so deployment resource is multiplied outside of just a puny software engineer and may involve expensive resources like quality engineers, production and maintenance engineers as well as the great god Project Manager. Basically you argue that everyone (production, quality, management, maintenance, bottom line) will benefit if they upgrade and look what a fantastic offer NI have come up with for a one-time consolidation package (show the two quotes) I think you get the gist. Once you have argued those kinds of points with management and techie types, then you can woo the bean counters with all the free goodies you will get that they would have to buy anyway but you can get for free if they do this "one time consolidation" like "Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit." (thanks for the list Hooovahh ) Show them the quotes as what they have to pay if they do it now or when they have to later. Explain that if they get the SSP too, we will not have to worry about this again next year and we can roll it on ad-infinitum (this is a different budget ) . Any counter arguments, steer towards the SSP. This is your sacrificial "feature" which you may get if you are really smooth, but really not that bothered if you don't. Just make sure you steer all financial arguments towards buying or not buying that to deflect from consideration of the upgrade. I hate politics.

Running applications from source is a bad idea in almost all cases. I highly suggest building EXEs. That being said it is more work to make an EXE. Especially if for some reason the builder craps out and you need to start over again. Locking down an application is critical if you are taking any kind of measurement so you know a developer wasn't fudging the numbers, or adding filtering and averaging to make it pass. I'm lucky enough that my company currently has a renewable license scheme, so I don't have to deal with your specific problem. LabVIEW 2011 is the oldest I currently go back to, but all active programs are developed in 2013 SP1. We generally wait until the SP1 release before using it on any programs. We don't usually upgrade a project to a newer version of LabVIEW, unless we see a need for it. It has added risk associated with upgrading, which is why we have some older programs running 2011. Having all versions you need is important because saving as 2011 in 2014 means you can now only open it in 2014, which could be a problem if all of your developers don't have the appropriate versions. 2011 is basically the oldest I'd want to go back to. 2010 didn't have static VI references, and a bunch of the other application control functions used often today. Here are some of the major benefits I see from going from 2011 to 2014. Conditional auto-indexing, and concatenating loop options. Icon Editor API for code generation. In 2011 there was some kind of API but starting in 2012 it had more exposed. Code complexity metrix using VI server New scripting functions, some with events Bookmark Manager, for keeping track of todo's or other tags in source Improvements in QuickDrop. Especially the auto-wire, which could be done in earlier versions. Clear specific error (OpenG has a function like this) More control over events with the events palette Event structure now has a trace window for debug Events can be lossy Much improved shipped examples Improved versions of the Actor Framework Mouse scroll event And what might be a big selling point, is the fact that the Professional and Full LabVIEW 2014 now includes PID Fuzzy Logic Toolkit, and Professional also includes Database Connectivity, Desktop Execution, Report Generation, Unit Test Framework, and the VI Analyzer Toolkit. EDIT: Oh and lots of FPGA and RT updates

LvVariant is a C++ class. There is a reference count in the variant object, but I wouldn't expect it to come into play here... can't say for certain. When a To Variant primitive executes, LV does "newVariant = new Variant()". Then newVariant.mTD is assigned the data type object -- this is an object with its own fairly complex structure itself. Then the data on the wire is top-swapped into the variant's "newVariant.mData" field (To Variant's input is a stomper so LV has already guaranteed that the data is independent of any other parallel branch and is thus free to be stomped on). There's also an mAttrs field that the attribute table, which is left as null unless/until an attribute is added to the variant. LvVariant does not have any virtual methods so there is no vTable on the C++ object. But the actual data size of the LvVariant class is (1 + sz + sz + 4 + 4 + sz) bytes, where sz is 8 or 16 depending on how many bytes a pointer has on your system. The data is in the first of those pointers. The reference count is the first of the 4 bytes. There's also a transaction count -- the second 4 byte number -- which is unused within Labview.exe and is exported apparently for use with flex data -- you can basically ignore that. You'll never be able to change out the type descriptor -- that's the final sz in the size. Those are refcounted C++ objects that you have to go through the constructors to instantiate. So you could in theory change out the data within a variant, provided you started with a variant that had the type descriptor you needed already in it. You would need to either top swap (swap, not move) the data into the variant or copy the data in, depending upon whether the source data is stompable. A variant claims right of destruction over the data pointer it contains. Don't know if any of that helps you.