DocumentRoot in niwebserver.conf (LabVIEW 2009)

I'm using the LV2009 built-in web server and trying to pick my way through building a stand-alone application. So far I have done fairly well, but I have some questions regarding directives in the web server configuration file. There seems to be some conflicting information in the forum regarding the path directives, so I'd like to pin it down here.
The two posts I found that seem to relate to this directly are:
http://forums.ni.com/ni/board/message?board.id=170&message.id=434722#M434722
http://forums.ni.com/ni/board/message?board.id=170&message.id=393057#M393057
So, can the path used for DocumentRoot be relative? And if so, relative to what?
Ideally, I'd like to have this relative to the configuration file (this seems to be indicated in the first post above). However, it may be that the path is relative to the web server engine itself (as inidicated in the second post).
Thanks for any clarification!
James
Solved!
Go to Solution.

Hi James,
I believe that your first link to the post by NathanK is correct. He says there that "In 2009 all relative paths in niwebserver.conf are relative to the location of the config file itself." So the path can be relative, and relative to the path of the webserver.conf file.
I think that the difference in his two posts is because the post in your second link is talking about LabVIEW 8.6, while the post in your first link is about LabVIEW 2009, along with information about the differences between the two versions.
Regards,
Stephen S.
National Instruments
Applications Engineering

Similar Messages

$LVSERVER_ROOT in niwebserver.conf (LabVIEW 2009)

Hi!
I'm trying to figure out how to get remote panels working in my built applications programmed in LabVIEW 2009.
I followed this guide for LabVIEW 8.6:
http://digital.ni.com/public.nsf/allkb/7F95D43D3F50FCAC8625710E000068E1
It looks like the niwebserver.conf file has some new features. One that I'm curious about is this $LVSERVER_ROOT. I can't figure out where this points to, and how I change this variable. Is this something I can set somehow if I make an installer?
It it adds more flexibility for me to make a generic niwebserver.conf that requires less modifications on each of my target hardware platforms, then I'd like to know more about it so I can use it instead of entering in hard directory paths. I just can't find any documentation on it.

Hi,
what have you added in the ini-File? I've also problems with my webserver on my cRIO 9022. What have changed in LV2009? I've attached the ni-rt.ini
and also the niwebserver.conf (only renamed in the attachment). When I open the rt-device on the webbrowser I don't get any response - webserver is not running. Any suggestions?
Regards,
Joachim
Attachments:
ni-rt.ini ‏5 KB
niwebserver.ini ‏1 KB

LabVIEW 2009 - Executable w/ Remote Panels

Just hit a wall.
I'm want to make an installer that sets up the remote panel webserver and document for me. My goal is to not have to tweak or move setting files, or my html files around to get this to work. I can get it to work, but only with a little bit of tweaking.
Here is the krux of the problem (and I will get to the details of my setup after that):
I can't place my document.html that contains my web page with the remote panel in the appropriate folder automatically using the "Source Files" tree in my installer. See the attached image.
Within the niwebserver.conf file that my application creates (because my custom .ini file has WebServer.Enabled=True) there is a variable $LVSERVER_ROOT.
This variable points to:
$LVSERVER_ROOT = "C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\2009\webserver"
The default documentroot (where the .html files go) is:
DocumentRoot "$LVSERVER_ROOT/../../www"
Which resolves to:
"C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\www"
Seems somewhat trivial.
1. Make a custom .ini file for my compiled program that has the WebServer.Enabled=True, add it to my project and set it as the .ini file for my build specifications.
2. Make a .html file using the Web Publishing Tool, and add it to my project.
3. Have my .html file placed in "C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\www"
The closest alias for this is [LV90RTEDIR] which resolves to C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\LabVIEW 2009\. But I can't seem to figure out a way to select the directory above. I suppose I could make the file path in the [ProgramFilesFolder], but what if the user decided to place the run-time in some other folder (can they even do that?).
How should I resolve this? Should I just hard-code the path from the [ProgramFilesFolder] directive onward?
Thanks!
-nic
Attachments:
My Installer Properties.jpg ‏69 KB

