They are simply ignored during the source code distribution creation, as they would otherwise show up in the list of files generated during the build (which I am using in the script described in the quoted thread above). Note that it is not possible to see which files of a library are included in the Source Files tab of the source code distribution properties dialog, only that said library (XXX.lvlib) is included.

I suppose a workaround would be to remove this type of files (and other non .vi(m), .ctl, etc, files) from libraries and individually mark them as always included, but that kind of defeats the purpose of using libraries to provide self-contained code and asset packages.

Is that a described feature or a missing one? 

Does anyone else have trouble downloading certain packages through VIPM?

For example, I'm unable to download SQLite Library 1.16.0 because "VIPM could not download the package ... from the remote server."

I checked the error details and was able to locate the package on the server: https://download.ni.com/#evaluation/labview/lvtn/vipm/packages/drjdpowell_lib_sqlite_labview/

I tried different versions of VIPM, including 2019 and 2025.1 (build 2772) with no avail.

Other packages do not appear to be affected. Can someone confirm?

I'm able to download the package directly from the server with no issues so the problem is with VIPM.

I'm facing challenges running a legacy LabVIEW 2012 SP1 application on Windows 11 and would appreciate guidance.

Situation:

Production system: LabVIEW 2012 SP1 program on Windows 7

Need to evaluate/extend program on Windows 11 development machine

Have .vi, .ctl, .lvlps files but no deve  I acceptlopment license

Attempted Solutions: ( I assume )

Installed LabVIEW 2012 SP1 Runtime (patch files available, but installer blocked by Windows 11 security)

Windows 11 blocks lvrunner.exe installation; only support files install

.vi files associate with NILVWSPostInstallerScript instead of LabVIEW

Newer Runtime versions (2022 Q3) blocked by company firewall

Questions:

Has anyone successfully run LabVIEW 2012 Runtime on Windows 11?

Are there workarounds for Windows 11 security blocking older NI installers?

Can LabVIEW 2022+ Runtime open 2012 .vi files in read-only mode?

Alternative viewers or methods to examine .vi structure without full LabVIEW?
----------------------------------------------------------------------------------
Any insights would be greatly appreciated.

I have a main application that's compiled into an EXE. This application loads modules during run time.

The modules are built as a source distributions, with the dependencies copied into a common folder (<main app>\support).

The application gets built without an issue, the .EXE works. Once I build a module, the main application breaks, and the reason for it is that few VIMs (and only the VIMs) get disconnected from their .lvlib.

Once I fix these, everything is ok. What can cause this issue?

Thanks.

I've read a bit about .mnu files and how they can help organize and manage the appearance of VIs in the LabVIEW palettes, but I'm not entirely sure how to use them effectively. I think using .mnu files might be the solution to my problem, but I'm stuck on how to properly implement them in my library design.

Could someone please guide me on how to create and use .mnu files to manage my library's palette structure.

Thank you in advance for your help!

"You can also purchase Application Builder separately as an add-on to use with LabVIEW Full or Base until the 2021 SP1 version. 
Please note that moving forward from LabVIEW 2022 Q3 you can only purchase LabVIEW Application Builder via LabVIEW Professional Development System."

The only way now to build applications is to install the professional version. For a relatively low intensity user as myself, this is out of the question. I have no use for the professional edition, not even full, but the application builder is useful.

Are there any other way to get around this, other third party builders, or anything?

Thanks

I'm looking to license an application that will run exclusively on offline systems. I came across the "Third Party Licensing & Activation Toolkit API" available through JKI VIPM, but from what I understand, it requires an online activation process, which wouldn't work for my use case.

Are there any other libraries or toolkits you’d recommend? I also checked out Build, License, Track from Studio Bods (link), but I’m not clear on what the free tier offers, or if it's even available.

I realize the irony of asking for a free toolkit to license an application! However, I’m not looking to profit from this. I simply want to protect an application that I need to provide to a potential industrial partner while we finalize our collaboration. Unfortunately, I have to hand over the executable, but I want to ensure the application won’t run indefinitely if the partnership doesn't go through.

Thanks,

Marco.

It's been 'many moons' ago, but I remember updating my 2018 runtime to SP1 f5, but I haven't had to build an installer in 2018 since then.

I ran into a situation yesterday where I needed to create an installer in 2018 and left "Automatically select recommended installers" checked, which auto-selects the 2018 SP1 f5 RTE. 

