Source distribution overwrite vi

Hi!
I'm making a source distribution for my dynamically called VI's. These VIs operates on classes. I would like make one Distribution, that contains all called vis. My problem is, I've serveral overwrite class methods, with equal names as well. But when I make a preview, the distribution separates these vis, because they have similar names.
What is the common trick or solution for this problem?
Thanks in advance!
+++ In God we believe, in Trance we Trust +++
[Hungary]
Solved!
Go to Solution.

Hi Durnek,
1) dynamically loaded classes has to be added to always included section of build specification.
Add the classes as “Always Included” in the Source Files page of the Executable Properties dialog box
Place those classes into a directory next to the executable so that the relative path is still accurate. Follow these steps migrate the files along with the executable:
Create new destination folders in the Destinations page of the Executable Properties dialog. These destination folders must have the same relative path to the executable as the source class did to the top-level VI.
Navigate to the Source File Settings page of the Executable Properties dialog.
Browse through the Project Files tree and modify the Destination settings so that each file is migrated to the appropriate destination directory.
Another solution is to add unused object anywhere to block diagram. Application builder will find the class then.
2) In the Additional Exclusions page of the Executable Properties dialog, remove the checkmark from the Modify project library file after removing unused members checkbox.
3) VIs with the same name inside executable are supported from LV 2009+, so the new layout has to be selected. Otherwise you will have to create separate llb or folder for each class.
If you want to discuss more I would need to see your structure of the files. So you can either upload it in the forum or send it [email protected] You can put my name into subject.
Regards,
Jiri Keprt
NI EE Czech Republic
Certified LabVIEW Architect & Certified TestStand Architect

Similar Messages

Error 7 occurred while building source distribution in labview 8

I can build exe file and installer for my project. But while trying to build source distribution i got an error. Error description is as follows:
Error 7 occurred at ABAPI Dist Report Read Link Info Error.vi -> ABAPI Dist Cmp Settings to Disk Hier.vi -> ABAPI Get Settings From File.vi -> SDBEP_Invoke_Build_Engine.vi -> SDBUIP_Build_Invoke.vi -> SDBUIP_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux.

Hi Andy,
FYI, initially part of this project was developed in LabVIEW 7.1 and now I have
converted all the project files to LabVIEW 8.0. This was done by mass compiling and
saving all the VIs.
It is possible for me to build source distribution for some other programs. But I got the error while building source distribution for my current project. Same error was generated even while previewing the source distribution. This project contains some dynamic VIs. I had included them under the dynamic VIs and support files while creating EXE file. While building source distribution, i got an error message saying that :
"Unable to generate preview. An included VI or one of its dependencies does not exist. Open all Startup/Exported/Dynamically called VIs, recompile them (Ctrl-Shift Click the run arrow), and save them to update their dependencies.
\\Source code\Controls\Tests\Battery Current Calibration\Battery Current Calibration1.ctl
<Call Chain>Error 7 occurred at ABAPI Dist Report Read Link Info Error.vi -> ABAPI Dist Cmp Settings to Disk Hier.vi -> ABAPI Get Settings From File.vi -> SDBEP_Invoke_Build_Engine_Preview.vi -> SDBUIP_Build_Rule_Editor.vi -> SDBUIP_Item_OnDoProperties.vi -> SDBUIP_Item_OnDoProperties.vi.ProxyCaller
Possible reason(s):
LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS, and / on Linux."
For this error I rename the control, relink it in the code, and save the VI. Now I got an error message indicating different control. I was totally confused by this behaviour. What is the problem? Why the problem occured? What procedure to follow to avoid these kind of errors in future? I would be thankful, if I can get answers for my questions.
Thanks in advance.
Ramasamy.

Getting error in building source distribution