Hi mishkin,
I will have a read through your linked article. However, I was able to get the installer to setup everything for my target computer w/o me messing with config files as desired. The steps I followed were:
1. Code a desired VI and place it in a Project
2. Create a custom .ini file with the line "WebServer.Enabled=True". Add the .ini file to your project.
3. Create a Build of the VI, with the custom LabVIEW .ini
4. Use the web publishing tool to generate a .html file for the VI. The .html file will be placed in the root of your LabVIEW web server folder (see options dialog). For me this was C:\Program Files\National Instruments\LabVIEW 2009\www. If you study the .html file, you will see that it would not be difficult to make your own .html file.
5. Add the .html file to your project. (As a pre-step, I like to copy the .html file out of my web server root and into my project directory).
6. Build your application
7. Create an Installer. Add the application build of your VI to your desired directory. Place the .html file in [ProgramFilesFolder]\National Instruments\Shared\LabVIEW Run-Time\www
8. Build your installer
9. Install on target machine
So long as your target machine doesn't have another web server running on port 80 (which would require the need of an additional config file to be included to put the web server on another port), and the target machine's local group policies and firewall allow it, a user should be able to open their browser and point it to http://<targetmachine>/<targetvi>.html and be connected to that front panel.
NI has come a long way in making this feature very accessable. My only complaint is the lack of documentation. Although v8.5 and 8.6 were well documented, the steps in v2009 have changed and I had to figure them out through trial and error.
Now I need to add to my code that will allow my user to turn on and off the web server.

Favor to ask : can you open this labview 2009 Vi and save it for me in a Labview 8.6 readable vi ?

Hi guys,
I have a favor to ask : May somebody would be nice enough to open this Labview 2009 VI and save it in a Labview 8.6 readable VI ? You'll probably have some missing blocks cause I use specials ones but I don't want to have to re-make all the VI.
Thanks you very much
G.
Solved!
Go to Solution.
Attachments:
Control3.vi ‏29 KB

notimperial wrote:
Probably not the right place to do this, but could someone onpen this in labview 2010 and save it in a format compatible with labview 2009?
Thank you in advance
You are right we have a thread for this here.
http://forums.ni.com/t5/LabVIEW/Downconvert-VI-Requests/m-p/1067229
Here is your vi please use the downconvert thread next time.
Tim
Johnson Controls
Holland Michigan
Attachments:
WFMreaderIII.vi ‏53 KB

Run-time engine problem in Labview 2009 and Labview 2010

I have a problem with Labview 2009 and Labview 2010. I updated my Labview 2009 into 2010. But it turned out to be a trial one, because i did not have the serial number. So I uninstalled the Labview 2010. however, the funny stuff came over. I cannot use my Labview 2009. So i uninstalled Labview 2009 again. But eventually, I could not reinstall Labview 2009. Every time i had a runtime error and i could not proceed with the installation. in addition, any installation related to Labview is not permitted and the same error came up every time. it is very annoying.
So, What is the deal?
I attached the error here. Any comments or advice are welcomed and appreciated.
Attachments:
error.docx ‏2305 KB

By chance is this machine's language set to any non-English locale? You would check the locale setting by:
Opening Control Panel.
Opening "Regional and Language Options".
Looking Under "Regional Options" >> "Standards and Formats"
If it is set to something besides English, trying setting it to English and please report back what locale it was set to (or if this even solves the problem).
Regards,
- WesW

Potential Bug with LabVIEW 2009, Report Generation Toolkit, and MS Office 2003

We have discovered an issue with the above listed software. Specifically this pertains to Print Report.vi in the Report Gen palette. Basically, we have discovered that with Office 2003 installed the VI will error out. We've been using it in an executable, and the executable physically fails (and asks us to report an error to Microsoft). With Office 2007 we don't have a problem. We've tried building the examples into executables, and those work because they are printing HTML reports.
Also, we have converted back to LabVIEW 8.6 and rebuilt the executable and installed and it works perfectly. Its on the combination of LabVIEW 2009 and Office 2003 that seems to fail.

