VI Packager to gather up a big mess

[The_Big_Lebowski]

Hello,

I have inherited a mess.

I have used Labview 6.1 in the past, but I am far from being an expert, but I am well versed and understand most everything.

Labview 6.1 had no project manager back in the olden days.

I have a VI that operates a piece of test equipment that is crucial to our business. (I'll call it "The Application")

It has been worked on by several people over a course of several years.

- It was created in Labview but not sure what version.  It still must execute using LV 2010 environment present (not a run-time engine).

- It will NOT execute in LV 2012.  I have tried it.

- It was NOT created using the Project Manager.  It is a slew of VI's and Sub VI's and things that Labivew decided it needs.

- It has always been executed using the LabView Developers Environment (it was never built into a stand-alone app.)

- It is rather large and all over the place.

- It has scales, (NI-DAQmx) and DAQ fuctions and calibration files I would also like to keep intact.

My specific question is:  How can I "gather" all the bits and subs up into a project so I can compile it into a stand-alone package?

When I look at the main VI tree, it is calling stuff all over the place, and those files which are all over the place are not in the folder where the Main VI is located.

I must upgrade to LV2012 but am afraid that if I don't properly pack up this application, I will lose it forever.  Can I rev the application up to Labview 2012?

Is there a way to gather it all up into a nice neat package using the project manager or is there a 3rd party packager I can use?

Specific helpful answers are always much appreciated.  Irrelevant comments, not so much.

Lebowski

[Hooovahh]

First I would image the machine.  Or take the hard drive out and keep it in a safe place where it can be booted up again if for some reason you forgot to get some piece of information that you didn't know was needed.

You say it will not execute in 2012, why is this?  Is it because the code is too old and won't open?  You can try to save it in something like 8.5 then try to open that in 2012.  There is a thread where older code can be resaved to newer versions.

You can save the whole hierarchy by going to File >> Save As... and then choose to save the whole tree to a new folder.  This will save all VIs and their dependencies so you have all of your code in one place.

Backup MAX settings.  I assume this is where the DAQmx scales and other things are saved.  File >> Export in MAX.

This should be all the information you need to upgrade to what ever versio nof LabVIEW you need, but if you realize you forgot something (could be ini settings or documentation) remember you have that backup image or hard drive you kept for safe keeping.

Many times when upgrading you will find that some old hardware is no longer supported.  If this is the case you will have many more issues to handle, with new hardware to purchase, and software to change to handle the new hardware.  If you aren't experienced enough to handle all of these changes I would recommend getting in contact with someone you can contract in for a few weeks to handle these changes.  Good luck.

[Thoric · Accepted solution]

If it must still execute in LV2010 then continnue your development in LV2010.

If you want to "Project-ize" the application then take an empty LabVIEW Project and add the Main VI. Under Dependencies will be placed all the called subVIs. You can then use this list to drag and drop add all the necessary subVIs up into to the project space, using Virtual Folders to make the appearance easy to navigate.

To make sure you have a good copy, use the Project Save As feature to make a copy of the project elsewhere (such as a networked location, or an memory stick) which will give you the option to include all dependencies.

To cleanup the file locations, switch the project tree view from Items to Files by selecting CTRL+E on each dependency and Move on Disk each dependency to a more preferable location. You might want to reserve this process for the cloned project to ensure you don't move VIs in the original application (which might be expected for other applications).

Once here, you can then consider looking into why it doesn't work in 2012, but if you need it to work in 2010 I wouldn't develop in 2012 because back-converting can be fraught 

[The_Big_Lebowski]

Thank you both for the advice and suggestions.

I think I will do both... project-ize it as Thoric stated, and as per Hooovahh, save files to a directory and save all dependencies.

This will give me a double back up.

It sounds like Project Manager is the "packager" that was looking for.  I will study it more.

---

Thoric wrote:

If it must still execute in LV2010 then continnue your development in LV2010.

If you want to "Project-ize" the application then take an empty LabVIEW Project and add the Main VI. Under Dependencies will be placed all the called subVIs. You can then use this list to drag and drop add all the necessary subVIs up into to the project space, using Virtual Folders to make the appearance easy to navigate.

---

Yes, this is what I want to do, but I guess I was not clear... It does not have to execute in LV2010 forever, but to run it at all right now, it MUST execute in LV2010...  It is the only way it will run.

I must (at some point soon) upgrade to LV2012 due to a license upgrade and a tool kit upgrade that my LV2010 does not have.

As I had stated before, it will not execute in LV 2012.  I do not know exaclty why, but I get alot of "file not found" errors.  My first guess (duh!) is for some reason, cannot find all the files it needs to run.  The way it is saved right now, and when in LV 2012, and you run the main VI, it tries to load the sub VIs and all of the dependencies but cannot find them.  While doing so, it hangs 30-40 times while trying to look for but cannot find certain files.  Then, if you keep saying skip (by-pass), you get a broken arrow when it finally loads and it will not run.

This is what has led me to packaging it.  I believe that project-izing (awesome buzzword) I will be able to run it in 2012.  Then I can compile it and run it using a run-time engine.  It also seems that starting any new project, project manager is the way to go from the start.  The .llb thing was what we used in the olden days for a multi VI project, which was tedious.

Again, the Project Manager feature is all new to me.  I have version experience gap.Will let you know how it worked.  Thank you both for the assistance!

~ Kudos!

[SunshineDesign]

I would approach it by making sure I found and gathered every vi used and called in the application. Then I would put them all in a project directory and relink all the vi's calld to the new locations and make sure it can find and load everything. Then I would go thru and see what potential version issues are after getting it up and running under LV2012. So by going thru the existing application and having the requirements for the application, and the requirements for all the VI's to run the application, you should then be able to bring a measure of project management to the application. I always start with requirement on any project. Otherwise what is the plan and tactic?

[The_Big_Lebowski]

Sunshine,

What color is the sky in your world?

Do you think boss's ever have a plan?  They don't.

If yours does, I want to work with you at your company.

"I need this done as fast as you can, or yesterday, whichever is quicker.

We need it to be back up and running bla bla bla {insert suitable boss BS here}"

~My Boss

I actually agree with you, but had to bust your bacon a little.

I wish I had the time to be able to afford a measure of project management.

All I ever do is put out fires (aka be reactionary, never proactive).

I am, in no small part, the guy they modeled Dilbert after.

[SunshineDesign]

Blue like most folks. The difference is I take whatever I get and make them better, and I've had some handoff or takeover stinkers in my time.

Point being that I work to manage the programs and projects. I gather requirements, design, review and build. If I am taking over, and it's a mess

I take the time to clean, organize and document what I can as I work the discovery phase and continue to build on that as time with the project,

so the next person, our me when I pick it up again, has an easier time. That is real engineering, If not you are just a tweeker and not a serious engineer.