Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Life Lessons #1 - Project Portability

Active Participant

What-ho wire-makers.

Welcome to my new series of short articles, each one will be about something that we've learnt over many years of writing industrial software.

Today it's all about project portability. Time spent making your project portable is time well spent. At SSDC we like to be able to download a project onto a Laptop, Virtual Machine or customer machine from our repository and for it to work.

This means........

Keep all referenced data and libraries relative.

Remove external dependencies.

Minimise use of Instr.lib and User.lib

For us the project is a directory that wraps around the LabVIEW project containing everything pertaining to the project, source code is only one part and our projects can contain multiple LabVIEW projects.

ProjectDir.jpg

And because we are using the directory structure of the filing system we don't use virtual folders in our LabVIEW Project. I think that may make us bad people for some reason I can't fathom.

So here's our Project

Project.jpg

The test for portability is one of our code review items and involves exporting the repository into a clean virtual machine (with LabVIEW Loaded) and into different directories (usually desktop and \User\Public\Something or other.

Doing this has saved us a lot of hassle over the years.

Lots of Love

Steve

Comments
Active Participant

I've had challenges load times and executable/package builds stemming from using auto-populating folders.  They add enough complication to my life that I've stopped using them.

Active Participant

Never had an issue on any of our projects, which is interesting.....

Active Participant

I also avoid auto-population like the plague.

Cheers,

Matt Pollock
National Instruments
Active Participant

We wouldn't have builds in the project directory tho', tis only source-code

Active Participant

But why?, digging down brings out the real answers I find.

Similarly the interesting question is why do my projects not suffer issues where others do? I can't buy the argument that it makes life more complicated if it functions correctly, it's only mimicing what's happening on the hard-drive. I'll buy it makes life complicated if it doesn't work properly, if that's the case perhaps the next "why" may be something worth talking about.

Active Participant

Virtual folders allow me to create visual relationships that either I can't or don't want to represent on disk.  It also allows me to only show the files that are important to the LabVIEW project (other support files that are irrelevant aren't shown).  Also, I don't like that my project changes (and gets a dirty dot) just becuase I added a file on disk.





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

There are times when I need to have certain components in virtual folders in my projects (to set bulk properties for builds, for example). 

I've had cases in the past where having a class or .lvlib file in a separate folder than all of the items it contains (example: subfolders on disk containing the items, with the library one level up).  This leads to some confusion in the view, since LabVIEW doesn't want to show the same item in two places (in the library and in the subfolder on disk) simultaneously.  The more libraries you have, and the deeper the hierarchy goes, I've seen performance degradation as LabVIEW has to work much harder.  The resulting view is not quite an autopopulated view any longer, either.

I much prefer to use virtual folders, since what I see in my project is exactly what I want, where I want.  Plus I can change it without source control implications.  Any cruft (documentation files, alias files, source control artifacts, etc) I just don't include in the project.

Cheers,

Matt Pollock
National Instruments
Active Participant

Weirdly that's precisely what I like about it, I want the project to change if I add a file (because the project has changed!). I find the virtual folders to be a pain in the bum when I have to rescue projects that go awry (which is about 20% of my workload), because they hide information I want to know about.

Active Participant

Excellent stuff Matt, I can get my teeth into this...

I do all the library stuff as it is in the file hierarchy, I have to admit my library count/class count is possibly lower than the norm.

MattP wrote:

I much prefer to use virtual folders, since what I see in my project is exactly what I want, where I want.  Plus I can change it without source control implications.


                   

I would want to track any changes in source code control, hard disk space is cheap.

MattP wrote:

Any cruft (documentation files, alias files, source control artifacts, etc) I just don't include in the project.

Yup I'm with you there!

Active Participant

swatts wrote:


                       

Weirdly that's precisely what I like about it, I want the project to change if I add a file (because the project has changed!)


                   

It depends on what you mean by "project" - whether that's the things you're working on, or the LabVIEW project itself. Or both. See? Simple!





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

swatts wrote:                      

MattP wrote:

Any cruft (documentation files, alias files, source control artifacts, etc) I just don't include in the project.

Yup I'm with you there!                  

This confuses me: if you have documentation files that you *don't* want to show up in your project, and you're using auto-populating folders, that would mean you'd need a secondary location for the documentation. So you'd be maintaining two locations for the same thing?  Why not just use a virtual folder that you only show what you want?

Also, it's not just about hiding things you don't want to show up in LabVIEW - you can put things from multiple on-disk locations into one virtual folder, so that's a bonus.





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

For us the LabVIEW project is just a part of the whole, the whole is the thing in version control.

Active Participant

Christopher Relf wrote:


                       

swatts wrote:                      

MattP wrote:

Any cruft (documentation files, alias files, source control artifacts, etc) I just don't include in the project.

Yup I'm with you there!                  

This confuses me: if you have documentation files that you *don't* want to show up in your project, and you're using auto-populating folders, that would mean you'd need a secondary location for the documentation. So you'd be maintaining two locations for the same thing?  Why not just use a virtual folder that you only show what you want?

Also, it's not just about hiding things you don't want to show up in LabVIEW - you can put things from multiple on-disk locations into one virtual folder, so that's a bonus.


                   

That's because you are a 25 year old in a 50 year old body (I had several jokes all of them inappropriate..), the article is about portability (the auto-pop stuff is just me being a scamp). The docs directory for us is at the same level in the hierarchy as the sourcecode directory.

The simplest way to portability is not to have stuff in multiple locations, but to dump it all in a single hierarchy like the pretty picture up in the main article.

So we don't regard multiple disk locations as a bonus. Mind you I expect our use case differs greatly from yours, similar to my comments on reuse I would expect the pick n mix approach to work better in your environment than ours (it would be a disaster for us)

Active Participant

swatts wrote:


                       

Christopher Relf wrote:

swatts wrote:                      

MattP wrote:

Any cruft (documentation files, alias files, source control artifacts, etc) I just don't include in the project.

Yup I'm with you there!                  

This confuses me: if you have documentation files that you *don't* want to show up in your project, and you're using auto-populating folders, that would mean you'd need a secondary location for the documentation. So you'd be maintaining two locations for the same thing?  Why not just use a virtual folder that you only show what you want?

Also, it's not just about hiding things you don't want to show up in LabVIEW - you can put things from multiple on-disk locations into one virtual folder, so that's a bonus.         

the article is about portability (the auto-pop stuff is just me being a scamp). The docs directory for us is at the same level in the hierarchy as the sourcecode directory.                  

And hence my confusion!

swatts wrote:         

That's because you are a 25 year old in a 50 year old body (I had several jokes all of them inappropriate..),


                   

I would expecting nothing less form you Steve! Nor more, come to think of it...





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Member
  1. So you only use base LabVIEW?
  2. How about LabVIEW toolkits?
  3. What about DAQ, VISA, FPGA, cRIO etc?
  4. What about packages that install into vi.lib?
  5. How do you distribute reusable libraries?
  6. When you're setting up your monolithic folder. How do you get all the components into it? Do you have a skeletal directory structure with all the DLLs and crap and copy it somewhere?
  7. Is there any automation involved?
  8. Also, how do you reproduce the build process. Do you have a build tool?
Active Participant

That's a topnotch set of questions!

Michael Aivaliotis wrote:


                       

  1. So you only use base LabVIEW?
  2. How about LabVIEW toolkits?
  3. What about DAQ, VISA, FPGA, cRIO etc?
  4. What about packages that install into vi.lib?
  5. How do you distribute reusable libraries?
  6. When you're setting up your monolithic folder. How do you get all the components into it? Do you have a skeletal directory structure with all the DLLs and crap and copy it somewhere?
  7. Is there any automation involved?
  8. Also, how do you reproduce the build process. Do you have a build tool?


                   

1. Nope we use whatever the project dictates - 50%+ is now RT and FPGA

2. Try to keep away from toolkits as they are an external dependency, not dogmatic about it tho', or we move from the library (VI, INSTR or USER) and namespace. We try to embed everything in the project. An example is the FTP stuff, we modify a version and embed it in the project because we have improved its functionality.

3. All of those are part of the standard LabVIEW package so we leave as is, there is an argument to embed but it doesn't give much ROI.

4. Don't use many external toolkits, our re-use model is project based, so if it is useful to us we will embed it into our project template. Each project would then reference its own copy and version.

5. We don't, we deliver projects. The last time I did an API or Library as a deliverable was in LabVIEW 5.0 I think. It was a nanopositioning toolkit and we used llbs.

6. To make it portable we keep referenced dlls (project specific) in the same directory as the Main VI. With the called subVIs below it in the file hierarchy LabVIEW finds it all with no problems.

7. Only from the project template and VI generation perspective, we have a wide variety of project types so I've found that automation is a significant investment in 1 particular way of working. So we have project templates that have all the functionality for particular jobs that repeat (for example we have a template for a multi-unit test system). This gets exported from our repository as a working project and commited into a completely new repo for each new project.

8. Our project template has a working build spec in it. Most of our use cases are delivery of source code or we build the systems. I'd say <5% of our projects involve delivery of EXEs to a customer that will just use them. In those cases the portability aspect is a bonus because you are not generating complicated installs etc.

That was an excellent way of digging out the peculiarities of our use case, it's almost as if you had spent time interviewing people!

Active Participant

Hi Steve,

 

I am late to this party and you and I have discussed our differences in LabVIEW project structures in the past. However, you and I were talking about this last week and I wanted to write some of what you and I discussed here.

 

When I teach Managing Software Engineering in LabVIEW and people ask me what is my recommendation for project structure, I send them to your other post on project structure and to the way a project using DQMH modules is structured. Then I suggest people try to understand where you are coming from and where we are coming from and based on that decide what works best for them. 

 

I always tell them: "my way is just a way, it is not The Way". Just make sure whatever approach you take is based on an informed decision and not just an impulse. 

 

From what I am reading in the comments, it really boils down to how much the LabVIEW developer is using classes and libraries. In our case, we use an lvlib for each module, this means that the code organization can be done using virtual folders within the library itself and the auto-populating folder would only show that there is an lvlib, nothing more. In fact, when I am doing code clean up and looking for code that is no longer used, I use an auto-populating folder to find all the VIs that are in the same folder as an lvlib, but are not part of the lvlib. This normally means that I either forgot to add it to the library or that it is no longer used and it should be deleted. But that is the only extent of the use of auto-populating folders for us.

 

Thanks again for sharing your knowledge with us.

Regards,

Fab

Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion