Leaderboard

Has anyone put effort into defining a roaming environment configuration for LV? I work on several virtual machines, and keeping my LV settings, probes, glyphs, QD extensions, labview.ini tokens, etc. consistent across all of them is a nuisance. I'd like to put all that stuff in Dropbox so it syncs automatically. Are there known drawbacks or existing tools I should know about before I funnel several hours of tinkering into it?

I'll offer my 2c here. As a general solution to the problem, point 1 is simply not going to cut the mustard. As I understand it, part of the problem here is the presentation of the values on the UI and how to handle the different modes of user entered data. Try telling a user to enter data via String/variant and you might as well just quit on the spot. This also pushes a LOT of errors from compile time to run-time which is not good. The option of dependency injection works absolutely fine IF you are using the objects own methods to interface with the stored configuration data. By implementing a simple UI for each (type of) class, you can keep the UI interfaces for user data entry completely seperate from each other with zero JSON, XML or the like in sight (unless that's actually your underlying data of course ). Granted the problem of programatically setting the values of the sub-objects remains but simply pushing the UI work into the objects themselves DOES significantly improve the ability to decouple the various input methods for users at least without creating any new burdens. This is simply the same as hard-coding each and every subclass functionality into your code and has almost zero expandability in the future. As a rule, you should be asking your objects to do things for you instead of telling them what to do. As such, I find the implementation of the UI interface (for this specific example) into the subobjects themselves the most logical, most flexible and safest method. Even the required knowledge of JSON formatting or Variants so that the object of choice will understand it is, for me, not a definition of an interface, it's broken encapsulation. Wiring up a strictly-typed terminal is always better. If and only if it is impossible to get what you want with strict typing then consider going down the dynamic typing road.

I don't know where I fit in the spectrum of average LabVIEW users, but I would not be able to make the same application that I do today in 2013, in 6.1, without many extra weeks put into custom code for UI design, and work arounds and even then it wouldn't work as well. Drag and drop, events, property/invoke nodes that were added, VI server control, subpanels, user events, I mean have you ever tried to make a multicolumn listbox in 6.1 and have it be interactive? Sorting based on column clicking? Because I did once, and gave up when I was doing it with VB code and .Net to make tables. Not every version delivers a home run in terms of features, but many good tools come in 3 years, let alone 12. But I do understand the pain of upgrades, which is why I mentioned we don't upgrade unless we see a need. That being said since 2009 NI has done much better at maintaining version compatibility and feature set. I'd bet a large majority of 2009 projects could be opened in 2014 and work as is. There are probably a few tools that have been deprecated but I don't know what they would be. Also please don't think I'm attacking you. I simply think 6.x is too far. I'd say the majority of my code could be done in 2010 or 2009 without much trouble.

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