When I select "OK" in "Additional Installers", the "Select Source" dialog appears with a single entry, which is a 2018 application that I had built and installed on my local machine.  Clicking on "OK" prompts for a media path as expected, but I don't have (or can find) and installer for 2018 SP1 f5.  Even pointing it to the installer it's referencing (that I created) gives me an error message stating that the "...media you have provided is a different version of the requested media" (which it isn't).

I ended up giving up on creating an installer in 2018 and recompiled everything in a later version of LabVIEW since I needed to get an update deployed immediately.  However, I am curious whether anyone has any insight into this.  I can't be the only one to have seen it.

I managed to follow the instructions found here:

http://digital.ni.com/public.nsf/allkb/9538A36E218F10A4862571A8005EF6C0

Now when I double-click on my custom file (i.e. file.abc) it opens my application. From there I can use the command line interface to open the file.

This is fine when my application is closed. However, I want it to work when my application is running. My application contains an event structure. I was told that I could probably doing it by using the DDE server functions.

Would anybody be able to help me to find the relevant information?

Thanks very much.

Battler.

I am building several applications for the  the Lab I work in and would like to have one generic installer and then have the users just download run the executable. Any time we install anything our IT dept has to get involved . 

Thank you

I recently installed LabVIEW 2023Q1 and am trying to compile (create an executable of) my company's application, that we can successfully compile with LabVIEW 2019. Unfortunately, at the end of the compilation I get an "error 13" message, just like in this link:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000g34oSAA&l=en-CA

However, I don't think it applies to me, since this was supposed to be only in LabVIEW 2017, and that my "Use fast file format" is already disabled anyway.

When trying to remove/add back part of my source code, I notice I tend to have problems when I include code that have dependencies inside the new LVAddons folder (C:\Program Files\NI\LVAddons) that NI came up with in LabVIEW 2022Q3 (specifically, xnet and daqmx).

Googling specifically for building errors with LVAddons, I came across this issue reported by JKI:

https://github.com/vipm-io/vipm-desktop-issues/issues/17

Since it's related to building a package and not an executable, I'm not sure it's relevant for my situation.

What makes it hard to troubleshoot is that everything looks happy in the lvproj. All dependencies are found in LVAddons instead of C:\Program Files (x86)\National Instruments\LabVIEW 2023\vi.lib, which seems to match NI's intentions. And the error only occurs at the very end of the compilation.

Has anyone encountered this problem while building with either LV2022Q3 or LV2023Q1?

I have installed the latest versions of NI-XNET and NI-DAQx drivers (2023Q2).

The whole error message is as follows:

Error 13 occurred at Invoke Node in AB_Engine_Write_Linker_Wrapper.vi->AB_Build.lvclass:Copy_Files_Core_Old.vi->AB_Build.lvclass:Copy_Files.vi->AB_Application.lvclass:Copy_Files.vi->AB_EXE.lvclass:Copy_Files.vi->AB_Build.lvclass:Build.vi->AB_Application.lvclass:Build.vi->AB_EXE.lvclass:Build.vi->AB_Engine_Build.vi->AB_Build_Invoke.vi->AB_Build_Invoke.vi.ProxyCaller

Possible reason(s):

LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
=========================
LabVIEW: (Hex 0xD) Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
=========================
Shareable board exclusively owned.

Method Name: Linker:Write Info To File

Regards

Dan

Currently, we have both the 32 and 64 bit versions of LabVIEW on the same PC, and I am running into an issue of how to properly deal with the PPL plugins.  

We distribute the reuse PPLs via VIPM.   

The install process for this is typically:

- When built, Package both bitness into the same VIP file

- Unpack to a temp folder

- Determine the bitness and move the desired bitness PPL to the install folder (Ex: C:\ProgramData\PPL\DB Base\DB Base.lvlibp)

- Delete the temp folder with the "incorrect" bitness.

This works when we only have one version of LabVIEW on a PC.   But there may be times when we need both the 32 and 64 bit on a machine, depending on the programs installed.  An example being a test software that needs 64 bit and we would also want another tool that we developed and is in 32 bit, and they both need to use the DB Base.lvlibp.

Having both try to access the same file (C:\ProgramData\PPL\DB Base\DB Base.lvlibp) wont work for one of the bitness'.

Is it better to append the bitness to the file name?  (Ex: C:\ProgramData\PPL\DB Base\DB Base 32 bit.lvlibp)

Or to the folder?  (Ex: C:\ProgramData\PPL\DB Base 32 bit\DB Base.lvlibp)

In either case, I can see my build process getting more complicated for the plugin module (DB Plugin), which inherits from the DB Base PPL....

- Do I have a 32 bit project (DB Plugin 32 bit.lvproj) that points to the C:\ProgramData\PPL\DB Base\DB Base 32 bit.lvlibp and a 64 bit project that points to the 64 bit base PPL (or folder)?

I'm trying to create an executable that uses gRPC library. The project works well from development environment but I get an error 7 when running compiled code:

Error 7 occurred at Call Library Function Node in grpc-lvsupport-release.lvlib:Create Client.vi:560002->Voluson_client.lvlib:Create Client.vi:560001->gRPCFunctionCall.vi->Sequence Editor 1.vi

LabVIEW: (Hex 0x7) File not found. The file might be in a different location or deleted. Use the command prompt or the file explorer to verify that the path is correct.

I tracked it down to "GetServerDLL.vi", which, by default, e.g. when not in run-time, runs the following code:

and returns path "C:\Program Files\National Instruments\LabVIEW 2023\vi.lib\gRPC\LabVIEW gRPC Library\Libraries\Win64\labview_grpc_server.dll", which is where the "Libraries" folder is located.

At run time, it executes this:

which, of course returns location of the exe+Libraries\Win64...

I'm not clear on the intention of this or what steps should I take to make it work? Do I need to copy the whole "Libraries" to the same location as the executable manually and then add it to build specs for installer?

Thank you for reading.

AL

Thanks very much,  -Joe

Over night something changed on my windows 10 build server and I can now no longer open VIPM. It just shows the splash screen and then closes again.

Here's the log file:

=========== START of VIPM 2018.0.0 (build 2025) Error Message ===========
An internal VIPM 2018.0.0 (build 2025) Error has occured on: Tuesday August 20, 2019 at 03:19:48 PM

= Automated Message Start = 
Error 8 occurred at Open/Create/Replace File in NI_LVConfig.lvlib:Parse Config to 
Queue.vi->NI_LVConfig.lvlib:Load.vi->NI_LVConfig.lvlib:Open Config Data 
(compatibility).vi->DDEFA056211BA4DA4D215C322E067D90->621BFCD461979D3C7127139A69154E03->762BBE85A007
171D5A65B48289D23361->46803A2448FAC5F85BFF8F5C199E9C6F->OGPM 
Class.lvlib:7D7C5CD8C5D361C01081DF5613237E15->OGPM 
Class.lvlib:D69AB3997B80ACD75689430E3922612C->OGPM Class.lvlib:OGPM Init.vi->VIPM Splash.vi
Possible reason(s):
LabVIEW:  File permission error. You do not have the correct permissions for the file.
=========================
DMA hardware error detected.
C:\ProgramData\JKI\VIPM\cache\ngene_lib_deepltk_fpga_addon-1.0.0.45.spec
= Automated Message End =

= User Defined Message Start = 
    Error(s) Generated in Splash Window
= User Defined Message End =

= Error Handler Call Chain Start =
    VIPM Splash.vi
= Error Handler Call Chain End =
=========== END of VIPM 2018.0.0 (build 2025) Error Message ===========

Any idea where the files are that it doesn't have the right permissions for?

My programming skills are high, but LabView skill is almost non-existent.

I found LLB file within the Windows Resources of PE Executable.

I noticed the LLB file contains one, large "block" of data inside, called 'LVzp', which is encrypted.I wrote proper xor-based decryption algorithm.

This resulted in a Zip file. I extracted the ZIP, and found many folders and files inside.

Some folders have names which indicate they might've been libraries in original project, but were all extracted and put into directory structure instead. For example, I see a folder "vi.lib", and inside there's a folder "dlg_ctls.llb".

Now to my questions:

How should I prepare all that for re-building?

Should I re-create all the LLB files from single VI files I see in extracted folders?

Should I also create LIB files before adding everything to a new project? I understand that "New -> Library" in project view creates LLB file, how do I create LIBs?

Or maybe adding everything to a project as-is will work as well?

Are any specific actions needed to re-create a project out of these files? I figured all the "Remove ..." options in "Additional Exclusions" tab of build target need to be unchecked, anything more?

I have a problem with cmd LabVIEW. I did a state machine and build an exe(So far, so good). 

I did a state machine with a 2000ms timeout. Everytime out i launch a cmd (So far, so good). This command consist to check if nvidia cuda is installed  (All is in the code and So far, so good).

In my state machine i have a state which launch an external installer which will be installed cuda (So far, so good). 

My problem start when cuda is installed during the execution of this state machine (build in exe) and my timeout state does no work (the cmd which check if cuda is installed does not work).

When i restart the exe this state work ! and detect cuda with no problem 🤔

Why do i have to restart my exe to make it work ? (i put the state machine in snip copy and work well in LV version - Not work well when build exe)

CMD inside the exe are blocked since cuda installer was launched, why ?

If you want to do the test, just run the exe in the project, install cuda and when cuda is installed just see that it is not detected.
Restart the exe and there are no worries cuda is detected. 😭

I searched and I still haven't found out why   😭  😭  😭

217806318_SourceInstaller.zip

I've seen this here, but not sure if the output of this can be called from my 3rd party installer builder. What have others done?

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000fyxySAA&l=en-US

Please post any replies in that topic.

I first tried to use the pre build actions calling a VI using scripting to remove the block diagram from my VIs (something like below). However when I do this I get this kind of error message.

It seems that we cannot remove the block diagram before the build.

My question is "How can we remove the block diagrams from a post build action ?" 

After some research, I came across this post  in which Jim Kring says "This should be possible with a custom post-build action VI", however he does not explain how to achieve this.

I was able to remove the block diagrams using the post install actions however my goal would be to remove them with a post build action. 

I get this error when building my package with VIPM, previously the package was building fine.

It always took a long time (~15 to 20 minutes) to build this package because it's quite large (~78 classes, 1200+ VIs).
Since the last successful build I've only added some methods in the classes.

Mass compiling the folder containing the source code doesn't report any issue.

Error 66 is descibed in LabVIEW as 'The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools>>Options>>VI Server on the server side.'

I've check this and other (smaller) package still build fine.

Sources are in LV 2019 32 bit

I'm using the latest version of VIPM 2021.1 b2754

Any suggestions?

I work on a large (4000+ VIs, 1.6 GB repository) LabVIEW program. I've just finished working on a new feature, and all of the sudden the code won't build anymore, always failing with this error:

"Error 1 occurred at An error occurred while saving the following file:

C:\Program Files (x86)\National Instruments\LabVIEW 2019\vi.lib\registry\registry.llb\Registry refnum.ctl

Click the link below to visit the Application Builder support page. Use the following information as a reference:

Error 42 occurred at AB_Source_VI.lvclass:Close_Reference.vi -> AB_Build.lvclass:Save.vi

Possible reason(s):

LabVIEW: (Hex 0x2A) Generic error.

Possible reason(s):

LabVIEW: (Hex 0x1) 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 @.

=======

Command requires GPIB Controller to be Controller-In-Charge."

The feature resulted in changes to several widely used typedefs, and an update to one of our core VIPM packages (one we make ourselves).

The code runs fine from IDE, and nothing shows up as broken in the project. I've run mass compiles a few times, which found some broken VIs that were removed from the project but not deleted from the repository, so I removed those. It also found a few "Insane Objects", most of which I have now removed. The mass compile output gets smaller each time, but the error code on subsequent builds never changes.

I've been trying to read the "LVInternalReports" that are created for each failed build, but I'm struggling to interpret some of its contents. In the lvlog.txt file of the latest build, I see several <DEBUG_OUTPUT> sections with DWarn lines that seem relevant. Here is one example:

"<DEBUG_OUTPUT>
2022-09-15 1:03:56.779 PM
DWarn 0xF481EB8C: error returned from SaveObjectData: 1 image {HeapClass=FPHP,UID=12,DPId=9,o=0x9db4fe00}
d:\builds\penguin\labview\branches\2019\dev\source\panel\savedata.cpp(634) : DWarn 0xF481EB8C: error returned from SaveObjectData: 1 image {HeapClass=FPHP,UID=12,DPId=9,o=0x9db4fe00}
minidump id: f47da8ab-45aa-4102-ba6b-3f32f5b84f42
$Id: //labview/branches/2019/dev/source/panel/savedata.cpp#4 $"

Is there a way to trace what this is referring to? I assume if this refers to a particular VI it will help me track down the issue, but I don't know what these hexadecimal codes refer to.

If anyone has suggestions for other ways to diagnose the build failure it would be greatly appreciated.

I have noticed the difference in performance for the same application built on Windows and Linux (Ubuntu). Small differences could be understood but it looks like my app runs much slower on Ubuntu, so I tried to find any information what is that difference. I have checked the process created by the application in system performance and that's the first surprise: on widows I have 44 threads, on Linux 12 only. So it leads to question - is the parallel execution works on Linux ? 

I have tied to search the web to find any information related to how the application builder works but with no success. I would be grateful for any link or document describing that topic. 

edit:

44 thraeds on windows couled be expected when we have PC with 2 cores (2*20 + 4) according to https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PARmSAO&l=pl-PL

On Linux, running the LabVIEW 20XX\vi.lib\Utility\sysinfo.llb\threadconfig.vi. will show us that:

so the normal prioriti is used only (checked on Ubuntu and OPENsuse).

I have played around with package manager/builder in the last few days... it seems that this thing is not completely easy going as I thought it was - or I am just too stupid to use...

so what I want:

I have a network drive with folders where I store NI Installers/feeds/pools and other .nipkgs/feeds

I want to create "station specific" feeds out of these packages.

Easiest way I found out to create such a feed was to do it via command line?

I did something like:

nipkg feed-create C:\temp\TestStation P:\driverX
nipkg feed-create --append C:\temp\TestStation P:\driverY

What I did not find is a possibility to like concatenate different Package-Feed-Files.

For example the NI drivers and so on always have a Feed file in there installers, wouldn't it be nice to just select these files instead of all the .nipkgs in the pool folder?

Would make the new Package-feed-file much more readable if the would only contain references to other feed files, at least in my head...

thanks in advance

€:

had another idea:

I could create an installer which installs Package Manager with a few tweaks by just adding the network package feed files to the recognized feed paths?

Or does someone else have some good idea to setup production stations with defined runtimes/test setups AND also developing stations with defined versions?

I am trying to debug a (exe) build that is breaking for reasons I don't yet understand. In the past I added some setting to my LabVIEW.ini file to get extra detailed information about the build process, but I cannot find that key listed anywhere. Can someone remember what it is?

It was something like EnableDetailedBuildInfo, but it has been years since I needed it last so have got no chance of actually remembering the details.

(Sometimes I wonder if there is a race condition in the builder; what does it do for example if there are two plugins include din the build that will call the same VI, and the destination is set to Same as caller ..🤔That's not the case just now though, right now the only caller is one dynamically called external VI..)

In an ideal world I think I would create a destination for the lvlibs that plugins are to use in a single external support container-file like an llb...In the case of this JSON library though there are classes involved to, so an llb does not work (name collisions etc). Packed libraries are too cumbersome to use I think, for various reasons (having to support multiple targets for example).

So as a second best solution I want everything (all lvlibs that plugins may need something for) packed into the executable (works as a single file container, and supports classes as long as it is not using the 8.x file format...), but then the application build seems to behave very unpredictably. At first I would expect that if I included the lvlib on the always included list, and then set the destination of the lvlib to the executable I would be fine, but no. - Suspecting that this only applies to the lvlib-container file itself and not the VIs it owns, I then also set the destination for all dependencies and packed and shared libraries to the executable...- Still the builder puts lvlib-VIs together with the plugin. I have tried this with and without excluding unused members of the library with/without modification...and with and without disconnecting type definitions.

In the end I returned to the original build setup (as this was noticed after a conversion from 2018 to 2020), tried a build, got a Bad-VI error on a couple of VIs used by an xcontrol, set those to include the block diagram...and voila - magically this affected where the JSON lvlib ended up as well, even though they have no links in the code. This problem keeps popping up though, and once it is there it seems like getting the lvlib-files to the wanted destination always includes some voodoo...😧 Or does it?

is there a (clean) way to install Matlab with NI Package Manager?

I need some mat-Scripts (local .m-Files) for my software and make sure the right version is installed. (as we use package manger, and I am not that familiar with it, it would be nice to have one software package rather than someone have to install the software one by another)

The scripts are called in the software and needed to be changed by some other developers, without entering LabVIEW 😕

br

Michael

The "C:\ProgramData\National Instruments" folder on one of my VMs is using 40GB. Does anyone know the proper way to clean up the NI crap?

Using SpaceSniffer, it show the bulk of it is used by the Update Service and NI Package Manager. I'm sure it's just leftover installers that may be needed.

Not a great description, but I figured it was worth an ask if others have been able to get this to work.  

I have tested my application on 5 completely different Windows 10 computers managed by different people. On three of them with various versions of LabVIEW IDE my executable opened with a whole Run arrow and no error message. Two other machines previously had no LabVIEW, so I installed a Runtime Engine 2017f2 32-bit with default settings to match the version of my IDE. Both gave an identical error message.

The DLL is always included in the application build. I have tried placing the DLL in every conceivable location on the target host: in the executable folder, in the /data folder, in the c:\Windows and system32 folders... I even created a full folder tree matching the location of the project on the developer workstation. Same error. When I intentionally hide the DLL, my executable prompts me to point to it upon being opened, and when I do, I get all the same error messages.

Vendor documentation only asks to put the two files in the same folder. From programmer's manual: " The driver was written in LabWindows/CVI, version 4.0.1 and is contained in a dynamic link library which can be linked with a variety of programming languages." There is no vendor-provided support.

One way I actually got rid of the error message was by editing every Call Library Function Node in every VI in the LLB to use relative path to DLL together with the Application Directory VI. However, I feel that there has got to be a better way to compile than by editing a vendor-provided library, especially since it works as-is on some computers. Can anyone suggest what it is?

Thank you for your time!

Quote

NI_LVConfig.lvlib:Load.vi<ERR> C:\Users\MichaelA\AppData\Local\Temp\AB_Cache_{DD695C27-7E5F-4A88-8B25-B389D65799CC}.txt <b>Complete call chain:</b>      NI_LVConfig.lvlib:Load.vi      NI_LVConfig.lvlib:Open Config Data.vi      AB_RW_Project_Cache_Info.vi      BuildMonitor_Clean.vi      CleanTarget.vi      NI_App_Builder_API.lvlib:Clean.vi      build exe - vishots.vi      Build_App2.vi

I've seen this issue a few times with various projects. I'm not sure what causes it, but there's no way to recover from it quickly. The only thing that fixes it, that I've found, is to manually execute a build from the project build spec. This seems to fix the missing cache issue. After a manual build is done, Automated builds using the build.vi work as expected without errors, multiple times.

To make things simple to try and get to the root of it I created the simplest possible example I can think of. One copy is in LV2019 and it works fine, the other is LV2020 and it does not work.

The assembly builds fine in LV2020, and indeed is callable from LabVIEW code. The test is just a simple Increment VI.

This works fine when the assembly is built using LV2019, the num variable is correctly 2 after running this line of code.

However in LV2020 I get the following exceptions after running that line

System.TypeInitializationException
  HResult=0x80131534
  Message=The type initializer for 'MyAssemblyNamespace.LvClient' threw an exception.
  Source=Increment2020
  StackTrace:
   at MyAssemblyNamespace.MyTestClass.Increment(Double input)
   at Increment.Program.Main(String[] args) in C:\dev\Scratch\DLL Build Test (2020)\Source\C#\Increment\Increment\Program.cs:line 10

Inner Exception 1:
FileNotFoundException: Missing Dependency in:

Inner Exception 2:
VIAssemblyException: Missing Dependency in:

I have tried playing around with including the LabVIEW Interop assembly in the C# application (C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2019\NationalInstruments.LabVIEW.Interop.dll) and changing this to 2020 for the LV2020 version, it does not seem to make any difference.

The LV2019 version runs without this assembly included in the project.

Is this something to do with the GAC? This is now getting into the details of .NET that I am not really very familiar with.

Does anyone have any tips for things I can look into? I have attached a zip of everything for anyone curious.

Build Test.zip

I know the LabVIEW runtime is also available as an nipkg file. is that the better way to go? If someone can suggest any other solution that would help, I appreciate it.

I have recompiled the dll with Enable Debugging and Wait for debugger on launch enabled in the build specifications. I then launch the Debug Application or Shared Library window from LabVIEW (in the Opertate menu) and run TestStand (which calls the dll). Nothing happens - the dll runs as expected but I am not able to connect to it for debugging.

I have never used the Debug Application or Shared Library functionality and I'm not sure if I'm doing something wrong or if this is even possible (although the help files lead me to believe it should work). Any nudges in the right direction?

When I build an application with LabVIEW for Mac OS X (2016 through 2020), the icon is yellow and when I save a plot of data, the png is yellow as well.  Running the source code is fine, the icons are normal (black text, white background) and my png plots of data are normal.   Does anyone else see this behavior with the LabVIEW Application builder for Mac OS X?   My only option is to continue to use LabVIEW 2015.

Main.vi Some Plot.vi try_LV_2020_Save_Plot.aliases try_LV_2020_Save_Plot.lvlps try_LV_2020_Save_Plot.lvproj

Does someone know what the long-meaningless-named VI might be (a vim instance, I'm guessing).  

Any help appreciated.

-- James

I've been working on this for years but I still haven't managed to set up a build server that builds reliably.

My inputs are a vipc file and a .lvproj with all relevant files checkout via git. From there it's a two-step process. A powershell script makes 2 separate calls to labview using two small helper vis:

1.) apply vipc file using VIPM API; close labview entirely

2.) build the project given a build spec name

In the end of step 2 it comes down to this

And I have no idea if the last 2 steps are needed but I'm definitely trying to work around problems there, such as:

- some files have changed, because LabVIEW can't just open a project without touching it. So I need to save everything to avoid the "Don't you want to save" dialog blocking everything

- I can't remember what the "Exit" is for

I've played with clearing the build and compiled object cache before every build. I've just turned off automatic recovery saving on my build servers. But I still find myself with builds that just never finish. Often, the last line in my build log is "Attempting to build <whatever>". Of course there is no way to debug a build that's gone wrong because I can't just remote into the build server and look at what's going on because the labview instance that's been started by the build pipeline isn't visible on my desktop even though it's the same user. So all I can do is manually restart, and in most cases that fixes the problem. Of course, the problem is not fixed then ...

Sometimes I remote into the build server and I see a vipm crash handler window. Sometimes I get the old "Sorry for the inconvenience" thing from labview but nothing is ever repeatable

Are there any other recommended settings? Should I mark all files as read-only to stop labview from touching them?

Any tricks, recommendations or other mildly related wisdom?

This is the code:

I have done everything I can think of including re-installing the runtime engine, creating an installer from the build PC, copying all DLLs from the Runtime directory to the application data directory etc, none of this works.

This is just a regular PC, the only thing that is a bit out of the ordinary is that it does not have internet access, but surely this is not the cause? Could it be related to 64-bit?

Anyone else seen this in 2019 64-bit?

I've been trying to figure out how to get a function made with LabVIEW 2011 up and running in MS Visual C# 2010 (.NET 4.0)

I've been using this guide:

http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/building_a_net_assembly/

When i try to execute the code I made in visual studio I get the following error:

Failed to call InitLVClient function

I've seen this thread:

http://forums.ni.com/t5/LabVIEW/VIAssemblyException-quot-Failed-to-call-InitLVClient-function/td-p/1472988

My question to you is, is it possible to create LabVIEW 2011 code for use in Visual C# 2010?

If so does anybody have a link to a guide on how to export LabVIEW 2011 VIs into a format that can be called from Visual C# 2010? Even better yet, does anybody have any example code I could work off?

My two Win 10 machines are on a corporate domain. I have local admin access. One runs LV 2017 32-bit IDE, the other - a matching runtime engine.

Does anyone know if it is possible to run a LabVIEW application without installing the RTE by carefully placing certain files in the right place?

I need to test my LV RT update without real target (cRIO-9045) and I don't need to use the real I/O module and real FPGA, I want to test only the interface betwwen host application (on PC) and RT application (cRIO).

To do that I've used
1) "ni-linux-rt-pxi-system-image-2019.09_19.5_online_repack2.exe"
       to download the iso file : standard_x64_recovery.iso (84 MB)
