LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.lvib / .llb / .lvilp Which one to choose and how to organize it?

Solved!
Go to solution
Highlighted

Hi all.

 

For a project I have to develop an application to control and monitor part of a tested. For this reason I have to send "a vi" that will be used in a bigger application (according to customer requirements) but I'll need more than one obviously and the question of how to manage and send all this appears.

 

For safety (and security) reasons, my VIs must not be editable and some not even openable.

 

I thought using a Libray would be the best option, but then what should I choose, a project Library or an .llb ?

What I understood so far is that llbs are more something from the past and not really used anymore even though they still have some advantages. But I do need to do version code, so I believe a project library would be the best right?

 

How should I then organize it? I've seen some with two main virtual folders: Public and Private, the latter being password protected. But what do you put in those exactly?

 

Finally what is exactly a packed project library ? Should it be my final delivery to the customer, or when I'm done with my library, I save it, zip it and send it away?

 

Thanks for your clarifications.

Vinny. 

0 Kudos
Message 1 of 32
(435 Views)
Highlighted
Solution
Accepted by VinnyLaTaupe

How is it going to be used?

 

If it's not going to be called (or not required to be called) from LabVIEW, a dll would be an extra option.

 

Never use a llb... AFAIK, these are only here for backwards compatibility. The won't solve your problems either.

 

Public\private is something else. Public VIs can be called publicly, private VIs can only be called from VIs within the library\class.

 

VIs in a packed library can't be edited, but the public VIs can be used like VIs. They can't be edited, and there's no diagrams. Sound to me like the best option.

 

PPLs are like dlls, they contain compiled code, and no source code. But unlike dlls, they are native to LabVIEW. Their functions can be used as VIs, and they can't be called from outside a LabVIEW environment (like TestStand, LabVIEW executables).

Message 2 of 32
(402 Views)
Highlighted

I'd second the suggestion for a Packed Project Library (PPL).

 

