LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Version control for excel test definition files

Hello everyone, looking for your wisdom, it may be a crazy idea, but rather ask. We are working on a common test interface using labview, the application will be used with a plethora of different products, each product will require a "test definition file" made in excel that will describe each test to be performed on the product and its parameters and specifications. We are looking into rev control the VIs/Project with SVN or something similar, but it came to our idea if the excel "test definition file" can be also controlled through SVN, which it may be possible, but the question is if the file (test definition file) that is inside the SVN will be accessible from the labview interface (the interface only needs read access to the file to load it once during execution of test). We would like to avoid the option to control it through the SVN and then copying it on other location so it can be accessible to the labview interface.

 

There will be different test stations running the labview interface, each station running different PNs, reading the "test definition file" from a server (in this case, the SVN server).

 

There is also a similar situation for the update service, the idea is that the labview interface will have an automatic update service, so we also wonder if it can read the rev status of the SVN and update it from the same SVN server copying the VIs that will require update.

 

The idea is to have everything version controlled with one tool and avoid lag or missing updates of different sites.

 

It may be too much for the same post, if needed we may break it down. Open to suggestions.

 

Thanks in advance!

 

 

0 Kudos
Message 1 of 4
(744 Views)

Why not save the Test Definition File (which seems to be somewhat "Version-specific" right with the VIs?  I'm going to assume that you will eventually build an Executable so that you don't need to run this code from "within" LabVIEW.  I also assume that you are using LabVIEW Project to organize your (little-p) "project".

 

Here's a suggestion if the above assumptions are true:

  1. Create a folder called "Data" inside the top-level Folder that contains the rest of the Project.  Put the Test Definition File in here, and (automatically) save the latest version when you Commit your Project to SVN.
  2. While running in Development Mode (i.e. while testing from within LabVIEW), you can find the Top-Level Folder that holds the Project (a variety of techniques, including finding the folder holding the Top-Level VI, and locating the Data folder with relationship to this Top-Level VI's folder).  The Data folder holding the Test Definition File is one level down.
  3. If you are running in Execution Mode, the default location for the Data Folder (specified in the Build Spec) is similarly one folder down from the Folder holding the .EXE file.
  4. Fortunately, for both Execution and Development modes, the Application Folder (which holds the Data Folder) is specified by the "Application Directory" VI in the File I/O Palette under File Constants.

Bob Schor

0 Kudos
Message 2 of 4
(707 Views)

Hello Bob,

 

Thanks a lot for your quick response! Before getting into the suggestions below, which I still don't discard, I have to clarify that the user interface/test definition file is not version specific, I mean, the interface can run any version of the TDF (for short), we will have several machines/stations which indeed as you pointed will run an executable of the interface, each station will be capable of running any PN limited on some instances by the hardware on the station rather by the software.

 

The initial idea of the implementation is to have the TDFs separate from the labview project of the interface so they can be updated individually and away from the labview interface, so if any PN requires a change we don't have to mess with the labview project/interface, we only modify the TDF of that specific PN.

 

Clearly having as you mention the Data folder below the labview project, both can be controlled on the SVN, but as pointed above, we will need to modify the project each time we need to update or add a TDF. And also, such project may have 400-500 TDFs due this interface will be used to test any of those PNs.

 

Some way to see what we want to do is like having the SVN controlling the excel file which will be directly on an windows network path location so it can be accessed through the labview file/dir fuctions to read it. Having the files in a network will allow for up to date access.

 

I have used TortoiseSVN very briefly, and what I see is that it creates a repository in a windows folder but the individual files are not visible inside from the windows explorer (have to use their tool software), it may be one SVN that will control the files even if they are within a windows folder and anyone can have may be read access from the windows explorer.

 

Thanks again, and Best Regards.

0 Kudos
Message 3 of 4
(683 Views)

Thank you for the update on what you are trying to do.

 

I wonder if you are using the "wrong model" for what a Version Control System does, and how it should be used.  Here is a very brief, overly-simplified description.  A VCS is characterized by a Repository, something you don't directly manipulate, but which provides to you the "latest revision" (sometimes called the "Working Copy" when it is on your computer) of something, and also all the previous revisions that you have committed to it.  The notion can be illustrated for Software Development -- instead of My Code, My Code Version 1, My Code Version 1.1, etc. all living on your Hard Drive (sometimes a dozen or more "versions"), you have only the current (Working Copy) version, which you (frequently) re-commit to the Repository, along with a note saying "What's New" so if you need to go back to an older version, you know where to find it.

 

The Repository is almost always stored remotely on a Server (not on your PC).  You (ideally) have only the current "latest version" (or Working Copy) on your PC, and keep the Repository "up to date" by frequent Commits.

 

What you describe sounds to me like a "Global Data Folder" with multiple files (I couldn't follow TDF and PN) that would be needed in different circumstances.  This is more like a DataBase (and some have use LabVIEW to pull in configurations from things like SQLite, beyond my area of expertise).  If you have multiple Configurations that your Program can use, you need to decide how you want the user to be able to select the Configuration they want/need to use, go to the (fixed) location where the Configurations are stored, and pull in the correct one.  You do not (necessarily) want/need Subversion or any VCS for this, as you really aren't interested in the "history" of these Configurations (I'm guessing).

 

When you are storing something that "everyone" needs to access, consider putting it in the Public Documents folder (where anyone logged in can read, but also write, to it) or in the hidden, Read-only ProgramData folder (you would need Admin rights to save files to your Configuration folder there).

 

Bob Schor

0 Kudos
Message 4 of 4
(674 Views)