2) After I 've Created a VM with Oracle VM 6.1 + “Oracle_VM_VirtualBox_Extension_Pack-6.1.12.vbox-extpack”
      Below the VM settings :

a) Linux Ubuntu 64bit and 2GB RAM                                                                          b) 10 GB 

c) EFI selected                                                            d)  USB 3 controller for keyboard

e) selected the *.iso file                                          

 3) after run ("avvia") and with keyboard arrow select "verbose mode" (keep in mind, the keyboards now works)

but when the installation arrives at the first choice option I'm not able to select anything because the keyboards on VM doesn't work

Any suggestion?

Thanks

Is there a way to configure the default path for those extra installers from the Application Builder itself or from any LabVIEW configuration ?

For two of the packages that I have created for internal repos, VIPM has decided that I need a System Package.   The posts I have seem from JKI indicate that this is a sub-package that is used internally to the main package, and should be automatically included.

However, after I am seeing issues on any PC other than the PC where the package was built.

Is there a setting I am missing?

Showing the (System) package as a dependency:

Package Configuration in the VI Package Configuration Editor

Package installed, on the PC where the package was initially created (no issues, no exclamation mark)

Package when installed on another PC (NOTICE: the System Package name has changed and there is a red exclamation mark, but there are no errors shown on install of the package).

