Labview executable and Webserver

I'm having a little difficulty getting the webserver to run with a labview executable. (Labview 8.5)
The problem appears to be that the webserver does not think that the vi is running (probably because it is an exectuable).
The message is "Requested VI is not loaded into memory on the server computer".
Here is part of the HTML code:
<PARAM name="LVFPPVINAME" value="Adjustable Wing.lvproj/My Computer/Adjustable Wing.vi">
<PARAM name="REQCTRL" value=true>
<EMBED src=".LV_FrontPanelProtocol.rpvi85" LVFPPVINAME="Adjustable Wing.lvproj/My Computer/Adjustable Wing.vi" REQCTRL=true TYPE="application/x-labviewrpvi85"
The part ="Adjustable Wing.lvproj/My Computer/Adjustable Wing.vi" does not seem right to me - surely this should point at the .exe?
Thanks
Smiler

Hi Smiler,
To use an executable as the source for the LV web server you need to make sure the Adjustable Wing.vi is your main VI (Startup VI). If it is then once you have built the application move the .exe .alias and .ini file to the web server root directory by default <LabVIEW install dir>\www
Once the VI is in this directory open the .ini file and the first line under the [<App name>] should be:
postScriptLevel2=False
WebServer.Enabled=True
If the web server is not a the default location update the entry WebServer.RootPath= in the .ini file
At this point open LabVIEW go to Tools >> Options >> Web Server: Configuration and turn OFF the web server.
Now run the exe from the web server root directory and then open the html page you created before.
Regards
JamesC
NIUK and Ireland
It only takes a second to rate an answer

Similar Messages

Interface between LabView Executables and compiled MATLAB code

Query: Does anyone have experience of calling compiled MATLAB functions from a LabView Executable?

Hello
Well, I am using some applications as you ask. Some calculus was done in matlab, so, now, it is compiled as dll an front end and other calculatiosn are in Labview. matlab dll are registered as activex, and so are called from labview. Integration is so good, tha some old matlab application was changed to Labview and matlab dll.
I must to state that I am not the integrator. My part is only Labview. So, should you have further questions, I can pass this thread to the integrator company. I do not promisse answers.
But it runs fine.
Cheers
Alipio
"Qod natura non dat, Salmantica non praestat"

How to start a LabVIEW executable programmatically.

I created a LabVIEW executable and want to start it programatically from another PC.
I know how to start LabVIEW remotely but not how to handle an application.

If you have NT/Win2k machine, then you can launch labview built exe using DCOM. Here is example that tells you how to do that.
http://zone.ni.com/devzone/devzoneweb.nsf/opendoc?openagent&9208517E41C2B1B18625683A000CB86E&cat=9C6DF90777E5A78206256874000FA14E
Another one
http://zone.ni.com/devzone/devzoneweb.nsf/opendoc?openagent&20346814BACE06BF8625683A000C3C98&cat=46E7994B7483D781862567C300662667
A Rafiq

Convert executable and supporting files to msi

Hello all,
Wanting to know if it is possible, or if anyone has tried, to roll a labview executable and supporting files into a .msi microsoft installer package. Wanting to do this for its auto exection and encryption. I have attempted using third party applications like "Advanced Installer" and Altris wise package studio with no avail. I found the following old post describing this exact problem using a different third party applicaiton and labview 6.1. I am currently running Labview 2011 professional.
http://forums.ni.com/t5/LabVIEW/Repackaging-Labview-using-Veritas-Wininstall-fails/td-p/89442
I know that Lab-windows can be used to package a .msi installer but I do not have access to it nor am I trained to use it.
Just wanting some information, any information, on how to make this happen.

When you built the exe in the project, you should have noticed the option to create an installer. Fully documented in the LabVIEW help.

Read text from a string control in a compiled LabView executable from C#

I have a third party complied LabVIEW executable and no source code. I need to read values from the front panel in C#. I know that LabVIEW controls and indicators are not actual windows. Is there a way to programmatically access this information(i.e. without using screenshots and OCR)? I couldn't find this exact question answered in this forum. I've read a few things about VI Server doing this from LabVIEW, but I don't think you can access VI Server from C#. Any help would be appreciated.
Thanks in advance.

You should certainly be able to access VI Server from C#. LabVIEW has an ActiveX server built in that allows other applications to access a sizeable subset of VI Server functionality. I would guess you could access ActiveX servers directly from C#, but the worst-case scenario would be to wrap the ActiveX calls into a .NET assembly. I've seen this done before. This blog entry is slightly off topic, but might help you.
Actually, I do need to revise this answer... If you are working with a LabVIEW DLL, the DLL would have to be compiled with the ActiveX Server option enabled. Otherwise, LabVIEW won't include the code that allows the DLL to be hooked into using this method. So if you don't have the source and you can't recompile it, you might be out of luck. Does the DLL really not have a function that exports this string value?
Message Edited by Jarrod S. on 10-26-2006 01:39 PM
Jarrod S.
National Instruments

