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.

Tags: NI Software

Similar Questions

  • 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

  • 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.

  • 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


  • 'Clone' of the project library (.lvlib)

    We have a study on sound localization - move us a speaker with a robotic arm, play sound through the speaker, ask our subjects to point a laser where they perceive the location of the sound and press a button.  We can also turn on LEDs and lasers, adjust sync settings, even to move the sound source.  The various tests are "programmed" by entries into an Excel workbook with columns for the timing, healthy situation, sound settings, etc.  In addition to the Excel workbook, we generate 3 output files - a header file XML that describes the configuration of the recording (analog and digital channel names and scales) and saves the settings of each trial as it is executed, an XML event which records all of the events of "point-in-time", such as Messages, status changes, or modifies the digital I/o, and a file of examples that contains N (usually 16) sampled analog and digital channels sampled at 1 kHz.  We control all of this a LabVIEW Real-time project, which also includes routines to study, manipulate and analyze data of output files.

    The project evolves (slowly) - we are currently at Version 2.0 (Version 1.x was developed in LabVIEW 7.0, this is the complete rewrite 2012/2014, "start from scratch and do it right, or at least better").  We are contemplating adding the ability to study the sounds delivered via stereo headphones (vary the volume from left to right or by adding a small time gap between channels) and calls this Version 2.1.

    To try and prevent "Version hell", we intend to do "backward compatibility" Versions - we will Add some new columns to the workbook Excel for new parameters in headphones, but put in place LabVIEW code to simply "do nothing" (with headphones) if he reads a Version 2.0 workbook where these parameters are lacking.  This allows us to code of Version 2.1 allows to make a Version 2.0 experience.

    We are faced with one of the problems are to know how read and analyze or manipulate data files resulting.  For example, the header file contains specific sets the version of the data, which are analyzed by the XML parser and converted directly into a Cluster of LabVIEW.  Thus a Version 2.0 file must be read by the code who "knows" a Cluster of Trial Version 2.0, whereas a 2.1 file needs a trial 2.1 Cluster.

    When I read the header file, the first thing I encounter is the Version number (2.0 or 2.1).  Knowing this, I could, in principle, use a Case statement to call a Version 2.0 or Version 2.1 analysis routine.  But I am trying to 'avoid a mess', and libraries in the project seems a good way to do so, if I understand how to use them properly.

    [For now, I have to say that I tried a little experiment: I have created a new project, built Library1 in a folder with a 'Hello' and 'Test' Library1, built the library 2 (inside the folder library 2) with 'Hello' and 'Test' (different) and called the high-level.]  Worked well.  I then "took a shortcut" and copied the folder Library1 (outside of LabVIEW) on the menaces3.  When I said that the project to add 3 library, I had a mess of conflicts, which I couldn't resolve.  And I "broke" LabVIEW - even after removing all the .lvlib and the .lvproj files, I couldn't create a project and make a folder to add (Snapshot) without a missing file error to appear.  I did the experiment using LabVIEW 2012 - this problem has affected not only LabVIEW 2012, but also 2013 LabVIEW and LabVIEW 2014, but not LabVIEW 2011.  I spoke with the support of OR, which are also puzzled.  I am currently working in a new virtual machine until I can get LabVIEW "repaired"].

    What I want to do is identify all Version-specific routines in my folder of analysis and include data in this case TypeDefs for the Version-specific parts.  I would then "wrap" all this in a project library Version 2.0.  The code "on the outside" would have its own copy of TypeDefs (she could use the "Latest Version", as external routines are supposed to be 'backward compatibility'.

    So here are my questions.

    1. Suppose that I restructured my project so that I have a record, both "Real" and "Virtual" (in the project) parsing, and it contains a subfolder called Version 2.0 that contains the Version-specific TypeDefs and most of parsing code.  Is there an easy way to transform the Version 2.0 to Version 2.0 Library folder so that when I call functions in this library, they use Version 2.0 of the TypeDefs of the library, regardless of the TypeDefs declared in the main routine?

  • Assuming that I have a folder of Version 2.0 of work and the library, is there an easy way to "clone" to make a folder of Version 2.1 and the library?  If so, all I would need to do the "work" for Version 2.1 of the code would replace TypeDefs of Version 2.0 in the file of Version 2.1 with the "correct" TypeDefs, and (b) add any additional analysis code is required for the new features in the new Version.
  • I apologize for the long-winded nature of this issue.  I look for tutorials on libraries of the project (there are), but none covered this topic.  To pay for your patience, I am happy to write and submit to the OR for a future white paper on libraries of the project - which would speak?

    Bob Schor

    PS - Moderator - if it belongs to another Forum, feel free to move it.

    On the money Bob!  Save under... Duplicate the hierarchy to the new location (requires that the new library offers a new name)

    To convert a virtual folder to a lvlib just to create a new lvlib in the project and move the project members want in the new lvlib Project Explorer does the rest of the book nitty gritty on registration of the members of the lvlib with the new property information.  (You will be prompted to save the members when the composition is changed)

    And Yes, it's the kind of mistake you don't do twice.  And, believe it or not, I had this type of issue used to justify not using projects! "they are too much hassle when you mud round in windows Explorer ' then I asked them if the never borrowed the car of their father and did not him tell you parked above on the next Street.  They now use projects.

  • How to access a global variable that is common between the different baskets project library

    My project consist of several libraries, after generation the library project packed for each library, I find it cannot share data in a global variable between different packaged project library file. For example: packed project library #1 contains VI variables global wirte 'position' and give it a value '400 '. Library #2 present another VI project try to read this global variable, but he gave reading of is NULL not "400". Why has this happened? Is it possible to solve, welcome any help, I wll appreciate for this!

    If you understand what is happening here...

    When you build a PPL, it takes in the .lvlib and also all the dependencies of the .lvlib.

    In your case, when you generate the Test Task.lvlib in a .lvlibp, she also pulls on a copy of the DataProcess.lvlib:GlobalsVariable.vi because it's addictive to read GlobalVar.vi.

    When your application runs, you end up with two copies of GlobalsVariable.vi in memory:

    DataProcess.lvlibp:GlobalsVariable.vi

    AND

    Test Task.lvlibp:: GlobalsVariable.vi (I don't know how PPLs namespace dependencies... If there is still the DataProcess.lvlibp)

    Because they are different screws (i.e. in a different namespace), they have their own memory and that's why you can't access the data.

    Your Test Task.lvlibp calls the version of GlobalsVariable.vi, he pulled the dependencies.

    To solve this problem - you must ensure that Task.lvlibp of Test calls the version of GlobalsVariable.vi of the DataProcess.lvlibp - you'll need to replace all instances with the version of the PPL. Of course, if you run DataProcess in the development environment, then it will always be bad namespaced, hence the suggestion to put your global variable VI in is own PPL that you then use in the process of data and Test tasks.

  • 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.

  • 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

  • Save all source files in a project of earlier version?

    What is the quickest way to save all source files in a project from an earlier version?

    I know that I can do with individual files, but is there a way to do everything at once?

    Of course, just do the same thing, you save the screws for the previous version. In the Project Explorer window, select file-> except for the previous Version...

  • 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,

  • My images from various sources are fine in the library, but when I do develop they are converted into negative.

    My images from various sources are fine in the library, but when I do develop they are converted into negative.

    Go to Preferences, click the performance tab, and then clear the check box

  • Hard Drive Setup for the source files, media Cache, project, Render, etc...

    I am working to put in place the following readers:

    C: SSD for the OS and programs

    D: RAID 0 (three SATA II F3) for projects from first, where I did too, and still

    E: RAID 0 (two SATA III WD black Caviar) for the source files, hiding from media and preview the files (if I can get the controllers/SATA III RAID Marvel that is)

    External HD USB 3.0 for backup projects

    Should I make this different?

    Anyone think it would be better to use the SDD discs instead of hard drives? I have

    Please confirm that it is correct:

    C: SSD for:

    • Operating system and programs
    • No pagefile

    D: RAID 0 (three SATA II F3) for:

    • No pagefile
    • First project
    • Source files of project first (suggestion by evil)
    • Project yet

    E: RAID 0 (two SATA III WD black Caviar) for:

    • Swap file (install first, 12 GB since I have 24GO RAM)
    • Media cache
    • Preview files
    • Rendering of the project (e.g., DVD MPEG2, H.264, etc.) / source files of project yet

    Fix.

    When I finish my PR projects, I use DVD - HQ Bitrate & GOP calculator to determine the parameters of flow and export to DVD MPEG2 or H.264 - BR according to my delivery format, but also because I always export sound instead of AC3 5.1 2.0. I only make my chapter points in Encore and not worth trying it in the PR, due to the limitations of long GOP. Again these same limitations, but I prefer to do it in yet, because then I can easily adapt and make the poster frames for my taste.

    In my workflow, so I have my source media and the project on the D drive and export the MPEG2-DVD, or H.264 - BR in drive E. open the project again from my D drive, and then import the assets on my E drive.

    Reminder I export the image file and then use Nero to make multiple copies, because with Nero I can use multiple burners, creating 50 copies goes two times faster with two burners or even 4 times faster with four burners.

  • Get the dependencies of VI in a packaged project library

    I'm building a test sequencer which uses packaged libraries to the project. I want to be able to get the path to a VI that is part of the packed but not explicitly part of the lvlib the PPL has been built since. If I'm trying to get dependencies VI library or any VI in the library by using the method of getting the dead VI, I get only the dependencies that are explicitly part of the lvlib, even though I see clearly that there are screws that are part of the packed library, I can open them , and I can view the code.

    Background:

    My test of libraries have an entrance variant on which I set a global variable used byt the sequencer of test. While the tests can have access to these global variables, I want to decompress values of type variant and write them on local copy (namespaced) of the test of the global step. This function works, but to use it, I need the way access to the copy of the lvlibp global. I tried wiring, the name of VI, because I know it's in memory, but it returns an error. I also tried wiring the VI name prefixed by the name of the lblibp, following the format used in the title bar of the global open in the packed library.

    I do not want to include the global in the library explicitly, because it will be used by other libraries. I could deploy the global library packed own ots, but I wanted to see if I could make this work, a s it seem elegant and transparent for the other people in my group try to use (just use this world!) and it requires less files to deploy.

    In addition to experimentation, I found that you can open a reference to any VI in a packed using the string library name:

  • Eclipse fails to package the project every other time I try to run BlackBerry Simulator

    I have a simple project that I've set up using the SDK 7.1 BlackBerry, it has no external dependencies.

    Almost without fail, every other time I hit him "run on BlackBerry Simulator' I get an error similar to the following:

    Packaging project BlackBerryApplication
    C:\Eclipse\plugins\net.rim.ejde.componentpack7.1.0_7.1.0.10\components\bin\rapc.exe -convertpng -quiet codename=deliverables\Standard\7.1.0\BlackBerryApplication -sourceroot=D:\Git\BlackBerry Application\BlackBerryApplication\src;D:\Git\BlackBerry Application\BlackBerryApplication\res;D:\Git\BlackBerry Application\BlackBerryApplication -import=C:\Eclipse\plugins\net.rim.ejde.componentpack7.1.0_7.1.0.10\components\lib\net_rim_api.jar deliverables\Standard\7.1.0\BlackBerryApplication.rapc D:\Git\BlackBerry Application\BlackBerryApplication\bin
    JAR file creation failed with error -1
    The preverified classes if any are in tmp28761. See jar log of errors in C:\Users\t_gibson\AppData\Local\Temp\rapc_71af6d24.dir\jarlog.txt
    Error!: Error: preverifier failed: C:\Eclipse\plugins\net.rim.ejde.componentpack7.1.0_7.1.0.10\components\bin\preverify.exe -d C:\Users\ ...
    Packaging project BlackBerryApplication failed (took 0.584 seconds)
    

    No matter if I clean up project or own Simulator I still get the same error another each compilation. Does anyone have an idea what could cause this? If I type "run on a BlackBerry Simulator" right after the error, it works fine.

    I use the 9900 with Eclipse 3.7.2 and BlackBerry 7.1.0.10 SDK Simulator. The plug-in version is 2.0.0.201207181003.

    Thank you!

    EDIT: I should clarify that when I say that the cleanup project makes no difference, what I mean is that cleaning of the project once the means it compiles OK next time, but unless he is cleaned after the first compilation, again a second time the compilation will fail. If although the project before each compilation of cleaning could cause it to compile every time, this does not solve the problem that it is there always something left in an inconsistent state after a successful compilation.

    I have determined that the source of the problem was a bad setting in the project configuration that I did when I created the project, I added wrong file the project root to the source compilation path option on folders. The error in the line of rapc.exe is highlighted below

    Packaging project BlackBerryApplication
    C:\Eclipse\plugins\net.rim.ejde.componentpack7.1.0_7.1.0.10\components\bin\rapc.exe -convertpng -quiet codename=deliverables\Standard\7.1.0\BlackBerryApplication -sourceroot=D:\Git\BlackBerry Application\BlackBerryApplication\src;D:\Git\BlackBerry Application\BlackBerryApplication\res;D:\Git\BlackBerry Application\BlackBerryApplication -import=C:\Eclipse\plugins\net.rim.ejde.componentpack7.1.0_7.1.0.10\components\lib\net_rim_api.jar deliverables\Standard\7.1.0\BlackBerryApplication.rapc D:\Git\BlackBerry Application\BlackBerryApplication\bin
    JAR file creation failed with error -1
    The preverified classes if any are in tmp28761. See jar log of errors in C:\Users\t_gibson\AppData\Local\Temp\rapc_71af6d24.dir\jarlog.txt
    Error!: Error: preverifier failed: C:\Eclipse\plugins\net.rim.ejde.componentpack7.1.0_7.1.0.10\components\bin\preverify.exe -d C:\Users\ ...
    Packaging project BlackBerryApplication failed (took 0.584 seconds)
    
  • Unlock source distribution

    So I have a bunch of configuration files that are stored in a different location from the application, so I created 2 built, one for the .exe and distribution from a single source for the configuration files. The installer works well such things as well as copies of their respective filders in an orderly manner. So far so good.

    The problem: the ini files - get administrator rights and I can not unlock in the Setup user interface. Users must be able to edit the files. Ideas?

    /Y

    Well, I created a solution, but I'm not very happy about it, I think there must be a lighter way on this subject.

    I created a vi which runs a system with a command attrib exec. It is compiled into an exe in a separate build definition. It is installed in the same location as the main user interface and in the installation program, it is defined as running after installtion.

    Is this really the best way?

    Why can't I just throw a system as part of the installation command but only compiled of vi? Why should I install the exe, why not a 'walk only with installation?

    /Y

Maybe you are looking for