void __cdecl _InitCodePtrsProc(struct VICodePtrsRec **viCodePtrs);

Just to explain what I'm talking about:

* VI files and other RSRC files, can contain compiled code stored in VICD resource

* VICD consists of the actual assembly, and list of 'patches'; these patches combine function of imports table and relocation table

* The actual assembly always has a InitCodePtrsProc() function, which sole purpose is to fill an array of code pointers which it receives as parameter

* The code pointers are just references to other functions which exist in the assembly; there are up to 30 such callbacks

* executing a VI file means just calling these callbacks, in proper order

It's not that hard to figure out the parameters of these callbacks, I'm just wondering if we already have that information.

Here's example init function for a very simple VI:

void __cdecl _InitCodePtrsProc(struct VICodePtrsRec **viCodePtrs)
{
  struct VICodePtrsRec *ptr;

  _VINormalInitCProcsHelper(viCodePtrs); // Imported routine, pointed in list of patches
  ptr = *viCodePtrs;
  *((_DWORD *)ptr + 5) = _InitProc;
  *((_DWORD *)ptr + 25) = _CodeDebugProc;
  *((_DWORD *)ptr + 26) = _CodeErrHandlingProc;
  *((_DWORD *)ptr + 30) = _RunProc;
  *((_DWORD *)ptr + 28) = _InitCodePtrsProc;
}

It's nothing to fancy. I added a few things to the UI to support more features and in preparation of adding the VI renamining/relinking step that was done seperately in the OpenG DEAB tool before calling the OpenG package builder. But I never got around to really add the deab part into the package builder. It's kind of extra difficult as the DEAB compononent doesn't currently support newer features like lvclass and lvlib at all and of course no mallable VIs etc.

I can post what I have somewhere, but don't get to excited.

I also found IB_Classes subfolder which has functions for interacting with Installers maybe, but there's no clear function to open an Installer build specification to start editing. I have a template project where I need to change three parameters for the Installer when the template is copied/edited: destination.name for one specific destination, INST_bldLocation, and INST_productName.

This is an example of updating a few of the build specification items for a PPL (just need the equivalent for installers):

Does anyone know if there is a way to hook Build Specification Executable Properties window in order to add a custom configuration panel? (cf. screenshot). I don't know if this can be achieved through LabVIEW project providers but I can't find any information about this subject.

Thank you in advance to anyone who can provide help or informations.

I'm having problems building a vipc from a vipb with files containing nested vims. Getting the following error from VIPM:

ERROR: 7: VIPM API_vipm_api.lvlib:Parse Build Return Message_vipm_api.vi<ERR>
Code:: 7
Source:: 0053C289D635723F5DC0A4F08297566A<ERR>
The following source VIs or Libraries are missing.
Please correct this problem before rebuilding.

b39afad9-8321-4719-86a9-dddab325fc87.vi

The following source VIs or Libraries are the callers of missing files

BitsSetter.vim

I created a zip with the vims and the vipb file. Any suggestions how to fix this?
Opening the files shows no errors. Replacing the nested vim with its actual implementation fixes the problem but I don't want to give in just yet.

I'm on LV 18.0.1f4 64bit with VIPM 2018.0.0f1

Cheers

bits.zip

Used PowerShell & ran the following:

[Reflection.Assembly]::LoadFile('C:\absolute\path\to\my.dll').GetReferencedAssemblies()

This neatly produces a list

Well my VI isn't broken and it runs fine in the development system. I've shut down and restarted LV with no luck. I can't see anything odd in the project. Any ideas? I just know NI is going to tell me to rebuild the project if I call them. BTW, I am able to build other executables.

<br><br>George<br><br>PS. I just rebuilt the Exe builder with no luck.<br>

I can get the installer to run through from start to finish with no user interaction using:

install.exe --passive --accept-eulas --prevent-reboot

