Can I prevent someone from saving a file in a later version

[Michaelbolton]

I am sending out VI's in 2014 to students and want to prevent them from being able to save in later versions. Is this possible can I force them to save in 2014 or before.

[altenbach]

No. Simply include instructions how to save for previous and give score deductions if they don't.

[Bob_Schor · Accepted solution]

As far as I know, the easiest way to prevent them from saving in a later version is to ensure that the later version isn't installed!  If they have two versions, say LabVIEW 2014 and LabVIEW 2015 installed, the rules LabVIEW uses if, for example, you double-click a VI to start LabVIEW, is to use the last-opened version of LabVIEW.  So you could leave LabVIEW installed, but delete the short-cut to the later versions from the Desktop and the Start Menus (being sure to "manually" start the earlier version to get it "recognized".

Note that "Save for Previous Version" can become a little "messy", particularly if tools from vi.lib are included, so even if you could "force" this to be the default, for anything other than a single VI that calls nothing else, this is not an optimal solution.

If you are an instructor and want to be able to open Assignments in the version of LabVIEW with which they were saved, you need to do the following:

• Have all the LabVIEW Versions your students use installed on your PC.
• Guess (or know) the correct Version of LabVIEW to use in opening the VI or Project.  If you guess "too low", you'll get an error saying "Use Version XXX".  If you guess "just right", you can read and save the VI without worry.  If you guess "too high", you can read, but if you save, you'll "promote" the Version, which you don't want to do.  To guard against this, open the VI's Properties, look on the General tab, and note the Version Number.  If you are too high, close the VI without saving, open the proper LabVIEW Version, and then open the VI. 

Bob Schor

[altenbach]

What is the reason for "sending out" the vis? Are they supposed to edit them or just run?

[Michaelbolton]

So a little back story I am teaching a class of around 300 students introduction to labview and have made assignments so they can be graded automatically using "open VI refrence" and "call by Vi reference". What I have run into is that if they change the slightest thing such as they assign a control to be I64 instead of I32 or they name something "Input" instead of "input" then my program says "Vi reference type does not match VI connector pane". So what I'm thinking of changing the assignment to is I set up the inputs and outputs and they do the internal wiring to try to prevent these mistakes. A lot of the students download the latest trial version of labview and we only have 2014 here so I am not able to open their assignment. The students are saving multiple times and will sometimes forget to save for previous version. I want to eliminate this as a factor which is why I wanted to force version control.

[Hooovahh]

Yeah that does kinda suck for multiple reasons.  I don't think you'll find a solution other than to ensure you have the latest version of LabVIEW installed, so you can open everything the student might hand in.  If you give them the template in 2014, and they are expected to edit it, then the act of editing it and saving it in 2015 will mean it gets saved in 2015.

[johnsold]

When I am responding to a Forum post where someone has posted in an earlier version and I plan to modify their VI, the first thing I do is place a free label on the block diagram with the version of the original document. That serves as a reminder to me to Save for Previous...

My suggestion for your situation is to do three things:

1. Explain to the students that different versions of LV are not fully compatible, that you are supplying the frameworks for their VIs in a particular version, and that only submissions in that version will be graded.

2. Place labels in a consistent position (such as upper left corner) on the front panel, the block diagram, and in the context help which restates the information in 1.

3. Warn them that the scoring is based, at least partly, on automated software analysis of their submissions. Be explicit about the kinds of things they should avoid changing.

And, of course, 4. Follow up. Enforce your policies.

Lynn

[pangvady]

Another idea is to set your VI to "Run when opened" using the "Execution" VI property:

You can then check the LabVIEW version in your VI to either pop up a message or close the VI if an unintended version is used.

[Bob_Schor]

Michael,     When I give my "Introduction to LabVIEW" lecture to students, one thing I try to impress on them is LabVIEW's "interesting take" on Versions.  We do try to install the current Version on the Lab PCs before the start of the fall semester (except this year, when NI took two months to get the Academic Kit to us, grrrrr), and as the "instructor", I try to make sure that I can, at least, "read everything" by having, myself, the current release on my PC.

So here is something to consider for yourself.  If you are doing most of your development in 2014 and don't want the hassle of upgrading your own code (which, if you are developing it as part of a team, e.g. with your students, means everyone has to upgrade), then you need to have a 2014 system "for work" and a 2016 system "for Teaching".  Here are three ways to do this "semi-safely":

1. Use a different PC.  PC's are relatively inexpensive, so you should be able to talk your chairman into springing for a $1000 desktop system that lives in your office and is your "Course Development" PC.  Put LabVIEW 2016 on it, and next year, upgrade to 2017 before the fall semester.  Advantage -- can't make a "Version" mistake, supports NI hardware, conceptually simple to create and manage.  Disadvantage -- one-time cost and "space" considerations.
2. Use a VM.  I do this using VMWare Workstation, but mainly to allow me to have "old" systems available (I've got some LabVIEW 7.0 code I occasionally need to visit) and to experiment with new stuff (like LabVIEW Beta code).  I might also create a VM if I'm doing a project with someone who has, say, LabVIEW 2011 and can't easily upgrade, as it prevents me from making a mistake and creating a massive "code incompatibility" issue.  Advantage -- relatively inexpensive, takes up "less room" (as it uses your existing hardware), reasonably efficient and simple to use.  Disadvantage -- need to deal with VMs, including creating new ones, handling software installation, etc.  [One way I handle this is to have a VM all ready-to-go, but missing LabVIEW -- I clone it and then add LabVIEW to the clone].  You will not have quite the same "hardware" access, but things that plug into Ethernet or USB should still be available to the VM.
3. Go dual-installation.  You can install LabVIEW 2016 "on top of" your existing LabVIEW 2014.  Now the responsibility of making sure you use the right version to open your code becomes your responsibility, particularly in light of LabVIEW's "The Last Version I Used Is the New Default Version" rule.  Advantage -- simplest, cheapest solution (until something goes wrong and you need to do a re-install).  Disadvantage -- you can mess up your LabVIEW code by saving 2014 code from LabVIEW 2016.  Be sure you are using Version Control if you go this route, as you will screw up at least once a dozen times.

Bob Schor

P.S. -- I've used all three methods, but mostly 2 and 3.