yeah, we had seen that, and been told about it by another user. we tried, to no avail. we still have ended up having to migrate back to 8.6.1 to get the executable to run properly.

LabVIEW 2009 crashes at startup with the presence of a certain CRT version on the system

When installing our LabVIEW integration package on a system running
LabVIEW 2009 LabVIEW will crash at startup afterwards. Using 'dependency
walker' reveals, that 'nicont.dll' causes this crash because of a
side-by-side configuration problem. After some debugging I found out
that on this particular system installing a certain version of the
Microsoft CRT will stop LabVIEW from functioning. My fix now is to
recompile our code with a newer version of VS. I now ship a VS9 version
of the runtime and everything is working as expected.
However
I guess the real problem lies within the LabVIEW installer. I guess a
needed version of the CRT is not installed by LabVIEW. It still works
because due to some policy files on the machine it gots defaulted to a
compatible version at startup. However when I install the following 2
merge modules on the target system LabVIEW does no longer work:
Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.762)
policy_8_0_Microsoft_VC80_CRT_x86.msm (file version inside: 8.0.50727.4053)
Renaming
the *.policy file in the SxS dir on the target system gets LabVIEW back
to run, but of course other SW needing this file does not run then
I was using XP, 32 bit SP 3
I can provide additional information if needed. Is this a known problem? Is there a fixed version of LabVIEW already?
Message Edited by anotherStefan on 02-05-2010 05:44 AM