However during install it pops up its own dialogue.

Does anyone know how I can suppress this dialogue?

https://forums.ni.com/t5/Actor-Framework-Discussions/Looking-for-IDE-Performance-Optimization-Suggestions/m-p/3961791#M6126

Boils down to, as you build large projects with AF are long build times unavoidable? What are best practices for avoiding long build times while working with AF?

Is there is a compilation of all the "tribal knowledge" about best AF/OOP coding practices for keeping build and IDE performance manageable?

Today I started getting a Load Warning Summary when running my .exe build specification - no idea why, and it is causing the generated .exe to be broken.

I think it's basically saying in the Load and Save Warning List message box attached that LabVIEW is loading DataStorage.lvclass from within the .exe, when it was expecting it to be within the source code.
The build completes, but with a broken arrow as the .exe can't find DataStorage.lvclass

All I've done today is add some functions to the class, but nothing major.

I've tried multiple things to fix it, including a Mass Compile but to no avail.

My next step is to revert back a couple of versions to find a version that will build so I can track down what I did to break it.

The other thing to say is that this error message appears when about 50% of the way through running the build (during Compile), so it's like when LabVIEW tries to load the class from the vi during the build it's loading it from the .exe rather than source code !?

Any ideas would be appreciated if you've seen a problem like this before.

Thanks,

Martin

Most of us here build applications and add to it user manuals and readme files that instruct how to install the app and what its requirements are.

However, we don't give the same level of documentation to the development env so that we could manage the source code from another computer in a few years.

You might lose track of the LV version, modules, addons, vipms, folder structure, win version, 3rd party tools/activex/dll/db, LV ini, system settings, methodology/architecture, passwords and so on.

I would love to hear how you approach that issue (docker VMs? Jenkins with a build from repository dedicated station?).

For now, to make it simple, I'll ask if there is a way to install LV automatically without having to install and modify manually:

1. LV ini and configurations

2. All the VIPMs that I currently use

3. NI Modules

4. 3rd party tools like activex and dlls

It takes hours if not days to install everything.

Is there a way to have such a bundle automatically installed when for example I upgrade LV or reinstall it on a different computer without me writing my own installation automation as I do for customer applications?

It will be crazy if I would have to update my installation automation each time I add a new VIPM or addon or save something new to the user.lib for each application I write for each version

For the first stage, I would be satisfied with a one-click unattended silent install of 20 VIPMs with LV env customization

