SCC, subVIs, and multiple calling VIs

torekp · October 2, 2007

Sometimes you just haven't left yourself enough extra connectors on the connector pane and you need to change your subVI's connector pattern. Or you find a strange behavior in a subVI (how it handles negative numbers, maybe) and you want to change it but can't remember how your other projects used this subVI. Maybe they needed negative numbers to be handled in that strange way. However we get there, I think most of us have had the experience of changing a subVI for the sake of one caller, only to break another calling VI in a different project. I know I have.

Can any Source Code Control provide a security check against this? That is, can it notify me when I try to check my subVI back in, "this may affect ProjectX.vi and ProjectY.vi", or some such? I haven't selected an SCC provider yet, but I was looking at Microsoft Visual Source Safe and didn't see it.

gmart · October 2, 2007

QUOTE(torekp @ Oct 1 2007, 06:49 AM)

Sometimes you just haven't left yourself enough extra connectors on the connector pane and you need to change your subVI's connector pattern. Or you find a strange behavior in a subVI (how it handles negative numbers, maybe) and you want to change it but can't remember how your other projects used this subVI. Maybe they needed negative numbers to be handled in that strange way. However we get there, I think most of us have had the experience of changing a subVI for the sake of one caller, only to break another calling VI in a different project. I know I have.
Can any Source Code Control provide a security check against this? That is, can it notify me when I try to check my subVI back in, "this may affect ProjectX.vi and ProjectY.vi", or some such? I haven't selected an SCC provider yet, but I was looking at Microsoft Visual Source Safe and didn't see it.

If you use the SCC integration in LabVIEW, there is a mechanism provided that may help. There is an option (which is on by default) that if the callers of your subVIs are in memory, when you edit or check out a VI, you will be prompted to check out your callers. So this check isn't on the check in side of your workflow, but should at least get all the callers checked out in the case you change a connector pane or something along those lines.

dannyt · October 2, 2007

QUOTE(torekp @ Oct 1 2007, 12:49 PM)

Can any Source Code Control provide a security check against this? That is, can it notify me when I try to check my subVI back in, "this may affect ProjectX.vi and ProjectY.vi", or some such? I haven't selected an SCC provider yet, but I was looking at Microsoft Visual Source Safe and didn't see it.

There is no way the SCC tools can know about the inter-relationship between your VI's and projects. but if you are happy to to document this, there are several way this type of thing could be done in ClearCase (I would suspect CVS and sub-version would support similar types of actions) but it does take a bit of work to set it up.

In ClearCase you can set-up triggers to fire on nearly every action ie checkin, checkout and many more. Not only that, but the triggers can fire in two modes for most actions, either as a pre-trigger or as a post trigger, typically pre-triggers can be setup with a pass / fail type result and be used to stop and action from happening.

The triggers are usually written as Perl scripts and thier can be written to do almost what you want.

So for example you could create a post-checkin trigger on all files of type *.vi files within your ClearCase system (attaching the trigger to all the files type is very easy and quick), this script file could then parse your VI relationship xml or text file and pop up a message telling you what else is affected. Obvioulsy you would need to remember to keep you inter-releationship documentation up to date.

Things that I have seen be done with triggers

and much more

There are also Clearcase objects called Hyperlinks that can be used to show inter-relationships between files (see below) and these can be acted upto by triggers as well.

Some useful or othewise definitions are at the bottom of the page.

hope this is of some use

Danny

ClearCase Triggers

A ClearCase Trigger is a an executable program that you create that you can make Clearcase invoke before and/or after a specified ClearCase event or operation. You tell ClearCase which commands/events to invoke it for, you tell it how to invoke it, and ClearCase will execute it at the specified time with the specified parameters, as well as set the environment with lots of ClearCase related environment variables to allow your trigger "script" to consult numerous items of contextual information at the time it is invoked.

ClearCase Hyperlink Types

Hyperlinks are the stangest of the Object types. Using Hyperlinks, you can link one version of an element to another. Not only that, but you can use hyperlinks to point from almost any object type to another. ClearCase uses Hyperlinks to track Globally defined types. First of all, to even use Global definitions of Object Types, you create a hyperlink AdminVOB from one VOB to the Administration VOB where the Global definitions live. Then when you actually invoke a Global definition, ClearCase links the Globally defined Object Type to the locally defined object type with the GlobalDefinition Hyperlink. A pretty neat trick. The classic use of Hyperlinks is to point from one version of an element to the supporting documentation. If someone checks out a library definition, then the trigger could also force a checkout of the corresponding documentation, and refuse to check in the library definition until the corresponding documentation has been updated.

Grampa_of_Oliva_n_Eden · October 2, 2007

Quick idea;