Sure! I tried to attach the installer causing the problem to this message.
However I failed miserably(BAD GATEWAY from the upstream server). Where can I upload the installer to or what do I need to do?
It will install some other stuff as well (A bunch of VIs, a DLL and an
OCX(this needs the CRT I have trouble with)and the CRT and MFC runtimes I
mentioned. An updated version of the installer can be obtain here(however it does no longer show the issue):
http://www.matrix-vision.com/functions/count.php?url=products/hardware/family/SC/mvBlueFOX/LabVIEW_a...
The only difference between the two packages is, that the OCX in the
attached file has been build using VS2005SP1 and in the package the link
points to I did use VS2008. Apart from that I changed the 2 merge
modules from Microsoft (CRT and MFC)

Migrating large project from DSC 7.1 to LabView 2009 Shared Variables ... What's the next step after recreating my variables?

I am in the process of migrating a large distributed (multi-workstation) automation system from the LabVIEW 7.11 DSCEngine on Windows XP to the LabVIEW 2009 Shared Variable Engine on Windows 7.
I have about 600 tags which represent data or IO states in a series of Opto22 instruments, accessible via their OptoOPCServer. There are another 150 memory tags which are used so the multiple workstations can trade requests and status information to coordinate motion and process sequencing. Only one workstation may be allowed to run the Opto22 server, because otherwise the Opto22 instruments are overwhelmed by the multiple communications requests; for simplicity, I'll refer to that workstation as the Opto22 gateway.
The LabVIEW 2009 migration tool was unable to properly migrate the Opto22 tags, but with some help from NI support (thank you, Jared!) and many days of pointing and clicking, I have successfully created a bound shared-variable library connecting to all the necessary data and IO. I've also created shared variables corresponding to the memory tags. All the variables have been deployed.
So far, so good. After much fighting with Windows 7 network location settings, I can open the Distributed System Manager on a second W7/LV2009 machine (I'll refer to it as the "remote" machine henceforth) and see the processes and all those variables on the Opto22 gateway workstation. I've also created a few variables on the remote workstation and confirmed that I can see them from the gateway workstation.
Now I need to be able to use (both read and write) the variables in VIs running on the remote workstation machine. (And by extension, on more remote workstations as I do the upgrade/migration).
I have succeeded in reading and writing them by creating a tag reader pointed at the URL for the process on the Opto22 gateway. I can see a way I could replace the old DSC tag reads and writes in my applications using this technique, but is this the right way to do this? Is this actually using the Shared Variable Engine, or is it actually using the DataSocket? I know for a fact that attempting to manipulate ~800 items via Datasocket will bog down the systems.
I had the impression that I should be able to create shared variables in my project on the remote workstation that link to those on the Opto22 gateway workstation. When, however, I try to browse to find the processes on that workstation, I get an error saying that isn't possible.
Am I on the right track with the tag reader? If not, is there some basic step I'm missing in trying to access the shared variables I created on the gateway workstation?
Any advice will be greatly appreciated.
Kevin
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

I have found the answer to part of my question -- an relatively easy way to create a "remote" library of shared variables that connect to the master library on my gateway workstation.
Export the variables from the master library as a csv file and copy that to the remote machine.
Open the file on the remote machine (in excel or the spreadsheet app of your choice) and (for safety's sake) immediately save it with a name marking it as the remote version.
Find the network path column (it was "U" in my file).
replace the path for each variable (which will be either a long file path or a blank, depending on the kind of variable) with \\machine\'process name'\variable name
where machine is the name or ip address of the master (gateway) workstation (I used the ip address to make sure it uses my dedicated automation ethernet network rather than our building-wide network)
and process name is the name of the process with the deployed variables visible in the Distributed System Manager on the gateway machine.
NOTE the single quotes around the process name; they are required.
The variable name is in the first ("A") column, so in Excel, I could do this for line 2 with the formula =CONCATENATE("\\machine\'process name'\",A2)
Once the formula worked on line 2, I could copy it into all the other lines.
Save the CSV file.
Import the CSV into the remote library to create the variables.
Note: at this point, if you attempt to deploy the variables, it will fail. The aliases are not quite set properly yet.
Open the properties for the first imported variable.
There is probably an error message at the bottom saying the alias is invalid.
In the alias section, you'll see it is set to "Project Variable" with the network path from step 4.
Change the setting to "PSP URL" with the same path and the error message should disappear.
Close the properties box, save the library, and then export the variables to a new CSV file.
Open the new CSV file in Excel, and scroll sideways to the NetworkrojectBound field.
You'll notice it is False for the first variable, and true for the rest. Set the field FALSE for all lines in the spreadsheet.
Scroll sideways... you'll notice there are two new columns between NetworkrojectPath and Network:UseBinding
The first one is NetworkingleWriter; it should already be FALSE for all lines.
The second one is Network:URL. That needs to be set equal to the value for each line of NetworkrojectPath.
You can accomplish this with a formula like in step 4. In Excel it was =U2 for line 2, and then cut and paste into all lines below it.
There is a third new field, Path, which should already be set to the location of the variable library. You don't need to do anything with it.
Save the edited CSV file.
Go back to the remote library, and import variables from the just-edited remote library CSV file.
Once you have imported them and the Multiple Variable Editor opens, click on done.
You should now be able to deploy the remote variable library without error. (Make sure to open the Distributed System Manager and start the local variable engine. It took me a few failures before I realized I had to do that before attempting a deployment).
Voila! You now have a "remote" library of shared variables that references all the shared variables on the master machine, and which should be deployable on other machines with very little difficulty.
It actually took longer to write out the process here than to perform these steps once I figured it out.
Kevin Roche
Advisory Engineer/Scientist
Spintronics and Magnetoelectronics group
IBM Research Almaden

How to create a standalone executable in LabVIEW 2009 Professional Development System?

How to create a standalone executable in LabVIEW 2009 Professional Development System?
Solved!
Go to Solution.

This should help you out http://zone.ni.com/devzone/cda/tut/p/id/3303
Also remember that quick search with Google in many cases will be quicker than asking in this forum. I always use Google before I ask for help in any forum. It is much quicker
Besides which, my opinion is that Express VIs Carthage must be destroyed deleted
(Sorry no Labview "brag list" so far)

In block diagram connecting wire getting blur while saving the VI in LabVIEW 2009

Hello,
I am using Labview 2009, And while I am saving a simple VI connecting wires are getting blurry. What could be the problem?? Is it affect my program while running?
Solved!
Go to Solution.

Go into Tools>>Options, select the Block Diagram page and find the section called Constant Folding. If the CF for wires check box is checked, then this is most likely the reason. You can uncheck the check box and it won't affect the way your code runs.
If this isn't the case, you should upload an image of what it looks like.
Try to take over the world!

Help needed in adding custom About box in built application in LabVIEW 2009

Hello,
Can anyone please help me add custom About box in built application in LabVIEW 2009? I had successfully built my application in labview 8.6, 8.5 and 8.2 before to include custom About box. However, when I tried the same method in LabVIEW 2009, it only showed LabVIEW 2009 About box rather than my custom About box.
Here is what I did:
1) Wrote an "About Application.vi" in the built VI folder;
2) Included this "About Application.vi" in the "Always Included" section of Source Files in Application Build;
3) Built the application;
4) Ran the built application, the About box showed only LabVIEW 2009 about (attached a picture).
You can see that on the upper left corner of the picture, there is my custom icon.
Your help is greatly appreciated,
Cathy
Solved!
Go to Solution.
Attachments:
About Box.JPG ‏34 KB