NI has a download page for the file TDAQ740.zip (http://www.ni.com/download/traditional-ni-daq-legacy-7.4/587/en/), but the link won´t work.

What is happening is that when I do my programmatic build, the lvproject only "remembers" the last build I manually did through the project itself, instead of the programmatic build.

for example, say I right click on my executable build specification, select "build".  My build will run, complete, and then all the files will be stored in the folder builds\EXE 1.0.0.0.  The flag "Auto Increment" is set to True. 

Now, I run my build script 5 times.  I will have folders EXE 1.0.0.1 through EXE 1.0.0.5.  I open my exe build specification in the labview project, navigate to the "Version Information" page, and the Version Number correctly shows 1.0.0.6 as the next build number.  So my build script is updating the build specification with the correct auto increment, and I have verified that LabVIEW is creating the correct files in the correct folder.

But, when I go to the build specification, right click and select "Explore", LabVIEW opens the EXE 1.0.0.0 folder, instead of the EXE 1.0.0.5 folder.

The consequence is that when I do an installer build, LabVIEW thinks that the 1.0.0.0 build was the last build, so the incorrect exe is copied into the installer.

Has anyone run into this issue with programmatic builds?

I have a question about general rule of packaging and distributing LabVIEW code.

I have a LabVIEW project (please see below tree structure) which contains numerous VI sample code which invokes function calls in the dll (PVCamNET.dll).

As the project needs to be shipped to the world I would like to package it more professionally than zipping the entire folder. 

Note the folders, DemoApp and Examples contain VI code.

Looking at the build specifications  there seem to be many options for packaging.

I have a DLL enclosed in the folder and besides the VIs the DLL must be part of the project.

My question is quite simple - what is the best way to package this project for the user to play with the VI code ?

Thanks!

I've installed LabVIEW 2018 which also attempted to update VIPM. LabVIEW installed OK, but VIPM failed to install. Been getting the message "The older version of VI Package Manager 2018 f1 cannot be removed. Contact your technical support group." Anyone seen this before?

Tried uninstalling VIPM then reinstalling through LabVIEW installer with no luck.

However as I am sure is the case with many companies, we need to maintain our data locally for corporate reasons. There was a reference to being able to have a local repository in the initial NI Week presentation by Derek but since then I have not seen any other reference to it and there is limited information available about the processes. Has anyone got any experience with the operation of GPM for internal use, or even any use with GPM in general? From looking through the Lava and NI forums, doesn't seem like many people have picked it up or at least haven't posted anything about their experiences with it.

I have tried posting code to forums in the past.  I have even posted to the code repository here on LAVA.  I have used code posted here and via the tools network and VIPM in my own projects.  But I am not sure if any of those avenues are the right path forward for me.  There was much discussion about different open source repositories on the interwebs that we could leverage.  There was also some discussion about how to help others discover the code you shared.  What I did not hear was any definitive conclusions on how best to do this.

So, the point of this thread is to try to solicit feedback on code sharing and come to some sort of consensus on the best options out there.  If you have an opinion on this please join the conversation and share what you think is the best solution.   Here are some questions I am trying to answer:

1. Where should we share code?  What system works best for LabVIEW code and is user friendly enough to not discourage people from using it?  Please share links and how-to documents for your preferred site/system.

2. How should we license code?  I heard some discussion about the various type of licenses.  I am not interested in retaining any rights to code I share and do not want to put any burdens on those who want to use and learn from any code I share.  What licence is accepted in the open source community that supports this kind of sharing?

3. Once we post, how do we make our code discoverable?  Do we need to post links all over the place or is there a better way?  Here is one attempt at making that better you should check out if you have not already: 

I am not just interested in putting the code out there, but also trying to explain why I think it is worth your time to take a look.  I am willing to post on forums, create a blog, even produce some vlogs on YouTube if it is the best option.   Please let me know what format would motivate you to take the time to learn about the open source code out there.

Either way, thanks for taking the time to read this thread and contribute what you can, even if it is just to follow the discussion and learn from others like I am trying to do.

-John

https://forums.ni.com/t5/LabVIEW/shared-variable-bound-to-Modbus-i-o-not-working-in-deployed/td-p/3809801

TIA, Enrico

I'm using VIPM to build my device drivers and project templates into vi packages which are then used by other developers. During the build process some of the front panel elements get blown up as if the text size was changed and then reduced again but the size of the control doesn't return to its original size. A similar thing happens on the block diagram. Some structures (set to auto-grow) end up wider in the package than in their original source as if a BD element inside the structure was increased in size and then decreased again. While that's not a terrible thing to happen in the drivers, it really kills the templates because the first hour is spent to fix up cosmetics...

I've attached some screenshots.

Anyone know how to fix that?

I register the events Win32_ProcessStartTrace and Win32_ProcessStopTrace for my .exe using Register-WMIEvent in Powershell.

Only the start event comes, never the stop event.

It works correctly with other exes such as notepad.exe, excel.exe, firefox.exe.

And then it defines the 2D array arguments to my function as being of this type: "void __cdecl Linear_discrim_4dll(DoubleArray *dataObsFeat, int32_t grpAsz," etc etc.  Trouble is, I have no idea how to fill out this structure so that the DLL can use it.  Say for simplicity I had a 2 by 3 input called dataObsFeat with elements {1,2,3; 11,12,13}; how would I create the object with these values in C or C++ and pass it to the function?  I am a total C++ noob, in case it isn't obvious.

I would like to automate downgrading process for few LabVIEW projects from LV17 to LV14. I use Project.Save for Previous method and it works fine for simple projects. It ignores everything that lives in vi.lib (KB).

But if I have a project that refers to toolkits located in instr.lib like instrument drivers, NI-DMM or NI-DCPower, saving for previous exports some of them to my destination folder. Interesting fact: I receive a warning, that NI-DMM and NI-DCPower were not converted (good news), but niModInst (part of NI-DCPower) was! And, of course, third-party instrument drivers (PSU drivers) were also converted. As you know, It greatly changes the destination folder hierarchy and alters references to these VIs in my project. I don't want to save these external files and toolkits for previous version, because I already have them in a different LV version installed. They are toolkits indeed and not project specific files.

Have you ever tried to setup Save for Previous function so it really ignores instr.lib? Or maybe, is there a way to setup third-party toolkits in instr.lib so they act like NI-DMM? Like "I don't support saving for previous, please be kind and install me for a different LV version by yourself"? 

It is a pain, honestly 

I have an application that works fine on my developpement computer (Windows 7 pro 64bit).
This application basically handles database and communications with some PLC's.

When using the same build on a customer's computer running windows 7 ultimate, it starts really nice, the communications, display and database are all ok.
But after some amount of time (not always the same, from 5 minutes to 1hour) the whole computer crashes. The display is frozen and there's no way to take control back.
I have to remove the power supply to make it work.
 

I checked the same software without most loops, it does the same,
I made a small test software (state machine activating and deactivating a boolean and counting every second), it does the same as my main software.
I checked the full software on another windows 7 pro computer, no issue. It's still running like it has been running on mine for more than 24hours.
 

The customer's computer is an industrial computer i7-6700 3,4GHz ; 8GB DDR4 Ram, Windows Seven Ultimate 64bit.

So here's my question, are there any know issue with labview application or labview RTE 2017f2 and windows 7 ultimate ?
Or maybe you have any idea of what could be wrong ?

Any ideas what to do next?

####
#Date: Tue, 10 Oct 2017 14:42:22
#OSName: Windows 10 Pro 
#OSVers: 10.0
#OSBuild: 15063
#AppName: LabVIEW
#Version: 16.0f2 32-bit
#AppKind: FDS
#AppModDate: 2/13/2017 09:03 GMT
#LabVIEW Base Address: 0x00400000


InitExecSystem() call to GetCurrProcessNumProcessors() reports: 4 processors
InitExecSystem() call to GetNumProcessors()            reports: 4 processors
InitExecSystem()                                      will use: 4 processors
starting LabVIEW Execution System 2 Thread 0 , capacity: 24 at [3590451742.90439940, (14:42:22.904399395 2017:10:10)]
starting LabVIEW Execution System 2 Thread 1 , capacity: 24 at [3590451742.90439940, (14:42:22.904399395 2017:10:10)]
starting LabVIEW Execution System 2 Thread 2 , capacity: 24 at [3590451742.90439940, (14:42:22.904399395 2017:10:10)]
starting LabVIEW Execution System 2 Thread 3 , capacity: 24 at [3590451742.90439940, (14:42:22.904399395 2017:10:10)]
starting LabVIEW Execution System 5 Thread 0 , capacity: 24 at [3590451744.55625770, (14:42:24.556257725 2017:10:10)]
starting LabVIEW Execution System 5 Thread 1 , capacity: 24 at [3590451744.55625770, (14:42:24.556257725 2017:10:10)]
starting LabVIEW Execution System 5 Thread 2 , capacity: 24 at [3590451744.55625770, (14:42:24.556257725 2017:10:10)]
starting LabVIEW Execution System 5 Thread 3 , capacity: 24 at [3590451744.55625770, (14:42:24.556257725 2017:10:10)]

<DEBUG_OUTPUT>
10/10/2017 14:43:21.731
DWarn 0x5C359BD0: no freeRange list or no elements
e:\builds\penguin\labview\branches\2016\dev\source\vi\cloneVI.cpp(412) : DWarn 0x5C359BD0: no freeRange list or no elements
minidump id: 5a131b3f-9e0e-4462-a33f-36b0f8b94d96
$Id: //labview/branches/2016/dev/source/vi/cloneVI.cpp#6 $

</DEBUG_OUTPUT>
0x006997BC - LabVIEW <unknown> + 0
0x10014A44 - mgcore_SH_16_0 <unknown> + 0
0x018B1176 - LabVIEW <unknown> + 0
0x018B18E5 - LabVIEW <unknown> + 0
0x01884365 - LabVIEW <unknown> + 0
0x018846A5 - LabVIEW <unknown> + 0
0x018A5903 - LabVIEW <unknown> + 0
0x01836EAA - LabVIEW <unknown> + 0
0x018AF415 - LabVIEW <unknown> + 0
0x009A1299 - LabVIEW <unknown> + 0
0x009B0166 - LabVIEW <unknown> + 0
0x00FE0918 - LabVIEW <unknown> + 0
0x01101929 - LabVIEW <unknown> + 0
0x00FDE022 - LabVIEW <unknown> + 0
0x013D2047 - LabVIEW <unknown> + 0
0x013D2ADB - LabVIEW <unknown> + 0
0x00BA92D1 - LabVIEW <unknown> + 0
0x01EB4817 - LabVIEW <unknown> + 0
0x01F661E5 - LabVIEW <unknown> + 0
0x01EB492C - LabVIEW <unknown> + 0
0x01EE0978 - LabVIEW <unknown> + 0
0x01F657A4 - LabVIEW <unknown> + 0
0x01F4CECB - LabVIEW <unknown> + 0
0x00AE5A05 - LabVIEW <unknown> + 0
0x0145A8F8 - LabVIEW <unknown> + 0
0x0145A91B - LabVIEW <unknown> + 0
0x00BA7981 - LabVIEW <unknown> + 0
0x01600F1B - LabVIEW <unknown> + 0
0x01605C71 - LabVIEW <unknown> + 0
0x01607D18 - LabVIEW <unknown> + 0
0x01EB4817 - LabVIEW <unknown> + 0
0x00CAF9BF - LabVIEW <unknown> + 0
0x00CB2189 - LabVIEW <unknown> + 0
0x00CB254E - LabVIEW <unknown> + 0
0x01EC0329 - LabVIEW <unknown> + 0
0x01F661E5 - LabVIEW <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***
#** prop types: "C:\Users\MFG-LaserCal-1\Desktop\build\LaserCalV2.exe\1abvi3w\user.lib\_LVCommon\LcProcessSpecs_class\utils\LcProcessSpecs_New.vi"
#** Loading: "C:\Users\MFG-LaserCal-1\Desktop\build\LaserCalV2.exe\1abvi3w\user.lib\_LVCommon\LcProcessSpecs_class\utils\LcProcessSpecs_New.vi"
*** End Dump ***

<DEBUG_OUTPUT>
10/10/2017 14:43:26.805
DWarn 0x5C359BD0: no freeRange list or no elements
e:\builds\penguin\labview\branches\2016\dev\source\vi\cloneVI.cpp(412) : DWarn 0x5C359BD0: no freeRange list or no elements
minidump id: 9e03b61f-a952-492f-84a7-1c132e2646f1
$Id: //labview/branches/2016/dev/source/vi/cloneVI.cpp#6 $

</DEBUG_OUTPUT>
0x006997BC - LabVIEW <unknown> + 0
0x10014A44 - mgcore_SH_16_0 <unknown> + 0
0x018B1176 - LabVIEW <unknown> + 0
0x018B18E5 - LabVIEW <unknown> + 0
0x01839216 - LabVIEW <unknown> + 0
0x0183473D - LabVIEW <unknown> + 0
0x0183A560 - LabVIEW <unknown> + 0
0x01823ED2 - LabVIEW <unknown> + 0
0x018241BD - LabVIEW <unknown> + 0
0x01822664 - LabVIEW <unknown> + 0
0x01821D18 - LabVIEW <unknown> + 0
0x0183A3EB - LabVIEW <unknown> + 0
0x0181AE5D - LabVIEW <unknown> + 0
0x0181EECD - LabVIEW <unknown> + 0
0x0181F8BA - LabVIEW <unknown> + 0
0x010F4FED - LabVIEW <unknown> + 0
0x01100B34 - LabVIEW <unknown> + 0
0x0046C5D2 - LabVIEW <unknown> + 0
0x0046C7EA - LabVIEW <unknown> + 0
0x0046C8F5 - LabVIEW <unknown> + 0
0x00FDF8AD - LabVIEW <unknown> + 0
0x018298E4 - LabVIEW <unknown> + 0
0x018290BC - LabVIEW <unknown> + 0
0x018224B2 - LabVIEW <unknown> + 0
0x00FB1224 - LabVIEW <unknown> + 0
0x00FB1371 - LabVIEW <unknown> + 0
0x01822FFA - LabVIEW <unknown> + 0
0x018216C1 - LabVIEW <unknown> + 0
0x010F3551 - LabVIEW <unknown> + 0
0x01101117 - LabVIEW <unknown> + 0
0x00FDE022 - LabVIEW <unknown> + 0
0x013D2047 - LabVIEW <unknown> + 0
0x013D2ADB - LabVIEW <unknown> + 0
0x00BA92D1 - LabVIEW <unknown> + 0
0x01EB4817 - LabVIEW <unknown> + 0
0x01F661E5 - LabVIEW <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***
#** Loading: "C:\Users\MFG-LaserCal-1\Desktop\build\LaserCalV2.exe\1abvi3w\instr.lib\_BarajaDrivers\Tunable Lasers\VdYenistaT100S_class\Example\Example1.vi\2"
#** Loading: "C:\Users\MFG-LaserCal-1\Desktop\build\LaserCalV2.exe\1abvi3w\instr.lib\_BarajaDrivers\Tunable Lasers\VdYenistaT100S_class\Example\Example1.vi"
*** End Dump ***

<DEBUG_OUTPUT>
10/10/2017 14:43:29.020
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: 6b19dd9c-e4a7-433e-b736-08a8fdd75b3e
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x7217146F - nierInterface <unknown> + 0
0x72175D75 - nierInterface <unknown> + 0
0x7217517A - nierInterface <unknown> + 0
0x762FA30D - KERNELBASE <unknown> + 0
0x77CC4AF1 - ntdll <unknown> + 0
0x77C857FD - ntdll <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***
#** prop types: "C:\Users\MFG-LaserCal-1\Desktop\build\LaserCalV2.exe\01_Application\MAIN_LaserCalV2.vi"
#** Loading: "C:\Users\MFG-LaserCal-1\Desktop\build\LaserCalV2.exe\01_Application\MAIN_LaserCalV2.vi"
*** End Dump ***

I would like to implement a Run-time license checking mechanism that will enable or disable some parts of my LabVIEW API depending on a license status. 

After reading numerous discussions here on the forum (We need a new password cracker :( , Low level VI data editor (warning: not for production use!) , I found some more hidden INI keys, Password Security in LabVIEW) I realised few things:

- reverse engineering in a LabVIEW-related field seems to be a doable task for some smart people, 

- password protection on block diagrams does not protect your IP, it is more of a "read-only" or a "private property" sign,

- removing block diagrams or compiling it into an executable are the ways to go, and finally,

- there are few tools out there, that seem to have a potential to "unflatten" VI data and modify/extract its data even without block diagrams.

Back to my task. I decided to remove block diagrams. Inside my protected VI I call an external library that does the actual license checking. So the code only gets this status and returns it back to other VIs. Then the VIs do not perform their main functions, and the user gets an error. 

Do you think I am safe here?

Is it possible to extract sensitive string information out of my VIs (without BD)?

Is there a way to change wiring rules/connector pane on my VIs?

Should I worry about DLL hijacking? 

Does NI have some kind of a tutorial for protecting your run-time API? 

How do you protect your API knowing all that? Do you sleep well?

Thanks

My name is John and i study Electrical/Computer engineering.

I am working on a project that consists of a user interface VI that communicates with a web page. ( locally ).

Look at the attached image for my project structure.

My issue is this : The project runs correctly ( i start the web service(this is on debug server port 8001): startup VI that is basically the User Interface pops-up. I right click on the "index.html" to get the URL and open it with a browser. any changes i make with my UI are visible on the browser. So , all cool so far)

When i try to build either a standalone application ( .exe ) or an installer it just doesn't work. I open the index.html with browser(on port 8080, also tried 8002(see attached image))  ( general style with css is visible, so it means that index.html opened) but nothing is updated. ( i send images/audio)

This is the first time i need to build a standalone application so i guess i didn't build it correctly.

Also as for the installer , if i understand correctly i need to first build an exe(that has the web service included) , and then include it in the installer  ?

I attach some more images where i show the build specification options.

Could you please walk me through ?  What source files do i need to include etc.

Thank you in advance.

Most of the time I am able to find solutions to my issues just by reading this forum but I wasn't that lucky this time.

So, i got an issue when i'm trying to install my build.

I got the following message: "This distribution is built with an older version of winMIF that is not compatible with .NET 4.6.2 upgrade to 17.0"

When googling this error message or even "winMIF" i can't find anything that match my request
I tried to uninstall the .NET framework and then reinstall the 4.0 (and 3.5) and I got the same issue. (Exactly the same error even if it's .NET 4.0 or 3.5 ...)

The computer used to build is a Win7Pro with Labview 16.
The target computer is a WES7 (but I got the same issue on my dev computer ...)

In advance thank you, 

Piet

I am deploying an executable (not installer) in a target PC with the same programs (labview and toolkits) installed than the development machine.

When I create executable I uncheck the option "enable debugging" (see image below):

** In the image "enable debugging" is checked but I uncheck in my application.

Then I am trying to debug in run time and of course I can not.

I do this to make me sure that the user can not get my block diagram.

But now I realized that in .ini file that Labview creates with executable there are these options:

DebugServerEnabled=False
DebugServerWaitOnLaunch=False

So if user writes "true" in these options, can they debug in real time and because of that get my block diagram?

Thanks a lot!

(arguments: /q /acceptlicenses YES)

But if the installer has no changes to install I want it to skip silently.

Unfortunately the behavior I am seeing is the installer will run and reinstall everytime in this mode.  Does anyone know how to get it to try and skip silently if there are no changes needed?

I have an application that uses PPL (Packed project library). During the build process of my application LabVIEW copies the PPL to build/My App Folder/data. I can run the application afterwards. If the PPL is deleted or moved later from this ../data/ directory I no longer can run the app.

Is there a way to dynamically link and load PPL from another location?  I've tried using viSearchPath for this but unfortunately it doesn't work. 

Thanks,

Nikita.

also posted here http://forums.ni.com/t5/LabVIEW/Create-a-link-to-PPL-Packed-Project-Library-in-Application/td-p/3555902

Best Regards

Eric

Note: I saw an old post by crelf here where there was some discussion of approach #1, below, and a follow up by Tonn Plomp about that mentioned the problem I've sited below.

Problem

Application installers that include dependencies (e.g. LabVIEW Run-Time Engine, IMAQdx, DAQmx, VISA, etc.) can be quite large. When users are upgrading to new versions of your application, it would be nice if they could just download the new application, and not have to download the dependencies, if they have not changed.

Solution (over-simplified)

Separate the installation of the application from the dependencies, and manage this all somehow.

More details on approaches...

= Approach #1 / Have two installers: "Full" (App + Dependencies) & "Upgrade" (App only)  =

How: Copy the installer rules and delete the dependencies. Call this the "Lite" or "Upgrade" installer.

Problem: The full installer and lite installer will likely have different product guids (component codes / installer IDs), so Windows will treat them as two different applications. And, since they are installing your application into the same location, there will be a conflict. The installer will not actually uninstall the old files first (maybe, or other bad things will happen that we can't predict).

= Approach #2 / Have two installers: "Application" & "Dependencies" =

How: Create an installer that includes the application and the dependencies. Then, make a copy of this and remove the app, so that only dependencies are installed -- call this "Dependencies". In the original installer build spec remove the dependencies -- call this "Application"

Problem 1: The first time the software is installed, the user has to install two separate things: Dependencies and then Application.

• Solution: In the "Dependencies" installer, include the installer for Application as additional support files, as well as a batch file that gets called as a post build spec to install the Application, after the Dependencies get installed.
  • Bonus: call this installer "Full Install" since it now includes the Dependencies AND the Application -- but, note that it's structurally different than the Full version in Approach #1, above.

Problem 2: What happens when the dependencies for your application change? (e.g. if it requires a new version of the run-time engine or if you start using some other LabVIEW feature that requires an additional support installer)

• Solution: Use some kind of versioning scheme where users understand that major releases of the Application will require upgrading the "Dependencies" installer to the same major version, too.  

= Approach #3 / Use a package manager with dynamic download and dependency management capabilities =

OK, we know this is the best solution, but let's explore what folks are doing with the above two approaches, for now...

Looking forward to hearing what people are doing and what your thoughts are on these approaches I've outlined.

The problem occurs though when I install the VIPM package (to vi.lib, although it doesn't matter where). All the VI's in the package are broken (see pics below). I can solve this by simply opening up each CLFN on the block diagrams and then closing them- the VI is fixed and the Run arrow becomes unbroken. So this will solve the problem. But I need to do this for all the VIs in the package which is tedious. Does anyone have any recommendations on how to solve the broken VI problem? To be honest I don't mind the fix I have (opening and closing the CLFN for all VIs) but other users might not like this idea, and sharing decent code is one of my aims in using the RPi (in the Maker tradition).

Open and close CLFN to fix broken VI:

Fixed VI:

** Test panel is a module program,included into PPL.In the attach pic, I am working with 'Module Program Labview2010' that send message or data to PCRs5 through 'Testpanel ppl'

I built an application for someone else, and when the exe was run on their computer, it started complaining about missing vis. I realized this probably meant the "Use LabVIEW 8.x file layout" button got unchecked somehow, so I fixed that and all was fine.

Which started me thinking...  Other than the issue LV 8.x and earlier builds have with vis with the same name, is there any technical reason to NOT use the LabVIEW 8.x file layout when making an executable? I don't use LVOOP, and think it's Bad Programming to have two vis with the same name in the same build (either they have slightly different functions, and therefore have different names, or it's the same vi living in my code reuse tree, or maybe it should be a polymorphic vi, etc).

I'm going thru a big code cleanup push and am wondering if this is something worth the effort of "fixing" in my 2500+ vi and 25+ exe library.

I have an application built in labview 2012 which we have been distributing fine with an installer built in labview 2012 for some time. Recently, a colleague tried to install the application onto a windows 10 machine and although the installation process seemed to go smoothly, for some reason, one of the two exe's distributed by the installer gives me the ever so helpful "This VI is not executable. Full development version is required. This VI is not executable. Full development version is required. This VI is not executable. Full development version is required. This VI is not executable. Full development version is required. This VI is not executable. Full development version is required. This VI is not executable. Full development version is required. ..... (you get the picture!)" error.

As an experiment I set up two clean virtual machines, one running windows 7 SP1, one running windows 10. I ran the same installer on both. In windows 7, I got a prompt saying that .NET framework 4.6.1 needed to be installed first, and that happened automatically, and after that the installer continued and everything worked fine (including the exe in question). On windows 10 I got no such warning. The installer ran through and the exe failed with the error message described above. 

On the Win10 VM, I then went in to "Turn windows features on/off" and although there's a tick in the ".NET framework 4.6 advanced features", there's no specific sign of 4.6.1. for a test, I added a tick to add .NET framework 3.5 (includes .NET 2.0 and 3.0) and installed that. That made my .exe run fine.... 

So.... is there any way to force the LV installer to prompt for/install the necessary .net "stuff" when running in Windows 10? Anything else I can do to automate things so that our customers dont need to manually add .net support for the program to run if they're using windows 10?

Thanks in advance!

Paul

http://forums.ni.com/t5/LabVIEW/LV-2016-Known-Issue-583670-Can-I-really-no-longer-build-for-Win7/td-p/3341369

I initially thought this was new behaviour introduced in VIPM 2016, but downgrading to VIPM 2014 SP2 didn't change anything. I'm now unable to downgrade any further, as my PC is convinced that 2014 SP2 is still installed (even though it's not...)

Could someone kindly try the attached *.vipb file and see if it opens? It's a bare minimum default file, with only a description summary added. I've hand-modified the summary from "Lorem ipsum" to "Larem ipsum" and now VIPM refuses to open it.

Thanks!

Dummy.vipb

• <ProjectRoot>
  • (Project.vipb)
  • Examples
    • Example1
    • Example2
  • Source
    • Cpp
    • LabVIEW
      • LVClass1
        • (Method1.vi)
      • LVClass2
        • (Method2.vi)

The auto-generated Functions Palette is structured like this:

    [Functions] >> [Company] >> [Project] >> Source >> LabVIEW >> LVClass1 >> Method1.vi
    [Functions] >> [Company] >> [Project] >> Source >> LabVIEW >> LVClass2 >> Method2.vi

However, I would like a simplified palette structure like this:

    [Functions] >> [Company] >> [Project] >> LVClass1 >> Method1.vi
    [Functions] >> [Company] >> [Project] >> LVClass2 >> Method2.vi

Is there a way to get VIPM to auto-generate the palette that way? I can think of a few workarounds (restructure my project, or add every palette folder manually) but I'm hoping I don't have to resort to them.

P.S. Sorry if this is the wrong place to post this, but I'm unable to post on the JKI forums

Quick question. I have an old VIPB file for a project and would like to use it for another project. My main interest is to recycle the Palette as I customized it to include a bunch of LV primitives on it. I thought it would be just a matter of saving the VIPB file As another name and change the Source Directory in the Build Information Section. The thing is though, once I change the Source Directory on the new VIPB file, VIPM dumps the old palette altogether and creates a brand new one with the directories that are part of this new Source Directory. Is there a way to reuse the palette from one VIPB file on another one?

I'm looking for an easy button to avoid having to spend hours basically replicating what another package already has.

Thanks!

The application builder puts it there automatically, but I do not know what it is for. If I remove it my application does not run, instead the usual file prompt dialogue pops up when I run the application.

Also, can anybody shed any light on what this file is for? My PC seems to think it is a "MAX Configuration UI" but that does not make any sense either.

Crossposted here.

I'd really appreciate your help with this. I'm trying to write a program that will find all the VIs that are open in the LabVIEW development environment (even if they are different application instances) and analyze their front panels and generate a report about them. I wrote a quick VI just to get started which will tell you the number of controls on the front panels of all open VIs. The problem is that it doesn't work when I build it into an executable. When I run the executable, instead of finding all the VIs open in the development environment, it only finds itself. I attached the code I wrote so far. Could anyone tell me what I how I could make this work from an executable? Thanks!

--Hope

VI Logger.zip

I have a program written in LabVIEW 2015 that works well enough in the dev environment but I'm having an issue when it is built into an application and i can't see why.

I use 3 different DVRs in order to ensure that the data I capture over a CAN bus in my main application is available and correct for use in a sub vi launched in one of the panes of my main Vi. This is with a view to having different sub vi's for different applications.

The DVR's are registered and created in the main vi and I have tried initially using run VI methods and Ctrl Val.Set properties to send the reference value to the vi in question, then i tried using the reference and storing it in a global for the vi to see and in a test case I've tried to pass it directly to a test vi via a connector/control on in  the vi but in all instances, it works in the dev environment but not when in an application.

Does anyone have any advice on whether i have some bad build settings or whether these references cannot be passed between vi's (which i thought was their purpose).

Either way, i've been scratching my head for a while and haven't got anywhere

I found vi.lib\SourceControl\support\SCCSup Compare Two VIs.vi which performs the comparison operation, allows me to specify which types of changes to detect, and returns if there are differences. This is exactly what I need and it works perfectly in the development environment. However, when I build my tool to a .exe file, I get a LabVIEW error with the following description:

Error 1574 occurred at Open VI Reference in SCCSup Compare Two VIs.vi->Resolve False Conflicts.vi

Possible reason(s):

LabVIEW:  (Hex 0x626) Cannot open a file with separated compiled code in the LabVIEW Run-Time Engine.

An error occurred loading VI 'my.vi'.
LabVIEW load error code 59: The source file's compiled code has been separated, and this version of LabVIEW does not have access to separated

Where my.vi is the path to the VI that it is attempting to compare. All of the VIs in my project have "Separate compiled code" enabled since I use version control on them, therefore turning it off it not an option. Is there any way to get around this issue?

I have  plan,to add one new LabView exe program compiled in LV2015 on one PC, where there is already one LabView exe program compiled in LV2011.

Have you ever encounter some problems or limitations with two runtimes running at same time.

Just for detail, I can't upgrade exe 2011 because i don't have sources.

Eric

Now it occurs to me, it could be sensible to check at runtime for the presence of LuaVIEW, and to disable the additional features if that is not found. Not found, presently, just means that some subVIs on the main BD are missing or broken. I figure that it would be rather easy to check dynamically for a Bad status of some VI wrapping a LuaVIEW subVI, and use that as a flag.

The best approximation to what I need, which I could think at, would be to wrap those broken part in a conditional disable structure. But, stock CD structures in the IDE can be conditioned only by bitness/targer/RTE, not by some runtime value (and it makes sense they can't; it's about compilation). Another option coming to mind, would be to create a project for good, with conditional disable symbols, and two different builds depending/independent, but then should I distribute only the builds?

Other options coming to mind look to me more cumbersome. e.g., I don't know, calling all relevant LuaVIEW vis dynamically, thus having them not explicitly on main BD. Or, I suppose plugin library may be the keyword, but then do I have to transform LuaVIEW in a plugin, which is above my head and not my call? Any elegant suggestion?

http://forums.ni.com/t5/LabVIEW/Values-not-passed-to-subVIs-in-builds-in-LV2014-and-2015/td-p/3254123

It now seems like the subVI that isn't working is actually getting all the values passed to it, but for some reason isn't able to generate the return event. That or it is generating the return event, but the event isn't being processed by the run time engine, because there are no errors from Generate Event. We are in the process of upgrading our entire code base to LabVIEW 2015, and we are reorganizing projects and libraries to make it somewhat easier to force inclusions in builds if that's the only solution.

I have a bundled software which has multiple EXE's under one installer.  Commonly I use the installer version number for reference and want to show it up to the user.  Is there any way to get the installer's version number instead of executable's version number?

--Ajay.