Q: Would you use VI tags to 'tag' your code?

[LAVA 1.0 Content]

I have a question.

I am thinking about a policy which allows our company to track which user.lib VI is used where so we can decide for which programs we have to retest upgrades of VI libraries.

I want to be able when building an application to read which VIs are used inside the app. A simple routine is reading all of the children VIs and store this array.

A more sophisticated way is a cross-link database where for every reuse VI is tracked in which applications it is used. I am thinking to give each reuse VI a special tag to have an easy access database field.

Some option are:

• VI description with a special string like ***Internal Reference #### Version 0.9*** (NI has such fields)
  
• A tag on the frontpanel like OpenG has
  
• A tag on the block diagram
  
• A tag using VI tags
  

I am thinking about the latter, the tags are invisible to the user, can be accessed via VI server, the downside is that they are not supported by NI (what do I care, I do more unsupported stuff).

What are your thoughts?

Ton

[Aristos Queue]

Could you instead do something where you read the project build specifications from the .lvproj file to determine what needs retesting?

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Jul 7 2008, 12:06 AM)

Could you instead do something where you read the project build specifications from the .lvproj file to determine what needs retesting?

No,

let me eloborate a little bit more.

Suppose I have written a VI that retrieves the executable version of an application, I store this inside my user.lib.

Now as quality assurance manager (a not-so hypothetical function) I wish to know in which applications I use this VI. This info should be easy retrievable, hence the database. So in my sourcecode I tag my source reuse VI with some part-number. During building of the application I retrieve all these part-numbers do some database code ét voila I can easily look up where I used that VI.

A little bit like http://forums.lavag.org/Getting-Started-Dialog-Window-t11143.html&p=47103#' target="_blank">here:

QUOTE

b) The API for these items had some dispute about it. We may decide that we want to change the implementation of these properties/methods in the future LabVIEW versions. Making these private means we do not have to support any mutation of existing VIs that load in that future version. We keep a list of which of our VIs use those properties/methods, and we don't bother trying to programmatically mutate other VIs on the off chance they use these properties/methods.

Ton

[Jim Kring]

A unique identifier of your reusable VI is its name (including lvlib prefix, if applicable). For example, you can't (or shouldn't) have two different VIs installed in your user.lib folder that have the same name. So, creating an additional tracking ID is redundant.

Also, if you have needs in this area, you might want to mention them to the VIPM team. I hear they have a great system for helping manage reusable VIs and this might be just the type of thing that's on their radar.

[dannyt]

This sort of tracking is why I would really like to easily be able to use locate user.lib on a Network drive and actually place all these VI into our source control system.

Once in the source control system I can do all the tracking I need without tagging.

Danny

[LAVA 1.0 Content]

QUOTE (dannyt @ Jul 7 2008, 10:44 AM)

Once in the source control system I can do all the tracking I need without tagging.

Really?

I have not found a source control code that allows you to trace from which code which VIs are called.

I think user.lib code should be developed somewhere else and should be installed into user.lib, and the source of these VIs should under SCC. During a built I would like to built a list of all the VIs (with identifiers) so I can keep trace.

Ton

[dannyt]

QUOTE (Ton @ Jul 7 2008, 11:55 AM)

Really?

I have not found a source control code that allows you to trace from which code which VIs are called.

I think user.lib code should be developed somewhere else and should be installed into user.lib, and the source of these VIs should under SCC. During a built I would like to built a list of all the VIs (with identifiers) so I can keep trace.

Ton

We use ClearCase as our source control tool and when I do a build (using the OpenG builder) I generate a Build of Material (BOM) which I save a part of the build log

so for all the files under source control I typically log something like.

-------------- ClearCase Build Info (Build Start) -----------------

ClearCase Build View : dannyt-dev-ats-566

ClearCase Config Spec :

element * CHECKEDOUT

element * /main/dev-ats-566/LATEST

element * /main/B388-ATS-2008JUN05 -mkbranch dev-ats-566

element * /main/0 -mkbranch dev-ats-566

----------Target List ----------------------------

test_executive-B388-ATS-2008JUN05-006.exe/n

--------- BOM LIST ---------------------------------

8210a_error_query.vi,N:\testTeam\ATS\Inst_Drivers\weinschel_8210A\8210a_error_query.vi,\main\2

5810_uut.vi,N:\testTeam\ATS\Inst_Drivers\digital_card\5810_uut.vi,\main\dev-ats-566\1

set_enabled_bits.vi,N:\testTeam\ATS\Inst_Drivers\digital_card\set_enabled_bits.vi,\main\dev-ats-566\1

get_ocp_trip.vi,N:\testTeam\ATS\Inst_Drivers\Generic_PSU\get_ocp_trip.vi,\main\9

get_current.vi,N:\testTeam\ATS\Inst_Drivers\Generic_PSU\get_current.vi,\main\10

To understand this, if you not familiar with ClearCase ignore the drive letter (well you expect all the drive letters to be the same or else you have a cross-link problem)

so set_enabled_bits.vi is located in the source control tool \testTeam\ATS\Inst_Drivers\digital_card and it is version 2 on branch dev-ats-566

whereas

8210a_error_query.vi is located in the source control tool \testTeam\ATS\Inst_Drivers\weinschel_8210A and this is version 2 on main.