Here is the link to download LabVIEW 2009 f2 patch:
http://digital.ni.com/public.nsf/websearch/C3F88F3596A164AD86257647006FB022?OpenDocument
Thanks for the help,

UDP Error when upgrading from Labview 8.6 to Labview 2009

I recently updgraded from Labview 8.6 to Labview 2009. I am writing an application to stream data to disk from UDP. My VIs run just fine in Labview 8.6, but when I try to run them in Labview 2009 my UDP read times out despite being able to monitor UDP traffic and see that the data is being sent and nothing in the file is changed from 8.6 to 2009. Is there a known issue related to this?

How are you moniting the UDP traffic? Have you verified that the port you are trying to use is actually available? When you installed 2009 there may have been an additional service installed that may have used the port you're trying to use. If you're running on Windows you can use the command "netstat -n -o -a" to see all the ports that are currently in use, as well as the process ID that has that port open.

Labview 2009 32 bit not running on xp 64 bit

Hi all,
I tried to upgrade to LabVIEW 2009 from LabVIEW 8.6 on 64-bit windows XP machine. Following about a 2 hour removal of 8.6 and subsequent installation of LV 2009 it turns out that the device drivers are not compatible with a 64-bit machine. On launching LabVIEW 2009 (32-bit) an error box appears stating that it is corrupt or missing files and to correct this using control panel etc. I have tried this and still the same error occurs and LV refuses to start.
All the license files are correct and the compnents are activated.
Anyone know how to fix this? Or should I go back to 8.6 and cancel my upgrade subscription?
Secondly, I am using a firewire camera and was informed that Ni-IMAQ legacy are no longer supported and to go to ni.com/ifo and enter legacy1394 to see how to download drivers etc for this. I end up on a page that says "not authorized".
Any help gratefully appreciated.
Solved!
Go to Solution.

Leeser wrote:
I agree that XP64 and LV 2009 are not compatible as I installed LV 2009 on another 32-bit machine with no problems. I was just surprised as there were no problems or issues that I came across for 8. on XP64. Ah well, a uninstallation and reinstallation lies in wait for me on Monday morning!!
As an aside why call it LV 2009 instead of LV 8.7 or even LV9.0...sounds reminiscent of an operating system!!
Regards,
Leeser
LabVIEW 2009 is according to the internal version scheme actually equivalent to LabVIEW 9.0. Why they changed the naming? I guess marketing told them to do so. Why then? Well marketing has some funny ideas sometimes. I guess since THE software provider in this world has started to do this since about Windows 2000 someone must have thought it to be the best idea since sliced bread and decided to do it for LabVIEW too.
Another guess is that in about 2010 there would have been something like 9.1, and 10.0 would then come out in 2011 and that sounded somehow to someone like a bad scheme so they decided to change it now. But maybe it will be forgotten and everybody returns to the old versioning at the begin of next year when 9.0.1 will come out, which would then otherwise be LV 2009.1??? Or maybe LV2009 SP1?
It has already happened with LabVIEW 6i (iMacs, iPhones, iAnything), LabVIEW 7 Express and LabVIEW 8.20 (following 8.0.1 and marking the 20th anniversary of LabVIEW, and being internally LabVIEW 8.2). All some marketing fun or hysteria.
Rolf Kalbermatter
Message Edited by rolfk on 08-17-2009 11:08 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

