Unlock source distribution

Similar Questions

• RT VI does not source distribution after reboot

  Here is a strange...

  I have a very complex application.  It runs great development environment.  It also runs great as a Starter (no GUI) rtexe.  When I build a source distribution and deploy a path of RT controller...

  VI Server invoke the method shows NO errors but the VI does not seem to be running. If I open a project, right-click on the target and click 'Connect', suddenly the invoke begins to work.  I think there must be a way to configure the settings of VI for the RT controller sur-boot server, but I don't know how it's done, or why I would not get an error before selecting the connection in a project.  Any ideas?

  Thank you

  XL600

  
  

• Source Distribution packaged vs project library

  I design my architecture for a project, and I want to use plugins for future expansion. Most of the information I found recommended the use of baskets library project for each plugin. But once in a while I find someone who is recommended to use the source distribution. I intend on creating this software to end users who do not have a development environment and who are not able to modify the code.

  So, I have a few questions.

  1. What is the difference between the source distribution and the project libraries packaged?
  
  
  2. What are the benefits of one over the other for plugins?

  Source distribution contains the source. It allows the end-user upgrade from the source of their version of LabVIEW (envinroment development only) since the source is dependent on version, and if the files are saved with the code were met, they can work in an envinroment of execution to the version of LabVIEW they were last updated in. However, the distributions of this nature seem to have several files to deploy. One of the main reasons to prefer this method is due to complications of "chaining" library dependencies of project packaed which we are stuck with until NEITHER arrives with a type of 'solution' for the control of this.

  The project packaged libraries are built (compatible execution) which do not require the environment and are generally single-file development which makes them easier to deploy. However, they are built to a specific version of LabVIEW. One of the main reasons for choosing this method is version control (files have version information) as well as ease of deployment (single file).

  At the end of the day it depends a lot on your end user in my opinion. Management of multiple files is a pain of a source distribution point but then so is chaining builds for libraries in the project packed and the problems of name-spacing inevitable that comes with it. Managing dependencies is never easy, and there is no easy fix for this solution in LabVIEW.

• How can I include all the VI that are listed in the hierarchy of VI for a source distribution

  I'll send my request to another developer. To do this, I used the source distribution function. But if I generate the files I miss the VI they are stored in the form of instrument drivers. How can I include, too?

  Walter wrote:

  I'll send my request to another developer. To do this, I used the source distribution function. But if I generate the files I miss the VI they are stored in the form of instrument drivers. How can I include, too?

  This is exactly yhe reason I'll go through and save screw driver to subfolders in my application directory. In this way, I can keep the NCC updated with a complete set of code including any mods, I do the driver (usually change of reentrancy).

  But if you don't take this approach, you will have to send you a colleague from the same packeage installing driver allowing you to put it on your machine.

  Ben

• problem of visarc in the source distribution

  I am trying to build a distribution from source to a project in LabVIEW 8.6.1.  I need to build the source distribution so that I can password protect all VI in the project (about 1200).  When I try to compile the source distribution I get the following error message.

  

  As you can see the source file does not exist because the path: C:\Documents and Settings\Program NIUninstaller Instruments... does not exist.  So, I created this path and place the visarc file where LabVIEW thinks it should be.  When I Isaiah to compile the source with the wrong path distribution I get the following error message:

  

  Once more the following path does not exist: Program Files: \Nationa lnstruments\LabVIEW 8.6...

  I don't know how to create this way false because he seems to treat the program as its own hard drive files.

  The next thing I did was reinstall DAQmx 8.9 as the name of the file is visarc, I don't know that it is connected to DAQmx but the visarc makes me think it might be.  DAQmx reinstalling does not fix this error.

  I should also add that I was able to build a very good three weeks ago source distribution.  During the last three weeks the code was treated by myself and two other developers.  I had seen problems with other developers link dll from their office of vi in the library, and when I pulled it back on my machine, I have been unable to build a source distribution, because their DLLs have been at a different path.  I solved this problem of rebind each Subvi to the dll in the correct path.  Could be a similar problem where one of the other developers visarc stored in C:\Documents and Settins\Program files... and I just need to recreate a link to the visarc file?  I don't think so because I don't think "recreate a link to the visarc file" is since then.  I'm open to any feedback.

  Thank you!

  Here is a solution provided by an EA:

  Hi Jon,

  The following information should help you to resolve the error you see

  LabVIEW VIs point to the rc files that are not in the vi.lib.  This means if you move the VI on disk (upward in a folder, in a folder, another drive), then the path that he stored in the rc (relative path) is no longer correct.  The application builder will recognize that the rc file will have two different routes (the one which is correct and which is not).
  Once two different paths are recognized source distributions will not be built successfully.  To correct this problem, follow these steps:
  1. If you have any previous version of LabVIEW installed temporarily
  Rename the folders of their resources.  Directories of resources can be in the labview\resource directory.
  2. Add massCompAll = True in the file LabVIEW.ini version of LabVIEW
  used.  The file is located in labview\LabVIEW.ini.  LabVIEW must be closed when you change the LabVIEW.ini file.
  3. launch LabVIEW, mass compile the project, and then try the build.
  4. exit LabVIEW and difficulty of any renamed resource records again to their
  original name.
  5. remove the massCompAll = True token in the LabVIEW.ini file once the
  compilation of mass is over.
  Note: Rename files from older versions of LabVIEW resources is critical because the token defined otherwise has a chance to cause the vi.lib of the different versions of LabVIEW to be reticulated

  Meghan
  Technical sales engineer
  National Instruments