A tree VI (a container VI that contains all top level and dynamic VI's) can serve as a quick check of all of it sub's.

I generally have one VI for each project.

I will work with the "tree open and if i break it, it gives me a quick indication that something is wrong.

Ben

dannyt · October 2, 2007

QUOTE(Ben @ Oct 1 2007, 02:54 PM)

Quick idea;
A tree VI (a container VI that contains all top level and dynamic VI's) can serve as a quick check of all of it sub's.

I generally have one VI for each project.

I will work with the "tree open and if i break it, it gives me a quick indication that something is wrong.

Ben

A significantly easier and more LabVIEW centric suggestion than mine Ben, I like it.

Danny

Michael Aivaliotis · October 2, 2007

QUOTE(Ben @ Oct 1 2007, 06:54 AM)

Quick idea;
A tree VI (a container VI that contains all top level and dynamic VI's) can serve as a quick check of all of it sub's.

I generally have one VI for each project.

I will work with the "tree open and if i break it, it gives me a quick indication that something is wrong.

Ben

In order to resolve the original posters problem (and to be 100% sure), you would have to open every single tree of every project your company produced in their lifetime. Not very practical.

It seems like there should be a way to get notified, and the ClearCase triggers seem to be it, however is sounds complicated and requires a lot of setup.

Grampa_of_Oliva_n_Eden · October 2, 2007

QUOTE(Michael_Aivaliotis @ Oct 1 2007, 11:31 AM)

In order to resolve the original posters problem (and to be 100% sure), you would have to open every single tree of every project your company produced in their lifetime. Not very practical.
It seems like there should be a way to get notified, and the ClearCase triggers seem to be it, however is sounds complicated and requires a lot of setup.

Yep! :headbang:

So if you have many projects and you want to share amoung all of them while keeping them running....

Then a "Quick Check" VI can be developed an used to open (via VI server) a list of Tree.VI's and check if they are broken.

An over-night batch job can run a report of VI's that broke the previous day.

Or even better, include a "tester" VI (a VI that runs sub-VI's and compares results to known good. Returns a single boolean T if OK) for each set of VI's. This will not only tell you if the VI's broke but would also tell you if the functionality changed.

Combine that with SCC and you should have most of your bases covered.

Ben

dannyt · October 2, 2007

QUOTE(Michael_Aivaliotis @ Oct 1 2007, 04:31 PM)

In order to resolve the original posters problem (and to be 100% sure), you would have to open every single tree of every project your company produced in their lifetime. Not very practical.
It seems like there should be a way to get notified, and the ClearCase triggers seem to be it, however is sounds complicated and requires a lot of setup.

Actually it might not be to bad, the create trigger part is easy as is associating it triggers to files, it is the script that is hard'ish.

Looking at the LabVIEW project files *.lvproj they are already in an xml format and contain in a readable for the vi names, with thier paths for example

I am new to 8.2.1 and using projects, can you add projects to projects I assume you can. So with one single top level, you could easily search through looking for all reference to the current VI you are editing.

If you cannot have projects within projects, a single text file point to all you projects and the location of thier project file (lvproj) would do. In fact you could forget you SCC system and just have a labVIEW application that told you for any VI all the projects it is used in within you orginasiation. I almost feel sure somebody has aleardy done this somewhere in the LAVA archives. You could even batch run something like this every night, as most older projects will not be changing as much as newer projects.

Danny

Ton Plomp · October 2, 2007

QUOTE(dannyt @ Oct 1 2007, 05:58 PM)

Actually it might not be to bad, the create trigger part is easy as is associating it triggers to files, it is the script that is hard'ish.
Looking at the LabVIEW project files *.lvproj they are already in an xml format and contain in a readable for the vi names, with thier paths for example

<Item Name="circle area.vi" Type="VI" URL="/C/Program Files/National Instruments/LabVIEW 8.2/examples/project/viserver/circle area.vi"/>

You could even batch run something like this every night, as most older projects will not be changing as much as newer projects.

Danny

Well the issue is lvproj don't cover dependencies (which are the case here).

What you need is some form of database.

Every VI call should there be logged, but you will always miss dynamic calls. So the problem is not the owning VI, but the subVI.

If you need to change functionality of a (very often used) subVI, you need to recreate it under another name.

http://wiki.openg.org/Library_VI_Deprecation_Process' target="_blank">OpenG has some policy for this

Ton

Rolf Kalbermatter · October 3, 2007

QUOTE(Michael_Aivaliotis @ Oct 1 2007, 10:31 AM)

In order to resolve the original posters problem (and to be 100% sure), you would have to open every single tree of every project your company produced in their lifetime. Not very practical.
It seems like there should be a way to get notified, and the ClearCase triggers seem to be it, however is sounds complicated and requires a lot of setup.

Personally I have resolved to copy my library VIs into the project directory itself whenever used in a project to avoid the mentioned troubles of changed behaviour between project developments.

And one other thing I usually do for bigger projects is a unit test framework. It will not solve the problem of automatically detecting any dependencies in any project you ever programmed, but for projects where you have a well defined unit test framework in place you can easily run this unit test in every project you are interested in regularly to make sure there have been no regressions. This also helps greatly during development of a project itself where you can tend to make subtle changes to a seemingly unimportant function and suddenly other things fail in an amazing way.

Rolf Kalbermatter

torekp · October 3, 2007

QUOTE(Ben @ Oct 1 2007, 03:42 PM)

Then a "Quick Check" VI can be developed an used to open (via VI server) a list of Tree.VI's and check if they are broken.

Brilliant. I'm doing it. There aren't that many Labview projects in my whole workplace so it won't be too hard to retrofit. The Quick Check could also examine a list of recently changed subVIs and tell you which top level VIs depended on them.

Andy Peters · November 1, 2007

QUOTE(torekp @ Oct 1 2007, 04:49 AM)

Sometimes you just haven't left yourself enough extra connectors on the connector pane and you need to change your subVI's connector pattern. Or you find a strange behavior in a subVI (how it handles negative numbers, maybe) and you want to change it but can't remember how your other projects used this subVI. Maybe they needed negative numbers to be handled in that strange way. However we get there, I think most of us have had the experience of changing a subVI for the sake of one caller, only to break another calling VI in a different project. I know I have.
Can any Source Code Control provide a security check against this? That is, can it notify me when I try to check my subVI back in, "this may affect ProjectX.vi and ProjectY.vi", or some such? I haven't selected an SCC provider yet, but I was looking at Microsoft Visual Source Safe and didn't see it.

I'm perhaps a little late replying, but here's what I think. I use Subversion, so my examples will be typical for svn repositories, but the ideas should be usable with any SCC system. Subversion does not have any way to tell you where a particular file is used.

If you have subVIs that are shared among multiple projects, it makes sense to maintain those subVIs as separate projects. To that end, you should always use a tagged revision of that subVI project. Tags are considered immutable (although in Subversion this is by convention and not enforced), so always using a tag rather than the trunk guarantees that if someone (yourself?) changes the subVI, the version you use in your project will not change.

In Subversion, to include a subVI in your project, you have to attach an svn:externals property, pointing to the subVI URL in the repository, to your project. Then when you do an svn checkout on your project, you get the subVI too, in its own subdirectory under your project directory.

Now, if you need to change that subVI, which is maintained as its own project, here's what you do. First, completely exit LabView! Change the svn:externals property on your main project to use the subVI project's trunk instead of the tag. (Or change it to whatever revision was used to create that tag.) Then do an svn update, which will automagically replace the tagged version of your subVI with whatever's in the trunk. Now reopen the main project in LabView and it should be good. Now you can modify the subVI and your main project VI to fit your needs. When you're done, save everything, then close LabView to ensure all changes are actually saved. Then commit the subVI back to its trunk. Create a new tag for the subVI in its project. Back to your main project, change the svn:externals property to point to the new tag, do an svn update on your project and you'll get the new tag as part of your project. Open the main project in LabView to make sure all's well, then when you're happy, save the project, close LabView, then commit all of the changes for your main project, which includes committing the svn:externals change. Now you're good.

I have a couple of large LabView projects structured this way. One uses seventeen separate subVI projects, all brought in using svn:external , and I've found that this method is the only way of preserving my sanity when re-using subVIs. I should note that this methodology isn't something that's useful only for LabView; I use it with VHDL sources for FPGAs and C sources for microcontrollers, too.

One more thing: consider setting the svn:needs-lock property for all VIs. In each users's home directory you'll find a subdirectory called .subversion (or perhaps it's in C:\Documents and Settings\username\Application Data\Subversion, G-d I hate Windows), and in there will be a file called config. In that file is a section called [auto-props]. In that section, add the following lines:

*.ctl = svn:needs-lock=*

*.vi = svn:needs-lock=*

Then when you initially svn import a project or svn add a new VI or control, the needs-lock propery will be set. When you check out a file with this property, it will be read-only, so to modify it you need to get a lock from the repository (simple svn lock Foo.vi ). You can then modify it. Nobody else can modify the file while you have it locked. This is a Good Thing because LabView VIs are binary and merging is basically impossible. Once you make your changes, commit the file and unlock it so if others need to modify it, they can do so.

Good luck,

-a

PS: if you're using Subversion on Windows, you really need http://tortoisesvn.tigris.org/' target="_blank">TortoiseSVN. Really.