While building source distribution, I am getting an error
Error copying files.
Source: ..\Program Files\National Instruments\LabVIEW 8.6\resource\visarc
Destination: D:\Chirag\builds\Arduino LLB\Arduino LLB\data\data\visarc
Librarian Path Location.vi
Error 1 occurred at AB_Destination.lvclass:Copy_File.vi -> AB_Source.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.
can someone please help me with this ??

Do you have multiple job servers in your environment? Did all the Job servers configured SMTP settings?

Error building source distribution of a project containing real-time utility VIs

I'm using Labview 8.0.
When building the source distribution of a project I get the following message:
An error occurred while building the following file:
C:\Program Files\National Instruments\LabVIEW 8.0\vi.lib\real-time\rtutility.llb\FPC pad/strip string to size.vi
I'm using "RT reboot controller.vi" and "RT ping controllers.vi" in the project.
Anyone can tell me how to solve the problem?
Is it correct that the filename of a VI contains the character "/"? (FPC pad/strip string to size.vi)

Hi!
You fall in a LabView library error..sorry.
As you have imagined the problem is the slash in the filename and to solve you have to remove it. Go to ..\National Instruments\LabVIEW 8.0\vi.lib\real-time\rtutility.llb and rename the file.
Let me know if this solve.
Ciao
Clara
AE Manager
NI Italy

Error 6 during Build Specification of My Source Distribution in Project explorer

While trying to convert a LV 8.0 application into a project file I get an Error 6. Message as Follows:
Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 6 occurred at ABAPI Dist Chg and Save VIs.vi -> ABAPI Dist Build LLB Image.vi -> ABAPI Copy Files and Apply Settings.vi -> SDBEP_Invoke_Build_Engine.vi -> SDBUIP_Build_Invoke.vi -> SDBUIP_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: Generic file I/O error.
NI-488: I/O operation aborted.
The error referenced a vi from a third-party labview driver for Iotech hardware.
Could the path be too long?

JT1958,
These types of errors are a bit tricky to diagnose. I would try the following, in order of easiness:
1) Mass compile your project by doing a <Ctrl-Shift-Run> on your top level VI to make sure your project is linked correctly. Sometimes if there is a bad VI reference somewhere you can have these types of problems.
2) The path being to long most likely isn't the issue, but if you suspect the IOTech driver, you may try taking it out of your code and see if that allows you to build a source distribution. If that works, try creating a simple project that contains VIs from the driver and see if you can get it to build. The point is to narrow down what specifically is causing the build to fail.
3) You can try to build this in LabVIEW 8.2 as some improvements to the source distribution builder were made.
Doug M
Applications Engineer
National Instruments
For those unfamiliar with NBC's The Office, my icon is NOT a picture of me

Error 1 occurred while building source distribution in labview 8.2.1

I can build exe file and installer for my project. But while trying to build source distribution on RT i got an error. Error description is as follows:
Error -1 occurred at Invoke Node in SDBUIP_Build_Invoke.vi->SDBUIP_Build_Rule_Editor.vi->SDBUIP_CreateNewWizard_Invoke.vi->SDBUIP_CreateNewWizard_Invoke.vi.ProxyCaller
When i click generate preview, i got an error.
Unable to generate preview. Invoke Node in ABAPI Dist read linkages.vi->ABAPI Dist Cmp Settings to Disk Hier.vi->ABAPI Get Settings From File2.vi->SDBEP_Invoke_Build_Engine_Preview.vi->SDBUIP_Build_Rule_Editor.vi->SDBUIP_Item_OnDoProperties.vi->SDBUIP_Item_OnDoProperties.vi.ProxyCaller
Thanks in advance.
Poolsak T.
Attachments:
rt_deploy2.zip ‏34 KB

Hi,
I would first try mass compiling the vi's within your project to ensure there aren't any unresolved conflicts. Moreover, it's intersting that you can create an application without problems but upon building a distribution, things go awry.
Do the vi's run on the RT target without error? Does the application run on the target without error? Or do they run on your host just fine and its when you attempt to deploy on to your RT target that this error occurs?
Let's see where this gets us.
Cheers,
Emilie K | National Instruments