As the user.lib stuff is not in source control the best I can get is

Current VIs Parents Ref__ogtk.vi,C:\Program Files\National Instruments\LabVIEW 8.2\user.lib\_OpenG.lib\appcontrol\appcontrol.llb\Current VIs Parents Ref__ogtk.vi

so if I could put the user.libs in a network location under source control I would be able to fully track them as about a reproduce any build using my log system

============

small rant.

I can never understand why all the LabVIEW people seem to like the fact that everything is locally install, to me it make good team working and control a nightmare almost impractical at time I feel, certainly from the point of a "quality assurance manager"

I look back to my days doing development on Unix, the development tool set was installed on the server under source control, or deployed out from a source control tool into one location. The developers used the path environment and you could really ensure everyone was developing with the same toolset & libraries be they thirdparty items or internal.

cheers

Danny

[LAVA 1.0 Content]

QUOTE (dannyt @ Jul 7 2008, 06:50 AM)

I can never understand why all the LabVIEW people seem to like the fact that everything is locally install, to me it make good team working and control a nightmare almost impractical at time I feel, certainly from the point of a "quality assurance manager"

In Windows you have the option to place a shortcut to a network folder in the local user.lib directory and have the VI libraries on the network show up in the user function palette.

Not the ideal solution, but a step in the direction.

[dannyt]

QUOTE (LV_FPGA_SE @ Jul 7 2008, 04:19 PM)

In Windows you have the option to place a shortcut to a network folder in the local user.lib directory and have the VI libraries on the network show up in the user function palette.

Not the ideal solution, but a step in the direction.

Cheers LV I will have a play at that, maybe create a fixed ClearCase view mounted on a agreed and common mounted drive.

Danny

[LAVA 1.0 Content]

QUOTE (dannyt @ Jul 7 2008, 01:50 PM)

We use ClearCase as our source control tool and when I do a build (using the OpenG builder) I generate a Build of Material (BOM) which I save a part of the build log

...

So you can easily (one click) say which products use a specific user.lib VI?

About the network drive, what happens if you work 'offline'? all your code is gone.

QUOTE

small rant.

I can never understand why all the LabVIEW people seem to like the fact that everything is locally install, to me it make good team working and control a nightmare almost impractical at time I feel, certainly from the point of a "quality assurance manager"

I say, multiple LabVIEW versions, I say ActiveX.

Both of these urge me to separate my user.lib development from the actual user.lib.

ActiveX will always recompile one a new computer, thus a new version to distribute between computers though no code has changed.

If you upgrade from 8.5 to 8.5.1 your whole user.lib will be recompile though no code has changed.

What if you find a bug, you fix it. But you also use the code in LabVIEW 8.2 (and 7.1 and 6.1)? Where do you make the fix?

Ton

[crelf]

Sorry for coming in late on this one - it's been sitting in my inbox, but I haven't had enough time to really think my replay through.

QUOTE (Ton @ Jul 6 2008, 03:21 PM)

Some option are:

• VI description with a special string like ***Internal Reference #### Version 0.9*** (NI has such fields)
  
• A tag on the frontpanel like OpenG has
  
• A tag on the block diagram
  
• A tag using VI tags
  

I think all of those options are valid. Sure, NI not supporting tags is a worry, and I'd want to get some assurance (public or private) that NI's not looking to get rid of them in the near future. That said, irrespective of which schema you choose, you can pretty quickly write a VI that will convert between the schemas (the only problem with that is doing so will naturally rev the VI ). I like the tag option for a couple of reasons: they're not visible to the user, which means that they aren't concerned about them. Also, it means that they can't manually change them - and that's pretty important. The other options are less secure (if all you're looking at is this information to track your revisions). That the user can't see them might be a liability too: but you'd need to look at use cases on when they shouldn't and when they should (if ever) be able to see them.

QUOTE (dannyt @ Jul 7 2008, 07:50 AM)

I look back to my days doing development on Unix, the development tool set was installed on the server under source control, or deployed out from a source control tool into one location. The developers used the path environment and you could really ensure everyone was developing with the same toolset & libraries be they thirdparty items or internal.

I remember those days too, with some fondness The problem with that scenario is when different users need different versions of a component: if you find an issue in a component and want to upgrade it, or if you want to add functionality to a component, I strongly believe that you shouldn't have to force everyone to use the new version. To do so often requires them to revalidate the work that they've already done and that works for them. Sure, if it's a bug that is hurting them, or expanded functionality that will help them, then it's a good reason to upgrade, but using that model introduces schisms (code branching) where you'll have more than one version of a components being maintained in separate locations. When this happens, less disciplined engineers might even drop their versions out of SCC to make room for newer versions. Then when do they make the switch? When a new project starts? Never? Parallel development is inevitable in this scenario, and bringing branches back together leads to a lot of engineering anxiety. There's a bunch of other reasons why that isn't a good idea, but schisms is the main one. That's why development environment configuration management systems are really really (you know I mean it because I wrote it twice!) important. They allow you to minimize those schisms, and manage reuse. The VIPM is a great product* that does exactly that in LabVIEW.

* No, I'm not on the JKI payroll - I just really really (you know I mean it because I wrote it twice again!) like the VIPM.