How Copy a Program Correctly?

[FlybyWire]

I have a machine at my work running labview we don't have any understanding how the program runs.  I want to go copy the program off machine to start figuring it out and create a backup in event of a crash.  My question is how is the best way to do this I can not risk damaging the original machine file as machine is critical to operation.  Is it really as simple as just copy past VI onto a flash drive?  

[crossrulz]

---

@FlybyWire wrote:

Is it really as simple as just copy past VI onto a flash drive?  

---

The VI and any other dependencies (other VIs, controls, project, etc.).  And once you get it copied off, put the code into a Source Code Control (SCC) such as SVN or Git.  Let the SCC maintain your history and backups (the repository should be on a server).

[altenbach]

---

@FlybyWire wrote:

I have a machine at my work running labview we don't have any understanding how the program runs.  I want to go copy the program off machine to start figuring it out and create a backup in event of a crash.  My question is how is the best way to do this I can not risk damaging the original machine file as machine is critical to operation.  Is it really as simple as just copy past VI onto a flash drive?  

---

No, the Vi is probably not sufficient, because, as mentioned, there will be dependencies and drivers and such, maybe even hardware, such as DAQ boards. I can guarantee that if you just copy the toplevel VI, it will be broken unless this is some gigantic monolithic Vi with a diagram the size of a football field! 😄 (In that case, your current problem is only the tip if the iceberg!).

Are you really running a "VI" in the development environment for "critical operations" (sic)??? Why isn't this a properly built executable? Do you know who wrote the program? What does it do? Are you planning to make modifications?

It is just a collection of files or nicely organized as a LabVIEW project? Do you have the same LabVIEW version on the second computer? How familiar are you with LabVIEW?

[FlybyWire]

So the program was built by someone who no longer works for company like 7 years ago.  The Machine runs fine and is used for testing equipment it pretty complex running load cells feed back from device and controlling some pressures and voltages.  I am new to LabVIEW and for lack of a better option been put in position of trying to figure it out and hopefully make a newer better documented machine. We do to turn over don't even know how to get in touch with original programmer.   I might just design a new system from ground up but was hoping to learn a bit by looking at old program to save time.  I am still not fully convinced even that LabVIEW is best to run the system or if a PLC would be better...only issue is we need analysis data...

Organization on project is kind of confusing ...

I have a newer LabVIEW on my PC...

[altenbach]

If you are "new to LabVIEW", this is probably not something that will be very successful unless the program is very simple.

Do you know how much LabVIEW experience the original programmer  had? Any certifications (e.g. CLD, CLA? .... or was is just an intern straight out of middle school? 😮 )

[MontgomeryScott]

I agree with what others are saying here that this can be a large undertaking. Sometimes a company uses labview and gets a developer that does not think about "what happens if this computer dies?"

Go to your top level VI and in the top toolbar select "view" under that menu look at VI hierarchy as well as subvi's and unopened subvi's. This will give you an idea of the volume of sub vi's you are working with.

Altenbach mentioned "Projects" These maintain a very useful roadmap of everywhere the program reaches out while running. The program will use a combination of custom VI's, manufacturer VIs made for their equipment, as well as VIs that come with every copy of labview. All these memory references in a project is VERY useful. Your goal if it does not have a project is to get it there!

For now, find the program on the machine's hard drive and copy the entire directory. Make an image file of the HDD if you need to or can, its cheaper than losing a custom program forever. Once you have a copy, start making a labview project out of the VI. stick everything into one folder, make it "autopopulating" in the project explorer.

Lastly, if your company has you as the "labview guy" they need to train you. you can do a one week class in areas, and they have online courses too. Encourage them to invest in you!

This kind of tom foolery happens when there isn't good management, good luck!

[FlybyWire]

I have no Idea of exact level of training he had but looking at program it is probably expert level...he's got multiple complex arrays and many sub levels that change based on commands...he's also interfacing with several devises...I don't know enough to describe better...   I only have labVIEW core one and a book(Labview for everyone) and the internet...so yeah I have learned a ton but not close to this ... I also found out at one point a contractor tried to figure out the code to make a new program and failed so....hmmm I am thinking it might be best to do a ground up at this point...with allot better documentation as the program documentation is not good at all...some of labels include things like "big ugly loop" and stuff that only original guy would get...

[MontgomeryScott]

If he has done a lot, perhaps he does have a project hidden somewhere. Have you done a search for "*.lvproj" just to see what turned up? Core I and core II take you a long way once you have the fundamentals. I make a lot of DAQ programs that speak to instruments, and yes a lot of googling happens, but you can do it! once you get arrays and data handling down, the big hang up of labview is making "act like windows" people want a lot of creature features, which means you need good error handling and input checking, because someone will try name a file "Record14?? Tuesday@1500"

when you take the steps into being a developer, do yourself a favor and ask "willI use this program again?" if its an input checker for typed inputs for filenames, the answer is YES. keep a copy of these somewhere handy so you don't need to make them every time. Also don't be intimidated by making subvi's in vi's. If you don't you'll run out of "room" before you get anywhere close to where you are finishing.

[NIquist]

For a simple answer to your original question, it depends on whether your code is in a project, or just a bunch of loose VIs.  Either way, I use the Save As... Duplicate option.  For the loose VI situation use Save As... Duplicate Hierarchy to new location and it will copy every required VI and subVI to a new folder.  Save As... Duplicate .lvproj file and contents does the same for projects.

You will end up with a folder that mimics the original file structure, but you can just move all the VIs up to the top and make a new file structure that suits you better.  Of course, using a project with virtual folders is the best choice.

This has always worked for me although there may be even better methods these days.  Keep in mind that this will NOT save things that come with LabVIEW like VIs in vi.lib.  Those should be available in your LabVIEW installed in the other PC you will be using.  If the original code uses external tools from VIPM, etc.  I would install them in the new LabVIEW PC using VIPM.

[FlybyWire]

So we end up just copying that massive containing folder for the whole program over to a drive.  I can now view it in all its over complexity...think there's at least 30sub VIs in this thing and the main is so big you cant see the whole program with out scrolling miles...figured out ho to zoom out using ctrl mouse wheel and with it all the way out still doesn't fit on screen .  Thanks everyone for the help