Be aware that if you build a few and they depend on each other, you'll want to be careful with how you build them. It's not that bad (and certainly, blog posts from <2015 or so make it sound disastrous, so I'm glad I came to them after that...) but might be worth checking out a presentation Mark Yedinak and Yinhui Chen gave at NI Week in 2019: https://labviewwiki.org/wiki/NIWeek_2019/Effectively_Using_Packed_Project_Libraries


GCentral
Message 3 of 32
(399 Views)
Highlighted

I'll throw in a third vote for PPLs.  As long as you don't have dependencies on other PPLs, they are very easy to use.  So some options to watch for when build a PPL based on your requirements:

1. Debugging - Make sure this is turned off in order to remove the diagrams from being visible.  Do note you lose debugging capabilities, but this probably isn't an issue at this point.

2. Allow future versions of LabVIEW to load this packed library - If you don't want to have to rebuild this PPL for each version of LabVIEW your customer could be using, you will want this enabled.  Do note that this was a new option starting with LabVIEW 2017.

 

I think this was already stated, but the user of the PPL will only be able to see VIs and controls that have a public access.  So any VI in your library you don't want your customer to know even exists, set to private.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 32
(383 Views)

I agree with previous posters. PPL (lvlibp) seems like the right solution for you.

It's fairly natural to Group up your code in a lvlib, i hope, so just add a Build PPL to your Project.

Preferrably you can have a 2nd verification Project that uses said PPL to run some functions just to check that all seems to be in order.

Then you can happily send the code (PPL) to your customer.

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 5 of 32
(370 Views)
Highlighted

Ok these answer largely my question.

I'll go for a PPL then, I don't have any other dependencies with other PPLs, just some "drivers" for other equipments.

 

     @Wiebe  "How is it going to be used?"

Typically I need to control a motor driver, so I need to create "a" VI that will take as a customer input a velocity setpoint, and the VI does all the job: Conversion from rpm to bytes array, communication with the motordriver etc. and then I need another VI questionning the motordriver to get its current velocity (also temperatures).

 

So I'd say there would be a few VIs in public non-editable, that would consist in Init.vi; parameters.vi; MotorControl.vi etc. actively used by the user and called in his program, and then a bunch of sub-VIs (conversion, communication etc.) that would go in private.

 


@crossrulz wrote:

1. Debugging - Make sure this is turned off in order to remove the diagrams from being visible.  Do note you lose debugging capabilities, but this probably isn't an issue at this point.

2. Allow future versions of LabVIEW to load this packed library - If you don't want to have to rebuild this PPL for each version of LabVIEW your customer could be using, you will want this enabled.  Do note that this was a new option starting with LabVIEW 2017.

 

I think this was already stated, but the user of the PPL will only be able to see VIs and controls that have a public access.  So any VI in your library you don't want your customer to know even exists, set to private.


  1. Yes, that's something I was thinking of, to make sure I do not forget about it I think I'll create a little checklist.
  2. Something not appearing in my requirements that I need to ask them is what version of Labview they're using. I have 2019, but if ever they have 2011 for instance then I'll have to downgrade my code right? Or is it something manageable directly in the build specifications?

Finally, but that's a bit of a digression, I might post something aside for this, how would you manage your revision in the end?
In my company we are using TortoiseSVN, and I am currently the only Labview developer but until now SVN wasn't properly used with LV and I wanted to start using it correctly (I already checked the technical aspect). So my question is, would you do revision history only on the code or also on any build you produce and send over? What is the the major/minor/revision number you'd give in the build? 

0 Kudos
Message 6 of 32
(363 Views)
Highlighted

Ah one last question, but as I wanted to include a screenshot I believe I have my answer:

Do you create a Project library within the project explorer or as a standalone project?

But given that the "Build Specifications" is only available in the Project Explorer, if I want to do a PPL I guess I don't have a choice.

VinnyLaTaupe_0-1600092899969.png

 

0 Kudos
Message 7 of 32
(354 Views)
Highlighted

@VinnyLaTaupe wrote:
Something not appearing in my requirements that I need to ask them is what version of Labview they're using. I have 2019, but if ever they have 2011 for instance then I'll have to downgrade my code right? Or is it something manageable directly in the build specifications?

You can only compile for the version you are using.  With the option I mentioned earlier, it just allows newer versions of the Runtime Engine to be able to run the built file.

 


@VinnyLaTaupe wrote:

Finally, but that's a bit of a digression, I might post something aside for this, how would you manage your revision in the end?
In my company we are using TortoiseSVN, and I am currently the only Labview developer but until now SVN wasn't properly used with LV and I wanted to start using it correctly (I already checked the technical aspect). So my question is, would you do revision history only on the code or also on any build you produce and send over? What is the the major/minor/revision number you'd give in the build? 


SVN should be used to keep your source code.  Your customer should have no access to your repository.  You email, copy to a CD, etc. to give your customer the PPL.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 32
(351 Views)
Highlighted

@VinnyLaTaupe wrote:

2. Something not appearing in my requirements that I need to ask them is what version of Labview they're using. I have 2019, but if ever they have 2011 for instance then I'll have to downgrade my code right? Or is it something manageable directly in the build specifications?

They won't be able to downgrade anything that is protected in any way.

 

PW protected VIs, packed libraries, PW lvlibs, DLLs all have to be recreated by you.

 

The only new thing is the "compatible with newer versions" flag, but that won't go back to LV11. I also think this is for forward compatibility, not for backward compatibility. So you'd have to make it in the lowers version that has this feature. I'm not 100% sure about this.

 


@VinnyLaTaupe wrote:

Finally, but that's a bit of a digression, I might post something aside for this, how would you manage your revision in the end?
In my company we are using TortoiseSVN, and I am currently the only Labview developer but until now SVN wasn't properly used with LV and I wanted to start using it correctly (I already checked the technical aspect). So my question is, would you do revision history only on the code or also on any build you produce and send over? What is the the major/minor/revision number you'd give in the build? 


Major would need a complete rework on their side.

Minor would add new features, maybe small changes to their side.

Revision should be compatible, but would fix bugs.

 

You can also use build. It's not in the installer though, that only has major, minor, revision...

 

It's not very critical (we actually use build for new features and bug fixes), but it helps if you stick to it.

 

The only thing that really matters is (back)traceability. You should know what commit was used for a version, and how to get from a version to a commit. This is pretty straightforward if you label each delivered version in SCC. We also tag each release. This makes it even easier to find. In HG this might get uncomfortable, AFAIK each tag is a copy of the entire repo. In SVN or GIT a tag is simply a reference to a place in time in the repo.

 

I'd go straight to GIT. GIT is almost like all good things from HG (local repo) and SVN (centralized repo) in one. You can commit even when you're not connected, something that is a big problem with SVN. 

Message 9 of 32
(348 Views)
Highlighted

TortoiseSVN works fine with LV. The integration isn't good (or existing?), but i like to check in and out from Explorer anyway. 🙂

There's some tips as to configure Tortoise to handle .vi as binary and avoid trying to merge (though that'd be true for most such programs) and a couple of other pointers. After that i've had no real problems with the system. (Me doing stupid stuff and not knowing quite what i'm doing isn't a system problem)

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 10 of 32
(346 Views)