Error Building Source Distribution

Hello group,
I'm trying to build a Source Distribution in LV8.6.
The application is used to drive a LV USB NI-8451 SPI adapter (among other things), so I have installed the SPI drivers in the default folder "C:\Progran Files\National Instruments\Labview 8.6\resource\objmgr\"
The source files for the project are located on our company's network drive, mapped as "S:\Machine_Plant-Eng\".
But when I try to build the source distribution, it is looking for the files to drive the SPI at "S:\Machine_Plant-Eng\ Progran Files\National Instruments\Labview 8.6\resource\objmgr\"
I don't know how to repoint the Project so it finds the correct files in the correct places.
Thanks,
Mike

check the "installer source location" under "additional Installers" in the "installer properites" and browse to cate the "S:\" drive (the complete path)
Regards
Guru (CLA)

LV 2009 Source Distribution with Broken VIs

It looks like LV 2009 has made another "improvement" to an edge case that has caught us off-guard. This is admittedly not a huge issue for us to deal with, but I thought it might be worth getting some more feedback and seeing if anyone else has comments as to whether this change is for the better or not.
   We have a plug-in architecture in which we compile a main program, then use a Source Distribution to create directories of plug-in modules that the main program calls dynamically. We can send out updated or new plug-ins this way without having to recompile or redistribute the main program.
   For each module, I have a "List" VI, similar to a driver "Tree" VI in NI drivers. It contains all the top-level VIs that that module uses. Many are called dynamically, so by loading this List VI into memory, you can be sure that all parts of the module are in memory. It also simplifies the build script, since if you include the List in the Source Distribution, it automatically includes all the top-level and dynamically called VIs you need in the distribution.
   The List VI is not executable. I add a broken wire on purpose, since this VI is not meant to be run. In addition, if any of the VI's on the diagram have "Required" inputs, that breaks the List VI.
    In LV 8.6 and before, we could build a source distribution with this broken VI. In LV 2009, the source distribution build fails with a message about not being able to save a file. If we "fix" the List VI, it works.
   So it appears that in LV 2009, NI "fixed" the source distribution to only work with executable VIs. It's not too hard for us to accomodate this, by fixing our List VIs. But I wonder if there aren't other edge cases where this "fix" is not such ideal behavior. Might you not want to be able to make a source distribution of source code that isn't finished and hence isn't executable?
   (Oh - another subtlety that may be relevant - we remove the diagram as a security measure. Maybe you can't remove the diagram from a broken VI? Though it did seem to work in 8.6...)
DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Sorry - false alarm. The difference did turn out to be that I had checked "Remove Diagram" for the broken VI, not just for the good VIs. You apparently can't remove the diagram from a broken VI since it can't compile it. In our 8.6 distributions, we didn't check that box for the broken VI. In 2009, I was checking that box for all VIs.
DaveT
David Thomson Original Code Consulting
www.originalcode.com
National Instruments Alliance Program Member
Certified LabVIEW Architect
There are 10 kinds of people: those who understand binary, and those who don't.

Source distribution with FPGA support

I am trying to deploy a series of VIs which interact with FPGAs (PXIe-7966 based). When I run my RT vi's in development mode, the automatic deployment includes many vis such as:
Deploying niLvFpgaWhatHappensToTopLevelVI.ctl(already deployed)
Deploying niFpgaNodeNameForErrorReporting.ctl(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying nirviWhatTheDeviceIsDoing.ctl(already deployed)
Deploying niFpgaHostInterfaceSession.ctl(already deployed)
Deploying nirio_resource_hc.ctl(already deployed)
Deploying nirio_resource_hc.ctl(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying niLvFpgaErrorClusterFromErrorCode.vi(already deployed)
Deploying nirviErrorClusterFromErrorCode.vi(already deployed)
Deploying niFpgaNodeNameForErrorReporting.ctl(already deployed)
Deploying niLvFpgaWhatHappensToTopLevelVI.ctl(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying niLvFpgaErrorClusterFromErrorCode.vi(already deployed)
Deploying nirviErrorClusterFromErrorCode.vi(already deployed)
Deploying niFpgaNodeNameForErrorReporting.ctl(already deployed)
Deploying niLvFpgaAdjustHostInterfaceError.vi(already deployed)
Deploying niLvFpgaWhatHappensToTopLevelVI.ctl(already deployed)
Deploying niLvFpgaAdjustHostInterfaceError.vi(already deployed)
Deploying niLvFpgaFormatErrorSource.vi(already deployed)
Deploying niLvFpgaAdjustHostInterfaceError.vi(already deployed)
Deploying niFpgaDynamicAddResources.vi(already deployed)
Deploying niLvFpga_Close_Dynamic.vi(already deployed)
Deploying niLvFpga_Open_PXIe-7966R.vi(already deployed)
None of these show as dependencies though on the RT target project. When I try to create a source distribution, I can't seem to get these deployed. My VIs (When called by reference or invoke) thus fail to start (Error 1003). I'm assuming it's because the source distribution didn't include the above items.
How then can I include the FPGA and RIO vi's in the source distribution? Including vi.lib, instr, and user (From the source distribution properties) doesn't appear to pull in any of these. Including NiFpgaLv.dll doesn't seem to help either. There's no other source distribution options that seem to address FPGA or RIO inclusion.
Thanks,
Robert

Hi Robert,
After doing a bit of research, it looks like this exact issue - down to the 1003 error code and behavior with vi.lib - was reported earlier this year. Apparently it only occurs on Pharlap OS (which corresponds to your PXI RT target). R&D has been notified, and the current target version for fix is LV 2015. The listed workaround is simply to FTP the files to the RT target as you are doing. Let us know if you have any further questions!
Regards,
David R
Applications Engineer
National Instruments

Source distribution of an llb

Hi,
I have a folder with llb's. I need to source distribute the folder in such a way that the llb structure should be maintained and the dependencies should come parallel to llb.
When I try to source distribute, all llb's are considered as folders and the VI's in the llb and its dependencies are source distributrd to a single folder.
Is a best way to source distribute an llb so that I will have the same llb structure?
Thanks,
Suresh

Suresh,
to be honest, since an LLB is already a source distribution, i don't get the point.
I assume that you want to duplicate a certain set of depending llbs and copy it over to another PC. If that is correct, simply create an Installer and make sure, that each llb is copied to the correct location. No Source Distribution needed here.
hope this helps,
Norbert
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.

Can not create source distribution from project

Visit the Request Support page at ni.com/ask to learn more about resolving this problem. Use the following information as a reference:
Error 1 occurred at AB_Destination.lvclass:Copy_File.vi -> AB_Source.lvclass:Copy_SourceItem.vi -> AB_Build.lvclass:Copy_Files.vi -> AB_Build.lvclass:Build.vi -> AB_Engine_Build.vi -> AB_Build_Invoke.vi -> AB_Build_Invoke.vi.ProxyCaller
Possible reason(s):
LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller in Charge.

Hi JoshSat,
This error message can be confusing. Error code 1 is defined by both LabVIEW and GPIB and has a different meaning based on what software component gave the error. Since you receive the error when building a source distribution, it is most likely the LabVIEW error and not the GPIB error.
First, we will need to know more about your application – what it's doing, the version of LabVIEW, the OS version, use of GPIB, use of Shared Variables, etc. This KnowledgeBase may also provide some insight into the cause of this issue.
You might want to start out building a much smaller source distribution that can reproduce the same problem. You’re welcome to post that project after you've shrunk it down as much as possible, and I can try to build it over here.
Please let me know if you can provide any additional information on your program, and whether the suggestions provided above fix the problem.
Message Edited by lion-o on 01-10-2008 10:58 AM
Mike Lyons
National Instruments
http://www.ni.com/devzone

A source distribution created in 32-bit LabView 2009 says that VIs aren't executable when opened in 64-bit LabView 2009. How do I run the main VIs?

A source distribution was made for a VI using 32-bit LabView 2009. The distribution was verified to work on another machine that ran 32-bit LabView 2009. However, when opened on a 64-bit LabView 2009, the VI was broken as indicated by the attached error message. How do I make the VI executable?
Solved!
Go to Solution.
Attachments:
source dist error.JPG ‏70 KB

Seems you have a problem with the installation of the Advanced Analysis Library (AAL) or the Intel Math Kernel Library that is used by the AAL on that 64 bit machine. Can't say for sure if these are already supported on 64 bit LabVIEW. At least a repair installation of LabVIEW seems to be in place.
The other error is from the HSD component not working. Again I can't say if this should even work on 64 bit LabVIEW. If it should a repair installation should be most probably done.
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

How to get a copy of stagecraft (flash lite 3.1) source distribution

Hi everyone,
I am a PhD student doing embedded system development. As the flash lite for digital home is pretty attractive to me, I am wondering how to get a copy of stagecraft (flash lite 3.1) source distribution. I cannot find download link anywhere. Does it require a license or is it free? Can anybody tell me how to get a copy of that. Your help will be highly appreciated.
Seamus

Adobe usually license to OEMs or operators on a per-unit royalty basis for each device. Not for small clients or individuals. You can get commercial-grade flash player source code from Zeeis, many embedded devices vendor use Zeeis Embedded Flash Layer to play SWF files.

Bug: Polymorphic vi icon removed during source distribution

I haven't been able to find this issue listed anywhere, but it may already be noted internally.
I found that when building a source distribution that contained polymophic vi's that the built poly's icon would be messed up.
It would have the "?" icon, but the vi was there and so was the icon image information. If I opened the built poly and opened the icon editor the image would be there. I could then accept and save changes.
The fix ended up being making sure that none of the pixals in the origianl poly icons were transparent. If I did this then the source distribution works correctly (polys have icons).
This is using LabVIEW 2012 SP1 F1 32-bit on Win7.

Sorry it too so long to reply. A smaller build did not exibit the behavior. I am zipping up my entire project and will private message you the dropbox link.
It could have something to do with the VI's originally being from 2011 then converted to 2012 (some were probably even created in 2010 originally).
Here is an image of one of the type defs in the project.

LabVIEW 2013: Source distribution, destination path for post build VI changed?

Hi,
In a source distribution for an embedded target (Real-Time for instance) you specify both "Local destination directory" and "Target destination directory". Let's say the local directory is "C:\MyProject\MyModules\", and the target directory is "C:\" for instance. Then on my build machine my source distribution will end up in "C:\MyProject\MyModules\c\<source distrib files>", and I can then FTP everything from <source distrib files> to the root of my target's c-drive (or in some cases I can just deploy directly after the build, and LabVIEW will move the files to the target for me).
You can also specify a Post Build VI that can do stuff to your source distribution after the build has completed. Such a Post Build VI has an input named "Destination Path" for use inside your Post Build VI, so you can find your files to operate on :-)
In LabVIEW versions prior to 2013 this destination path would be "C:\MyProject\MyModules\c\", but in LabVIEW 2013 the destination path is only "C:\MyProject\MyModules\" thus missing the target destination directory part. Now my Post Build VI can no longer find my source distribution files, unless I inside that VI hardcode the target destination directory - and that isn't a good solution.
Is this changed by design in LabVIEW 2013, or is it a bug?
Cheers,
Steen
CLA, CTA, CLED & LabVIEW Champion

I don't do a lot of (actually any) source distributions of embedded files, but I can tell you that there was a bug in earlier versions where during an application build, the destination path was reported incorrectly. Perhaps this is related.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Source distribution overwrite vi

Similar Messages

Maybe you are looking for