Search the Community

Hello, I would like to generate a manifest to modify the configuration of an executable so that it launches as administrator. For that I followed the LabVIEW link : https://www.ni.com/docs/fr-FR/bundle/labview/page/lvhowto/editing_app_manifests.html However the command "mt.exe -inputresource:directorypath:applicationname.exe -out:applicationname.manifest" given by LabVIEW does not work for me. When I run the command: "C:\Program Files (x86)\Windows Kits\10.0.22621.0\x86\mt.exe" -inputresource: "C:\Users\user_name\Desktop\exe\Installer.exe" -out:Installer.manifest Here is what I get: Microsoft (R) Manifest Tool Copyright (c) Microsoft Corporation. All rights reserved. Thank you for your answer Translated with DeepL

Hello, I would like to know if it is possible to launch an executable via a VI and if it is possible to launch it as an administrator ? Or if it is possible that the VIPM launches my VI as an adminitrator after the installation of a packet ? Thank you for your answer

Hello, I wrote a LabVIEW program to communicate with a hardware sensor using vendor-provided LLB and a DLL files. The program runs fine on my workstation both from LabVIEW IDE and from a compiled executable. The problem starts when I copy the entire executable folder to a target host without a LabVIEW IDE (only with a runtime engine). The application opens with a broken Run arrow and a "missing external function" error message appears for every function call I made to the DLL (see attached). 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!

Hello all, I am looking for a way to find controls on an executable LV program. I need this function because I want to automate a series of tests (user mouse clicks for example) on an executable LV program. The normal tools who does it with windows objects are not able to recognize LV controls individually. My idea is to find a way to recognize LV controls so I can interact with them individually. If anyone knows any third party programs to do automation tests for a LV exe that would also be highly appreciated. Best Regards, Vlad

I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help. When trying to execute or call the LPR.exe from System exec VI, I'm receiving error: "'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file." Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem. print.vi

I wonder if someone ran into this and has a good suggestion about. I have a DSC project, in which it looks just right to organize hierarchically my shared variables. Like, e.g. Now this is easy to do programmatically, see the attached project. The problem arises when building an application. It would look as if the plain way to do it, would be to create a build specification which includes the additional libraries, and select their deployment in the "Shared Variable Deployment" tab. However, this doesn't seem to work for nested libraries as in my example. The only possibility seems to add in "Always included" each of the contained libraries. But by doing like this the hierarchy is flattened. If I include like this, then the variables within the container library are not deployed at runtime. In my example project: open the project in the IDE, run DeployAllSharedVariables.vi, then CheckDeployed, and see the result (all four variables found with their nested paths) build and run DeployFlatLibraries and see the result: four variables, but flattened paths build and run DeployHierarchicalLibraries: only the two variables in the unnested SimpleVariableLibrary are there. I've searched a bit, and only came up with this document, which (for >2009) says "just check the checkbox". Nor the help page says much either. I wonder if I can do what I'd like only compiling separately the libraries, and loading them programmatically afterwards, both in the IDE and in the exe. Which probably is sane, but inconvenient for the first attempts. TestDeploy.zip

So, according to this NI document http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/linking_vis_to_help_files/ It should be possible to link a .chm file into your executable so that a user can choose Help > Help for This VI. Well, I followed the advice, and no dice. Here is my LV2017-64bit attempt. In the development environment, it works fine, but in the executable Help for This VI is grayed out. The .chm file is a poor excuse, and unrelated to this VI, but never mind that, it's not the problem here. LV17helpEx.chm html_help_VI.vi test_help_html.aliases test_help_html.lvlps test_help_html.lvproj

Bonjour, I use Labview 2015 32-bit on a 64-bit Win& pro computer. My application connects to Hardware using NI-VISA and NI-DAQmx only (Two RS232 communications via a VCOM port and one NI DIO card using DAQmx). Until today, I was building an executable which I was copying through the network on another win7 pro machine in the lab next to the hardware. It was working fine with Labview Runtime 2015 installed on this machine along with NI-VISA and NI-DAQmx. I never used an installer, I installed those 3 components seperatly. Yesterday I added some features to the application and the EXE won't start. I have an error msg saying "The VI is not executable. The full version of Labview is needed to fix errors". The machine in the lab can't run the EXE but the EXE won't even start on my development machine. My previous EXE from last week still works fine. The code works fine with all new features if I run the main VI from the development environment. I've double check all of my licences status. If I open another project and compile the EXE, I am able to run this EXE (I use a complex app containing almost all the same software components) If I build an EXE with a different UI source file part of the same project, that EXE works fine. If I build the EXE from my previous version again, it works fine too. I tried removing all the new features I had added in the project and build the EXE again and I still get the error. I tried creating a new project file and import the same librairies to try building an EXE from a fresh project file and I still get the error. I tried installing Labview 2015 on another computer and try to build an exe from a fresh labview install on this computer and I get the same error. The development machine can't execute the compiled EXE) It has to be related to the code but, I can't roll-back and get functionality of the EXE again unless I totally replace all of my files from a backup made last month. The most recent posts I read from a similar error are from 2013 and later. And the problem described is always that the EXE does not work on the deployment machine but works fine on the development machine. I must be at version 25 of this application to which I add improvements on a regular basis since almost 1 year. I am really puzzled. Is there a way to analyse or get more info about the broken EXE error? All the new features I added are using components that were already present in the project and in the main VI. The new features are important, I'd really like to use this working code with the hardware as soon as possible but I don't really want to install labview on the development machine. Any ideas? I don't know what to try next. What would be the best information to provide / look for for the next step? Thanks to all in advance Nien