• Is it possible to include the file lvprog in a source distribution build specification

  It seems to me that a full source distribution includes the associated project files but I don't see that it is possible to do. I missing something or do I just have to continue to, outside of LabVIEW, high zip folder that contains everything?

  I think you are talking about the *.lvproj (not *.lvprog).

  No, it is not possible. I think it was possible in the past (LV2009 and earlier versions) and I already complained that elsewhere long ago.

• Error source distribution building

  I get an error when building saying source distribution:

  «LabVIEW can not find a file that is a dependency of a startup, exported or always included VI.»

  File not found: the file "C:\Program Files (x 86) \National 2011\vi.lib\utf\common\conversion\utf_string_to_tag.vi" must have the qualified name of "NI_UnitTestFramework.lvlib:utf_string_to_tag.vi", but it has the qualified name of "utf_string_to_tag.vi".

  The missing file can be referenced by one of the libraries included in the compilation or the file - OpenData.vi. To resolve this problem:

  -Open all the startups, exported or always included live, recompile them (CTRL-SHIFT click the Run arrow) and keep them to update their dependencies.
  -Open libraries included in the building and check the existence and the location of the referenced files. Also, try to build with the option of additional exclusion, 'Delete unused library of the project members', verified. »

  Any ideas why this happens?

  I don't know what was wrong but I restarted Labview and it worked.

• error generating a source distribution

  I get the following error when generating a source distribution in LabView 8.6:

  Error 1 has occurred to AB_Destination.lvclass:Copy_File.vi-> AB_Source.lvclass:Copy_SourceItem.vi-> AB_Build.lvclass:Copy_Files.vi-> AB_Build.lvclass:Build.vi-> AB_Build.lvclass:Build_from_Wizard.vi-> AB_UI_FRAMEWORK.vi-> AB_Item_OnDoProperties.vi-> AB_Item_OnDoProperties.vi.ProxyCaller

  Hi RBFOLS,

  Thanks for the post and I hope that your well.

  Have you been movement screw around because you changed the build / did you take a few screws a another version of LabVIEW?

  I would recommend Delete the construction specifications and all files created by built so far. "" I would compile then mass the llb (screws using your) Tools "Advanced" mass compile.

  This error can be caused if you have named your executable with a character of invalid filename as a carriage return, or one of the following characters: \ /: *? " <> |. If the specified file name contains one of these characters, remove it and you should be able to build your executable without problem.

  Another point - which path names you use, make sure you the correct paths.

  If no joy, which was the full error message?

  Remember, if your component dynamically all live you must include the manually in the support screw.

  Hope this helps,