LabVIEW 2009 SP1 Run-Time Engine (Minimum) (32-bit) for Windows - Supported Features

Hi,
Can some one please point out what features are supported by the LV RTE (Minimum ) [LabVIEW 2009 SP1 Run-Time Engine (Minimum) (32-bit) for Windows]
1) Is there a limit on the size of the exe which can be run on it?
2) Will this support additional modules like DAQ etc.,? Or do we have to chose the regular installer ( 170 Mb ) for that purpose?
3) If a list of what it does or does not support is available, it would be extremely helpful.
Thanks In advance.
Regards,
Vijay

Anand,
I did go through both the links that you had sent earlier before posting on the forum. For eaxample refer the following link where it says,
http://joule.ni.com/nidu/cds/view/p/lang/en/id/1599
It does not contain the full run-time engine, but will allow some executables to run.
1) What do they mean by 'some' executables. Is there a list of yay's and no's available?
2) Can someone from NI reply to this and shed more knowledge?
Regards,
Vijay

Enum in a Typedef Reverts to Default (LabVIEW 2009)

When I add additional items to a typedef'd enum, constants of that enum on some BD's revert back to the default zero index enum value. In the past (8.6.1 and previous), adding items to an enum in no way would ever change constants that were already dropped on a BD. Now, in LabVIEW 2009, when I add items, about 60-70% of the constants dropped on different block diagrams will be changed to default value.
This happens in a "large" enum (~400 elements) that spans about 3 dozen VI's between RT and HMI block diagrams (a total of about 300 instances). This is a mature project that has never had this problem with 8.2, 8.5, 8.6, or 8.6.1...
I cannot post an example, because in the process of stripping down the VI, the problem goes away. It is extremely repeatable in the context of the project, but I cannot repeat it on an individual VI basis.
The current workaround is to edit the typedef'd enum while all referencing VI's are in memory. If the VI's that use the typedef are in memory, they will always properly recompile and maintain the correct constant value. However, if the VI is not in memory, and the typedef is changed, the next time the VI is opened, when it recompiles it will change the constants back to the zero index default value of the enum in only about 60-70% of VI's. Unfortunately, we cannot yet find a common thread in the VI's that recompile wrong, and the ones that recompile correctly.
Has anyone ever seen this problem? Suggestions?
Best regards,
Jack
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

We just realized a flaw in our "workaround", as partially pointed out by Ben (he was probably typing his response as we were confirming it here). If the constant is inside of a cluster on the BD, even if it is in memory, it will null out the enum inside of the constant. Therefore, the "workaround" is to rewrite the clustered enum constants from scratch (in other words, there's no workaround). Two of us spent a decent portion of the morning finally nailing this as the source of what we thought was an unrelated bug... and that's after spending a long day yesterday trying to find a fix. Yes, we feel Ben's angst of reverting back to previous SCC editions and manually editing dozens of VIs.
The severity of this bug is a showstopper for us. We cannot risk adding elements to an enum and consequently have referencing VIs changing their constants.
Force compiling a VI one at a time is not an option for us. I know this bug manifests itself even after a mass compile. So, is there a way to "mass force re-compile" that we could test?
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}

DocumentRo​ot in niwebserve​r.conf (LabVIEW 2009)

Similar Messages

Maybe you are looking for

DocumentRoot in niwebserver.conf (LabVIEW 2009)