Explicit LabVIEW Versions

[hooovahh]

I remember someone mentioning this before but can't find the topic. In any case, I have a package which has components in it that only work in LabVIEW 8.0, 8.2, and 8.5, but they have broken arrows in 8.6. With the VI Package Builder I don't have the option to say that a package cannot be installed in 8.6. VI Package Builder scans the directory and says that the VIs in it work with 8.2 and above.

 

Is this a feature that VIPM will have in the future or probably not? It's not a deal breaker by any means, but it has several use cases.

[Jim Kring]

I remember someone mentioning this before but can't find the topic. In any case, I have a package which has components in it that only work in LabVIEW 8.0, 8.2, and 8.5, but they have broken arrows in 8.6. With the VI Package Builder I don't have the option to say that a package cannot be installed in 8.6. VI Package Builder scans the directory and says that the VIs in it work with 8.2 and above.

 

Is this a feature that VIPM will have in the future or probably not? It's not a deal breaker by any means, but it has several use cases.

 

Hi Brian,

 

Yes, I recall this discussion coming up before, too, and it's something that we've been thinking about, a lot. Below, are some structured points on the issue:

 

There are a two different perspectives you can take when thinking about (and trying to address) this issue. Note that these perspectives are somewhat at odds with each other.

 

1) Make the VI Package's LV compatibility more tightly constrained.

 

On one hand, a package should know (to the best of its ability, at the time it's built), which LabVIEW version's it's compatible with (and which packages it depends upon).

Pros:

• A user can never accidentally install a VI Package onto a LabVIEW version that isn't known to be compatible.
  
  

Cons:

• A VI Package has to be rebuilt, in order for it to reflect new information about compatibility. This means that the package will need to be rebuilt every time a new LabVIEW version is released or a new dependency package is released.
  
  

Work-around:

• Create a post-build hook VI that changes "
  Exclusive_LabVIEW_Version=>=8.2
  " to "
  Exclusive_LabVIEW_Version=8.2
  "
  
  

Ideal solution:

• VIPM's package builder would allow you to specify explicit LabVIEW version compatibility.
  
  

2) Add additional information about "validation/certification" into the system.

One the other hand, when new LabVIEW versions are released (and new dependency packages are released), it would be useful to be able to update the compatibility/dependency information.

Pros:

• A package does not need to be rebuilt, in order for additional information about compatibility to be added into the system.
  
  

Cons

• The additional information doesn't travel around with the package, which means that everyone will need access to this shared information.
  
  

Work-around:

• Use "certified" (by you or your organization) VI Package Configurations (VIPC files). A VIPC contains LabVIEW version information (which determines which LabVIEW version to "Apply" the configuration to) in addition to a set of packages. So, you can create one certified VIPC file for each LabVIEW version that contains the packages you know to work for that LabVIEW version.
  
  

Ideal solution:

• There would be some central repository (for your organization) that contains information about validated configurations.
  
  

I'd be curious to hear your feedback about this and what type of solutions you'd find most useful.

 

Thanks,

 

-Jim

[hooovahh]

To be honest this kind of feature isn't a persistent thing, at least not for us. Out of the 20 or so different packages I've made (with several versions for each) I've only once came across a situation where the >=8.2 wouldn't work. Since this is so rare for us, I wouldn't mind building a post hook VI to change the compatible version for that package.

[Jim Kring]

To be honest this kind of feature isn't a persistent thing, at least not for us. Out of the 20 or so different packages I've made (with several versions for each) I've only once came across a situation where the >=8.2 wouldn't work. Since this is so rare for us, I wouldn't mind building a post hook VI to change the compatible version for that package.

 

OK. I'm glad that the post-build hook is a viable solution for you.

 

Ya, this issue isn't at the top of everyone's list -- it's most important for VIPM users who are interested in system validation (FDA, etc.).