• Need some advice on the best way to do specialized source distribution

  I need to give a customer a labview block, they can use our material in their own labview code that will read the (encrypted) data net senor off the coast and the flow of data in a form usable output.  I built a vi that can be used in a loop, a bit similar to the block of canned labview data acquisition that can be used to acquire data from products OR.

  There are many sophisticated (and secret) algorithms going on in the background which make sense data and translate them into a usable data table, but also configure the hardware itself. Accordingly the only final vi I prepared to distribute the client makes use of Subvi about 20. Almost none of these subvis could be ideally be reconverted in plain code in main vi, nor what I want to do this.

  The rules of the game is the following: I want to give him the block I created to use its own code, without him to see what's happening inside the vi.  I can deny him access to the block diagram/s, no problem, but I don't want to give him access to the subvis, to use, or even to know their names - preference they would be hidden or otherwise pre-compiled. Preferably I would just give him the main block only, perhaps with some support files that would be entirely opaque to him.

  Looking for advice on the best way to go. There is an elegant solution to this problem? For example, it would be better to compile the block as a .dll file, and then write a wrapper vi any?

  Have you thought of creating a packed library? You can also password protect your code. You can delete the distributed code block diagrams. You can use a combination of the above as well.

• Automatic allocation of passwords during the construction source distribution

  
  
  

• Distribution of the source with dll error

  I am trying to build a distribution source, using LabVIEW 8.6.1.  The code calls a dll and why the dll is listed as dependencies.  When I Isaiah to compile a source distribution I get this error:

  

  Has anyone seen this before, and if yes, what is the workaround?  Thank you very much for the help.

  Good morning jmcbee,

  As says the first 'reason', an input parameter can be invalid.  Although "the Distribution Source provider creates a copy of the project (including dependencies) for easy distribution files to another machine," your .dll is one path other than that of the project and this is the error that is returned, its path can be the invalid entry to blame. (KB: what is the feature of specification of Application Builder Build?)

  Try to place a copy of this DLL in the same folder as your project and reconfigure your project and call library function nodes to get the .dll file in the new location instead of the original location.

  Another thing you can try is to remove all spaces in the name of the specification to build and ensure that no spaces at the end of the name.  Then rebuild the source distribution.

  The following links can provide some basic information:

  What is the feature of Application Builder Build specification?

  http://digital.NI.com/public.nsf/allkb/41561F98D96235FC8625708F00552ADF?OpenDocument

  Error 1 or 6 is produced during the e/s of file - input parameter is incorrect

  http://digital.NI.com/public.nsf/allkb/BB06ABD0261A9F2B86256F190049A620?OpenDocument

  Why my executable does not work when you use the constant path of the current VI?

  http://digital.NI.com/public.nsf/allkb/FD7DE8BC8FFC256C862565F4006BE363?OpenDocument

• A distribution source created in 32-bit LabView 2009, explains that the screws are not executable when opened in LabView 2009 64-bit. How do the main screw?

  A source distribution was made for a VI using LabView 2009 32 bit. The distribution has been verified to work on another machine which ran 32-bit LabView 2009. However, when opened on a 64-bit LabView 2009, the VI was broken as indicated by the error message attached. How can I make the executable VI?

  The VI used the noise and vibrations and HSDL screw that I suspect don't are not supported in 64-bit.

• Distribution of the source - unit test dependency problem

  Hello

  I developed and API and I want to make the distribution of the sources, however my faulty build (error message is below) due to the error of reclassification of the Unit Test framework that I use to test my code. All Unit Tests are in the same folder, called "UnitTests", which is a part of a class. If I delete the UnitTests from the class folder, source distribution is created as expected. I try to put the folder always excluded UnitTests, but it does not help.

  I use LV 2012.

  Any ideas what I am doing wrong?

  Thank you

  Andrej

  Error message:

  LabVIEW does not find a file that is a dependency of a startup, exported or always included VI.

  File not found: the file "C:\Program Files (x 86) \National 2012\vi.lib\utf\dialogs\utf_defocus_trees.vi" must have the qualified name of "NI_UnitTestFramework.lvlib:utf_defocus_trees.vi", but it has the qualified name of "utf_defocus_trees.vi".

  The missing file can be referenced by one of the libraries included in the compilation or the file - CircularBuffer.lvlib. To resolve this problem:

  -Open all the startups, exported or always included live, recompile them (CTRL-SHIFT click the Run arrow) and keep them to update their dependencies.
  -Open libraries included in the building and check the existence and the location of the referenced files. Also, try building with the option of additional exclusion, 'Delete unused library of the project members', verified.

  Is attached to a fixed version of utf_defocus_trees.vi.  Place it in your \LabVIEW 2012\vi.lib\utf\dialogs directory .

  In addition, you might want to load/save utf_test_properties_sub.vi to get rid of the dirty dot.  This VI is located in the: \LabVIEW 2012\resource\framework\providers\utf.