Hi, I would like to associate icons with file types that are handled by a LabVIEW built application. To do so, "defaultIcon" key has to take a value of executable path with parameter "resource ID". The question is how to build in more than one icon with executable? Examples of LabVIEW keys: -library: ..\LabVIEW.exe,-8 -llb: ..\LabVIEW.exe,-3 Is it even possible with app builder? Any workaround?

Hello to all. First I explain my environment and then I will ask the question. PC 1 (development PC): intel i5, windows10 64bits, 8GB Ram, Labview 2015 SP1 (32 bits), Vision Adquisition Software 2015, Module Vision 2015, DSC 2015, ni OPC Server. PC 2 (deployment PC) : intel celeron 1.99 GHz, windows 7 64bits 8GB Ram, Labview 2015 SP1 (32 bits), VIsion Adquisition Software 2015, Module Vision 2015, DSC 2015, ni OPC Server, Run Time Engine 2015, VIsion Run Time 2015. PC 3 (deployment PC) intel Atom CPU N2600 1.40GHz, windows 7 64bits, 4GB Ram, Labview 2015 SP1 (32 bits), VIsion Adquisition Software 2015, Module VIsion 2015, DSC 2015, ni OPC Server, Run Time Engine 2015, VIsion Run Time 2015. I use the next in my aplication: 2 cameras GigE Lan connected to PC. A PLC connected RS232 through ni OPC server and about 15 shared variables. In development environment my application works well. In PC 2 a executable of my application works well. But the problem is that the same executable works bad in PC 3. Front Panel is slow and displays of image cameras don't refresh the image well. So all my application is slow in PC 3. What can it be? I don't think that it could be the specification of PC 3 but I don't know... Does anyone fix something similar? Any help will be appreciate it. Thanks a lot.

Hello to all. 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!

I use SVN for version control in my project and am often faced with many conflicted VIs that must be dealt with. I have found that frequently, the changes causing these conflicts are not "real" changes (for example, a wire was moved or a typedef for a cluster control was changed). So, I am trying to create a tool that queries my project directory for any VIs that have conflicts, and running the VI Comparison tool with only non-cosmetic changes enabled to automatically find VIs that don't have any "real" changes and marked the conflicts as resolved. I would like to build the tool into a .exe because I would like to be able to run this tool from the command-line so that I can create a right-click menu item in my Windows environment to easily run the tool from any folder containing conflicted files. 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?

Hi all, Have you see these Windows PCs on sticks?? http://www.amazon.com/gp/product/B00RVCGNEC/sr=8-1/qid=1422529141/ref=olp_product_details?ie=UTF8&me=&qid=1422529141&sr=8-1 http://liliputing.com/2015/01/intel-compute-stick-149-pc-stick.html I would love to know if anyone has tried running Labview Executables on them and if they have ran into success or trouble? Of high interest to me would be serial communications using serial adaptors. Im still not sure if this is possible with this class of PCs. cheers Puya

Hi, I have some applications (executables) made by several VIs and when they start, users see "loading in progress" window which displays VI's names. This is a typical behavior of LabVIEW, that other languages don't have. Is there a setting to hide/disable that window? Thanks, Claudio

Hypothetically, if one created a LabVIEW executable that used a remote application reference to interact with the LabVIEW IDE, how much of the scripting function set would work? I've already discovered "New VI" doesn't work, but what about the non-creative functions, such as programmatically showing a block diagram, traversing the block diagram, inspecting nodes and other objects etc.? It seems to me that it should be ok to perform inspection, just not manufacture, right? So why are a load (if not all) of the scripting methods denied when attempted from a remote interface?

This topic has come up a few times, mainly http://lavag.org/topic/13990-1502-error/?hl=1502 and http://lavag.org/topic/12461-strange-error-in-application-generating/?hl=1502. I just got hit with this issue today and will post what I found in case it will help somebody else. I recently upgraded to LV2013, and converted a large project I'm working on. Upon attempting to compile the executable, I was hit with the 1502 error with a particular VI. This had not ever happened with 2012, and the offending VI had no errors and ran fine in the development environment. Like others had reported, enabling debugging or disabling "Remove unused members of project libaries" in the build specification allowed the file to compile correctly. I figured this was some problem in LV2013, so I back converted to LV2012 and tried to recompile. Got the 1502 error again. After removing my fist from the monitor, I started to take a closer look at the offending VI. The offending VI had a subvi where I had inadvertently left a case structure with a constant wired to it. Inside of the unexecuted case were some unused LV Analysis Vis. For some reason, these were causing a problem in the compile. After removing the useless case structure and the unused VIs, everything worked fine. In one of the threads someone had mentioned broken code inside a diagram disabled structure causing problems, but I've never seen anyone mention working code inside of an unexecuted case statement. Hopefully this will help somebody who's having the same problem.

