Drawback of packed library vs old llb

[Joseph_Loo]

It is suggested you use a source control product with your test. When you create your project, you can have a deployment setup and a test setup. In the test setup, you can use an exe file or just run the system checking the items out.

The source control will handle the hundred of files for you to work with. I have found if you pack them in a library, it makes it difficult to locate the file and determine which one is newer or a different version. Separating the VI out and different configuration files, support files, etc. will allow you to use the source control system to determine the various versions being used and which can be discarded. If done properly, you can discard the vi and later discover it is needed, you can put it back in without a problem using the source control. Likewise, if the newer version needs to be roll back.

The source control system helps in controlling all the different versions and test you will need.

[JÞB]

---

@dacad wrote:

I got that but that puts me back in the situation where I have a huge number of items to maintain on the deployed systems.  Whether they are source vi's or individual packed libraries, a hundred test cases equals a hundred files, regardless of their format.

That is what I am trying to avoid.

Doug

---

Well then let me suggest another alternative not mentioned above.  Use a *.vip.  What, What's that and what does it do for me?  Exactly what you need, manage and install packages of code and code dependancies by revision with traceability and tools to quickly identify when new versions are available.  See here for more on VIPM

Your welcome for the free plug Jim.

[crossrulz]

---

@JÞB wrote:

---

@dacad wrote:

I got that but that puts me back in the situation where I have a huge number of items to maintain on the deployed systems.  Whether they are source vi's or individual packed libraries, a hundred test cases equals a hundred files, regardless of their format.

That is what I am trying to avoid.

Doug

---

Well then let me suggest another alternative not mentioned above.  Use a *.vip.  What, What's that and what does it do for me?  Exactly what you need, manage and install packages of code and code dependancies by revision with traceability and tools to quickly identify when new versions are available.  See here for more on VIPM

Your welcome for the free plug Jim.

---

As much as I love VIPM, I found it really only good for managing reuse libraries.  If only trying to maintain a program (or distribution), SCC works so much better.

[dacad]

Yea, unless it's a free version that has the deployment tools, a vipm tool really isn't an option.  No budget for that right now. What I looked at, on the JKL side at least, it appears to be more for development (source) code management than deployment management.

Isn't scc (source code control?) the same thing?. or is there just something other than vipm that I have not found yet.  But if it costs, I'm in the same boat. No budget.

Also to clarify, when I use the word test or mention test vi's, it refers to what the vi's are doing to our products.  It is not refering to testing the code or vi's themsleves.  Not sure if that caused any confusion or not. I'll stick with plug-in going forward.

From my perspective, I don't think I'll have a problem using a single library type file to deploy the plug-ins since they would be controlled by a project file on the development side.  If I modify/add/subract one of my plug-in vi's, I will have a self populating folder that keeps my current list up to date. I'm not concerned to much about previous revs as in reality, modifying something once it has been released will be infrequent.

If there is not "compiled into single file" option that allows loading only the portion required, then in the end, I will have to utilize something to manage all the individual plug-in files.   As of today, I only have about 3 dozen but that is going to grow quickly in the months coming.

Doug

[crossrulz]

---

@dacad wrote:

Yea, unless it's a free version that has the deployment tools, a vipm tool really isn't an option.  No budget for that right now. What I looked at, on the JKL side at least, it appears to be more for development (source) code management than deployment management.

Isn't scc (source code control?) the same thing?. or is there just something other than vipm that I have not found yet.  But if it costs, I'm in the same boat. No budget.

---

There is a free community version of VIPM which will let you build packages.  Again, I find it better for reuse libraries mostly since it maintains for each version of LabVIEW installed.

SCC isn't quite the same as building packages.  SCC is more for project management while VIPM is more for reuse management.

I used Tortoise SVN to maintain my test racks.  It is free and interfaces directly with Windows Explorer.

[dacad]

In looking at both, they seem to each be different approaches to project management vs project deployment. The vipm could perhaps work but it looks geared to be set up to pull updates as opposed to pushing them.

I may end up going a different route and do some trials with VI Server.  While I will still have the entire group of plug-ins to manage, at least I would only have to maintain a single location of them.

Thanks for the input as, whether it works or not, it make the brain think about other options.

Doug

[DFGray]

For what you want to do, either an LLB or a packed library will work.  Which you choose depends upon several things:

1. How big are your plug-ins?  Packed libraries load faster with small items, LLBs with large items.  I believe the crossover is about 200 VIs, although it is LabVIEW version specific and likely to get much more so.
2. Do you need hierarchy in your package?  LLBs are flat.  Packed libraries can have hierarchy.  If you have multiple objects with children in the same package, you will need hierarchy to prevent the method VIs of the parents and children (which have the same name on disk) from confilicting.
3. Do you load everything in a package, or just a fraction of the package?  If just a fraction, you probably want the LLB.  If the whole thing, you can use a packed library.
4. Do you use LabVIEW classes?  If so, can you develop bottom up?  Packed libraries change the namespace of their contained objects.  If you use LabVIEW classes, this means you must develop the class, then create the packed library before actually using it.  This actually forces good programming practice, so is not necessarily a bad thing. If you want this, use packed libraries.

Take home message - what you use depends upon what your constraints are.  From the preceding conversation, it sounds like LLBs would probably be your best bet.  But, if your modules are small enough, you might get better performance from packed libraries.  Being at heart an experimental physicist, I would recommend you try both and pick the one that works best.  Good luck!

[dacad]

DFGray

You might have just answered the one fact that has been eluding me.  If I read your post correctly, when I call on an item in an LLB, it loads only that item and not the entire file (like the vilibp does)

My plug-ins are small, averaging less than 200Kb and non-hierarical in nature. The dependent items are all common and will be in the executable.  But there will be a lot of them. Eventually exceeding a couple hundred.

Not using classes on this project as I have not worked with them enough to be able to implement in the time frame required.

The way this will work, the operator will run the exe, will select a part number from the supplied drop down list. Based on that part number, one and only one of the plug-in vi's will need to be called and used for anywhere from 10 minutes to all day leaning more towards the all day scenario. (depends on order qty)  They then switch to next part number, next plug-in vi, etc. etc.

If what you say about the LLB file loading only the called upon member is the case, then that is indeed the path I want to take.  Can you please confirm that I am interpreting that correctly ?

Thanks

Doug

[DFGray]

So far as I know, if you load an item from an LLB, only that item loads.

One caveat: if your VI is part of the library, the library must be opened first, and it will scan to ensure all the items in it are available (i.e. the library is complete).  If you have a library with lots of members and only use a few of them, you may want to consider breaking it up.  This assumes that diks load speed matters that much.  From your description, I am not sure you will notice.  Very old LabVIEW versions (8.0) actually loaded all items when a library was used.  This was fixed in the 8.2 to 8.5 time frame.

[dacad]

The initial load time is not critical as it will load only once at the beginning of each session for a given part number and then the reference will stay in the loop for duration of testing for that part number.  I will work with options and may have methods to break it up into smaller llb files based on certain criteria.

Thanks very much for this input as it was what I was looking to determine from the get go.

Doug