• Distribution source + Exe NIVDM.lvlib

  Hello!

  I want to create an exe and setup of my plugin application.

  One of my plug-in has a Subvi, called: IMAQ ROIProfile. I want to fix this vi on my source distribution and set this distribution to my Installer, but I can't because it is a part of NIVDM.lvlib.

  On the target computer where the engine of execution of LV and the NI Vision runtime are installed, I don't want to copy all the screws of NIVDM.lvlib in my source distribution.

  -Is it possible to separate these screws of lib?

  -Anyway I can do any problem if I attach the entire contents of NIVDM.lvlib to my Installer?

  Hi Durnek,

  Sorry for not responding for so long! Have you tried to attach the whole lvlib the installer? It shouldn't be a problem with the exception of the installer being slightly larger in size.

  Please let me know what you have tried sofar, what are the results and if you still need help!

  Best regards

  David Varga

  NIH

• Real-time application does not work; source code works very well

  The short version is I'm programming a cRIO and apparently the RT code isn't running after you deploy, and I can't understand why. It is further complicated as I do all this remote and I don't have direct access to the unit since I am 500 miles away. I work through a couple of other guys who know some LabVIEW, but neither is working on the site so that they explicitly trip there whenever I have a bright idea.

  I was there a few weeks ago. During this time, I created a code simple cRIO, since I'm new to the cRIO, allowing the user to move a control and change a chart. It worked fine, but I must stress that it did not have a FPGA component. After that, I worked on the actual code, which reads some sensors, displays the results on a user interface and stores the results. Did FPGA. I used it in the LabVIEW environment and it worked fine, but I ran out of time before I could finish a release build and deploy the RT as a compiled application. I sent them the version later, my contact deployed but had the network stream errors during execution of the user interface.

  After hours to address network problems and sending over debug versions, I tried to create a log on RT level so I could see what was going on. The journal is not yet open, even if it is the first command in the code. I have pores through the forums and found http://forums.ni.com/t5/LabVIEW/cRIO-Troubleshooting-creation-and-deployment-of-startup/td-p/1956475... which took a new direction.

  I had my contact use the RT debug console and when it pulls up to the front of the RT, it shows an arrow broken at delivery. He clicked and nothing happens - no work, no list of bugs. If he shoots to the top of the list of bugs manually, it is empty. Again, the RT works very well if you run it through LabVIEW and not as an application compiled in real-time. He also noticed that the open FPGA VI was grey on the block diagram. Are no other icons.

  If the problem seems to be that the compiled application of RT becomes some kind of error, but do not tell me what it is, and it seems to be related to the opening of the FPGA. I recompiled the FPGA and RT. I recompile the RT himself, but not the FPGA, because this would take hours. It is download everything properly for the cRIO. The RT is set to run automatically. It is restarted the cRIO whenever he deploys the RT. They have LabVIEW on a computer, but it doesn't have the correct drivers to run the code of the environment of LV. I am to resist have them install the dirvers because downloading big files is complicated due to the restrictions of security as well as a lousy connection at a remote site. In addition, it does not solve the problem of RT executable doesn't work is not the same as the source code, which, according to the thread above, seems to be a thing.

  The last thing I'm getting is that I sent her instructions for how to build a source distribution of the project that I sent and try to deploy on the cRIO. Even if it works, I'm not sure that this is an acceptable solution, because I assume running VI, rather than the EXE is slower, and they need to speed on this project.

  Simply, I don't know where to go from here. I probably need to get direct access to the cRIO and I might be able to convince them to ship to me so I can understand this point, but I don't know where I got same departure other than the Voodoo debugging standard of "trying stuff randomly until something works". I am open to suggestions, if someone managed to solve this before.

  Code snippet of the first part of the project is fixed, although I don't know how much what good it will do. I am really confused, and the customer is frustrated with how much budget is going to solve this problem.