Have a look to this brand new toolkit for LabVIEW if you are interested to distribute LabVIEW executable with advanced licensing, automatic update capabilities and a lot more amazing features. BLT for LabVIEW (Building, Licensing and Tracking) http://sine.ni.com/nips/cds/view/p/lang/en/nid/211731 BLT for LabVIEW is a stand-alone program you can use to distribute LabVIEW applications for commercial use in a few clicks. License your own LabVIEW application in a few clicks - no coding required Automatically (and remotely) update your applications when you make changes in your LabVIEW code Automate the build process for your LabVIEW executables Get user activity reports and error logs so you can remotely debug your program Use BLT scripting to remotely execute actions on a deployed computer, e.g., update LabVIEW RT Engine Disable parts of your code with features definitions

Hi All, This is my first post on LAVA, so here it goes: I am creating an application that involves reading data on two RS-422 serial ports. Everything was going just dandy until it was time to build my application into an executable. I've spent time debugging my issue and have been able to narror down where the source of the error is coming from, but I can't figure out why it's happening or how to fixt it. I created a simple VI that clearly demonstrates the error. The VI first configures two serial ports using VISA. It then gets the number of bytes at the port and reads from VISA resource in a loop. Finally the resource refs are closed. Before building into an executable (development mode), everything works fine. When I build this single VI into an executable, there are errors anywhere there is an Instr Propert Node. The error code is -1073807246 (which I can't find anywhere). Does anyone know why I'm having this issue? Is this some sort of dependency issue? Maybe I'm not really including some VISA functions in my dependenices? Serial Read.vi

I try to build an executable out of a program that is fully functional under the development environment (LabVIEW 2011, Linux). The executable complains that one of asynchronously launched VIs is bad because one of its components cannot be found. The VI does not invoke any sub-VI dynamically. To identify the problematic sub-VI, I use the following code: A new executable was build including this code and the VI under investigation. A run results in the following error: Possible reason(s): LabVIEW: File not found. The file might have been moved or deleted, or the file path might be incorrectly formatted for the operating system. For example, use \ as path separators on Windows, : on Mac OS X, and / on Linux. Verify that the path is correct using the command prompt or file explorer. VI Path: /opt/***/Builds/Debugg/Debugg_GetDependencies/SubVIs/*** - Plots & Parameters.vi/0 Built Application or Shared Library (DLL): Make sure all dynamically loaded VIs were properly included in the build specification for the application or shared library. LabVIEW Real-Time: VIs built into executables cannot be accessed through VI Server calls. Use Source Distributions to dynamically call VIs on Real-Time targets. /opt/***/Builds/Debugg/Debugg_GetDependencies/SubVIs/*** - Plots & Parameters.vi/0 The same mysterious path is indicated in the indicator "Array" with Execution State “Bad”. The corresponding name in the indicator “Dependency Names” is “*** - Plots & Parameters.vi:Instance:0”. So, I tried to run the same debugging code under LabVIEW development environment and got the same error (while the program works without any complains under LabVIEW). What could be the reason? Had any of you solved such a problem? Thank you

Shortly: We desperately need a good hint on principles describing how an Application (EXE) build interacts with Source Distribution build(s). Descriptions found in ni.com and generally in Internet mostly advise “use Source Distribution” not saying “why”. It works perfectly with simple test projects but is not sufficient for our real needs. Please advice where the general principles can be read. Details: There is a framework code (GOOP4 that means that all problems should be the same with build-in LVOOP). The framework dynamically invokes VIs. The dynamically invoked code also has OOP architecture. A perfect architecture would be creating the framework EXE and keep the dynamically invoked code as loose VIs in HD. However, it does not work. The framework EXE claims that the VIs are broken (while they are not). The common advice is deploying the VIs as a Source Distribution. However, this does not work too. If controlled with a property node “Execution state”, such a VI does not show the result “Bad” but an attempt to start it results in an error. I guess that the problem could be in the fact that some classes are used both the framework (the EXE file) and in the Source Distribution. However, I have no idea how these two builds interact with each other deciding which copy should be used. Unfortunately, error numbers that are shown are poorly described. So far we could guess only that the problem is in finding some sub-VIs. Thank you for reading to the end

Anyone seen this before? Please explain what is in the red circle. Im having a problem: webserver can not start after running my exe After many builds I found that It is come down to one little vi that i used: Inverse matrix as shown in the attachments. If i open this vi for the first time it shows: localhost as shown then i close it, reopen the vi again and it is now changed to: my project/My Computer as shown I dont understand, can you explain? This is the main cause of the error that i have as attached. (i know this because if i remove this vi, my exe runs fine!)