LabVIEW
compiling issue
For LabVIEW 7.1 and earlier, the easiest way is to save the application
into a library (.llb) file. This will collect all the VIs used into a
single file that can be easily moved to another machine.
From the File menu, select Save With Options.. and select the "Development Distribution" on the left of the dialog. You should be OK leaving the other settings at thier defualt. Hit Save and you'll be prompted for a path and name. Note that you should really only use a .llb file for transporting applicaiton between machines. Using them during develpoment can be dangerous because if a single VI in the library gets corrupted or it it's not written correctly into the library, it can render all the VIs in the library useless. Just a word of warning.
In LabVIEW 8, you can use the Project Explorer and create a Source Distribution build specification that will save everything, and can even optionally zip it so it can be easily transported.
Does that do what you need?
Ed
From the File menu, select Save With Options.. and select the "Development Distribution" on the left of the dialog. You should be OK leaving the other settings at thier defualt. Hit Save and you'll be prompted for a path and name. Note that you should really only use a .llb file for transporting applicaiton between machines. Using them during develpoment can be dangerous because if a single VI in the library gets corrupted or it it's not written correctly into the library, it can render all the VIs in the library useless. Just a word of warning.
In LabVIEW 8, you can use the Project Explorer and create a Source Distribution build specification that will save everything, and can even optionally zip it so it can be easily transported.
Does that do what you need?
Ed
Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences.
You can work from a libary just as you can from separate VIs, and 99% of time, you'll be OK.
The problem is that every once and while, a VI doesn't get saved correctly. If this happens to a VI that happens to be in a library, all of the VIs in the library will most likely be unreadable. If that happens, you've lost all your work and will have to start over. (I've heard the NI does have a tool that can fix some corrupted libraries) That's why I don't recommend using them while you are developing. Keep them as separate VIs until you need to move them. It's just safer.
A little background on libraries. They were originally intrduced so you could VIs with names that were longer than teh MS-DOS 8.3 naming convention. By putting the VIs inside a library package, you could have longer names. This also helped with the cross platform capabilities of LabVIEW since MACs could have long file names when MS_DOS and Windows 3.1 were stuck with the 8.3 format. Now that all major OS's support lnoger file names, the libraries are not really needed. But they are still useful for transporting source code.
Ed
The problem is that every once and while, a VI doesn't get saved correctly. If this happens to a VI that happens to be in a library, all of the VIs in the library will most likely be unreadable. If that happens, you've lost all your work and will have to start over. (I've heard the NI does have a tool that can fix some corrupted libraries) That's why I don't recommend using them while you are developing. Keep them as separate VIs until you need to move them. It's just safer.
A little background on libraries. They were originally intrduced so you could VIs with names that were longer than teh MS-DOS 8.3 naming convention. By putting the VIs inside a library package, you could have longer names. This also helped with the cross platform capabilities of LabVIEW since MACs could have long file names when MS_DOS and Windows 3.1 were stuck with the 8.3 format. Now that all major OS's support lnoger file names, the libraries are not really needed. But they are still useful for transporting source code.
Ed