How to Exchange Data and Events between LabVIEW Executables

I am having some trouble determining how to design multiple programs that can exchange data or events between each other when compiled into separate executables. I will layout the design scenario:
I have two VIs, one called Status and the other Graph. The Status VI displays the serial number and status of each DUT being tested (>50 devices). The Status VI has one timed loop along with a while loop that contains an event structure. If the user clicks on the DUT Status Cluster the event structure needs to pass the serial number to the Graph VI. The Graph VI when called fetches the records for the DUT based on the Serial Number and time frame. This VI is a producer/consumer so the user can change the time frame of the records to display onto the front panel graph.
I have a couple reasons the VIs need to be separated into independent applications. One being the underlying database fetches tends to slow the threads down between the two VIs; the other is that they may be distributed into separate systems (don't consider this in the design criteria).
I have been researching the available methods to pass the serial number to the Graph VI. My initial idea was to us a command line argument, but this does not allow the Status VI to pass another Serial Number to the Graph once it has started (I do not want to allow the user to execute multiple Graph applications because the database query can load down the server).
Is there a program method that I can implement between the two VIs that will allow me to compile them as two executables, and allow the Status program the repeatedly send an updated serial number event to the Graphs program.
I have reviewed many methods; Pipes (oglib_pipe), Action Engine, and Shared Variable. I am not sure which method will give me the ability to use a Event driven structure to inform the Graphs program when to update the serial number. Any suggestions and tutorials or examples would be greatly appreciated.

I have used the Action Engine (aka: functional global) approach for many years and it works well. Something to think about is that if you make the event's datatype a variant the only code that will need to know the actual structure of the event will be the function that needs to respond to it. Hence, a single event can service multiple functions.
Simply create a cluster containing an enum typedef that is a list of the functions that the event will service, and a variant that will be the function event data. From anywhere in the code you can fire the event (via the functional global) by selecting the function from the enum and converting function specific data to a variant. On the receiving end the event handler uses the enum to determine the function that is to get the data and sends the variant to it. The event handler doesn't know or care what the actual event data is so you could in theory add new functions without modifying the event handler.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Create an API to Launch an LabVIEW Built Executable and Pass it Input Parameters

Hello,
I'm looking for a way to create an API to Launch/Close an executable, created with LabVIEW, which in additional to Launching/Closing tht executable, will also allow me to pass input parameters.
To give you some background, I'm working on a logging utility, basically a background dameon, which I currently have implemented as a LabVIEW packed library and my API is a few VIs to launch that daemon and pass it a filename and a logging rate. Functionally it works just fine however is executes within LabVIEW not as an independent process. So instead of using a packed library, I would like to compile my logging daemon down to an executable but I still need a way to launch it and pass it parameters from an external application (such as Teststand).
I know you can launch executables and pass parameters using windows command lines, but I'm wondering if there is a more direct method such as a DLL that I could call in Teststand? Thanks.
Post CLD and when I'm a CLA when someone asks who I am, I can spin around in my chair and say "I am... the architect."

When Teststand Launches the Logger, it does so by opening a reference to the logger daemon using the "Open VI Reference" primitive and then it launches an instance of the dameon using the "Start Asynchronous Call" node.
This currently, launches the logger within labview not teststand. If I were to directly call the logger daemon VI itself as a step in TestStand, then it could run in a new teststand thread. At that point I would need a way to stop that logger which I should be able to do by storing a reference to its control queue within the teststand thread that it is running in. Since teststand let's you specify VI execution in the runtime engine instead of LabVIEW that might do the job.
The one catch is once the sequence completes, the logger does some cleanup, post processing, etc that depending on the amount of data captured can take some time so if a set of sequences needs to be executed, this could hang up teststand until that post processing is completed. That is one reason why I wanted it to execute outside of testtand so that additonal sequences could continue to run while the daemon finishes up in the background.
But, it's something I'll have to look into.
Post CLD and when I'm a CLA when someone asks who I am, I can spin around in my chair and say "I am... the architect."

Rshd and LabVIEW executable

Hello,
I have a LabVIEW executable built from LabVIEW Pro 2012. The executable executes without error normally. I now need to remote-execute it from a Windows 2000 networked computer. The labVIEW executable resides on a Windows 7 Pro (32-bit) computer peer-to-peer networked to a Windows 2000 computer. I have the latest rshd binary in the "system32" subdirectory on the Windows 7 computer and am using the native rsh client that comes with Windows 2000 on the Windows 2000 computer. The executable and it's front panel come up OK on the Windows 7 computer but the executable asks for the location of several DLLs. If I take the time to navigate to the DLLs the executable proceeds OK. I have added the path of the DLLs to the Windows 7 environment path but the executable still asks for their location. Is there any way to "add" the external DLLs to the LabVIEW executable build so they will be found at remote execution startup? The daemon on the Windows 7 computer is started at login via batch file that contains rshd -d -r.
Thanks in advance
Tim
Solved!
Go to Solution.

My apologies for this post. It’s been so long since I worked with things like the system variables and system path. I "thought" I had added the subdirectories of the required DLLs but I had set environment variables to each of them and then used the environment variables to append the system path. When I finally opened another CMD window and did an echo of the path I saw that the path had the literal variable names appended not their contents. I added the actual paths and nor the LabVIEW executable finds everything OK.

I'm trying to execute and possibly terminate a PERL script from Labview.

I am currently using the system exec.vi to run my perl script. I would like to be able to terminate it as well. Any suggestion?
I'm running from windows xp.

Try looking at http://www.jeffreytravis.com/lost/labperl.html
The download (LabPerl) gives you comms between Labview ' Perl and viceversa.
And doesn't take too long to fathom out how it all works.
The perl program is set running (manually or by labview command window - don't wait for completion) followed by labview control etc.
N.B.
Each labview write string requires a Linefeed - then chomp at perl end
The secret is to have a good handshake method - each LabView read returns to perl an "ok"

Improving load times in Linux LabVIEW executable

I'm looking for (simple) ways to improve the loading times in a Linux LabVIEW executable. We're using a low performance, low cost CPU board, and loading times are terrible. The CPU is capable of doing everything after the application is loaded, but takes forever to get there.
One of the problems is the size of the executable, that grows everytime you just look at it. Are there ways to create smaller executables? It runs from a Compact Flash card, which is ofcourse much slower than hard disk.
Another problem is a dynamic vi, that is started for every TCP connection that connects to the application. It takes a long time to load, and connecting too fast can even effectively hang up the system. Starting a handler task takes about half a second, up to a few seconds for the first task.
We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.

Dennisvr wrote:
I'm looking for
(simple) ways to improve the loading times in a Linux LabVIEW
executable. We're using a low performance, low cost CPU board, and
loading times are terrible. The CPU is capable of doing everything
after the application is loaded, but takes forever to get there. One
of the problems is the size of the executable, that grows everytime you
just look at it. Are there ways to create smaller executables? It runs
from a Compact Flash card, which is ofcourse much slower than hard disk. Another
problem is a dynamic vi, that is started for every TCP connection that
connects to the application. It takes a long time to load, and
connecting too fast can even effectively hang up the system. Starting a
handler task takes about half a second, up to a few seconds for the
first task. We're using the LabVIEW 7.1 runtime, system is a 300 MHz cyrix SBC, running from a Compact Flash.
I'm
not sure about the first part of your question. LabVIEW is highly
binary and does a lot of memory allocations before even one VI is ready
to be started. So maybe the memory manager is a problem. Another issue
is that the Macintosh like resource file format that is used by LabVIEW to store its VIs etc. results in
lots and lots of individual disk accesses with a rther random like
character inside a single file. So if you can configure the read
caching of your disk to use more memory this may significantly increase
the speed of loading LabVIEW VIs or applications.
And finally spawning VIs through VI server is a rather costly operation
especially on low resoruce systems. A VI is more like an executable in
many ways as far as resource consumption is concerned rather than a
thread. A much better way would be to avoid spawning subVIs altogether
and implement a queued TCP/IP server similar to the Date Time Server
example. It is a little extra work to work with this shift register
architecture but it will not have the issues of long load times for
every new TCP/IP connection coming in.
Rolf Kalbermatter
Message Edited by rolfk on 03-07-2006 06:33 PM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Open VI Reference to a LabVIEW executable.

Hello,
I haven't done this for a while and it's not working like expected. I'm trying to "Open VI Reference" from executable A.exe to B.exe. I'm trying to get a control value from B.exe in A.exe. Can someone send me an example?
Right now I'm at this stage: I have A.exe running as a LabVIEW executable. I'm trying to "Open VI Reference" to A.exe from LabVIEW development without success. Not sure what I'm doing wrong.
Don't hesitate to ask more info if you need some.
LabVIEW 2012, Windows 8.1.
Thanks,
Michel
Solved!
Go to Solution.

Bob_Schor wrote:
Once you have an Executable, does it matter that the underlying Development system is LabVIEW, rather than (say) Visual Studio, or Matlab? I suppose you could write an application that "knows" to, for example, listen to a TCP/IP port and interpret/execute commands, but that doesn't sound like the question being asked.
BS
LabVIEW-built executables still run as VI's in the RTE, though. Their identities have not been abstracted away into one single object or anything, and they still have name-based VI server access.
You can configure a build specification to include almost nothing, and require the VI files to be present in expected locations (i.e build specification's data or support directories). By default, all items in an executable application build specification are set to be put in the same location as their caller, which results in most things going into the .exe file, internally referenced in a directory-esque form like crossrulz mentioned, "MyExecutable.exe\MySubVI.vi".

Is it possible to call a VI that is inside a LabVIEW executable from a TestStand sequence?

I have created a custom TestStand operator interface and have modified the default sequential process model to display a UUT information dialog that prompts for more information than just the UUT serial number. This UUT information dialog is a LabVIEW VI. To distribute the operator interface, I build it into an executable. As part of the build process, I make a copy of the UUT information dialog VI (which is part of my operator interface project) and place it in the same folder as the executable. I have then configured the sequential process model to call the dialog VI from this location. It would be really nice if I could embed the UUT information dialog VI inside the operator interface executable so that I could distribute just an executable instead of an executable and separate VIs. Is this possible? In other words, is it possible to call a VI that is inside a LabVIEW executable from a TestStand sequence just like a standard LabVIEW VI call?

Ryan,
The dialog that you've created isn't being directly called by the OI at all and shouldn't need to be included in the same directory as the OI for distribution. Since you are modifying the PreUUT of the default process model, you will give the path to the VI in that step, create a deployment and then manually copy the VI to the directory referenced in the step. The VI is considered a support file for the process model and is not related to the OI at all.
Test Engineer - CTA

How can I run a labview executable file inside a VI

How can i add and run a labview executable file inside the vi and grab the output of the executable file to be used in the vi?
mytestautomation.com
...unleashed the power, explore and share ideas on power supply testing
nissanskyline.org
...your alternative nissan skyline information site

Hi cmdrb,
to run an executable you use SystemExec function.
To get the output of your (LabVIEW-made) executable you need to program some data transfer means: you may use network functions or file functions. In both cases your "LabVIEW executable" needs to provide that options…
Best regards,
GerdW
CLAD, using 2009SP1 + LV2011SP1 + LV2014SP1 on WinXP+Win7+cRIO
Kudos are welcome

How can I call a LabVIEW executable from within another LabVIEW executable?

I have a customer requirement for two LabVIEW executables. Based on their current setup, they need to run executable "A" or "B", both of which are under independent revision control. I have created a third "selection" executable that allows the operator to choose between one of the two, but I am receiving errors when I attempt to call a LabVIEW executable from within a LabVIEW executable using either the "System exec" VI or the "Run Application" VI. If I call a non-LabVIEW executable (such as Windows Explorer) everything works fine.

> I have a customer requirement for two LabVIEW executables. Based on
> their current setup, they need to run executable "A" or "B", both of
> which are under independent revision control. I have created a third
> "selection" executable that allows the operator to choose between one
> of the two, but I am receiving errors when I attempt to call a LabVIEW
> executable from within a LabVIEW executable using either the "System
> exec" VI or the "Run Application" VI. If I call a non-LabVIEW
> executable (such as Windows Explorer) everything works fine.
As with the other poster, I suspect a path problem. You might try the
path out in a shell window, and if it works, copy the complete absolute
path to LV to see if that works. LV is basically passing the comma
nd to
the OS and doesn't even know what is in it, so you should be able to get
it to work.
The other poster commented on subpanels, which is a good suggestion, but
without going to LV7, an EXE can have open more than one VI. You can
use the VI Server and the Run method to fire up another top-level VI.
The decision is whether you want both to be in unique processes.
Greg McKaskle

Control where a LabVIEW executable write it's Settings Configuration file

Is there any way to control which directory a LabVIEW executable writes it's configuration settings file to? I am using version 7.1.

I believe the INI file must be in the same directory as the executable. You can use the keys found in the LabVIEW.ini file and they will apply to your executable without any special programming on your part. That being said, you can always create a custom settings file or files anywhere you like to store configuration information specific to your application.
If we could specify some other path for the executable settings file, it would probably hurt more than help in the long run. The same directory as the executable is the only one whose existance you can be sure of..... or of whose existance you can be sure.
Dan Press
PrimeTest Corp.
www.primetest.com

Labview executable and Webserver

Similar Messages

Maybe you are looking for