LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with LabVIEW web server on executable, when moving executable around

Hey guys,

So I'm having a weird issue here. I'm able to run the web server fine through my VI. I had some issues when I compiled it as an executable, but eventually found out the issue was that I had to have labview closed completely before running the executable. Now it works great on my exe.

 

Now here comes the issue. I had to build the exe in my local drive (C:), but I want to store it on a different drive (say Z:). When I moved the files, I made sure to update the niwebserver.conf file DocumentRoot to the new folder (and drive) location.

 

However, now that I run the .exe from the Z: drive, I get an error with the web server. Anyone got any ideas on what may be causing this? Ideally I would like to retain the ability to build the exe on my local drive and move it over.

 

Thanks!

0 Kudos
Message 1 of 8
(3,853 Views)

Hello DDang,

 

You can try doing a mass compile of the VI, if you have any questions about what it is you can check here: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YJOjCAO&l=en-US

 

After doing the mass compile you could even try doing the exe again to make sure the paths are correct.

 

-Andrea G

Applications Engineer National Instruments

0 Kudos
Message 2 of 8
(3,806 Views)

Hey andmboa7, just treid to mass compile with no avail. However, have been playing around with it today, and have discovered the following situations with the .exe. Just want to remind that 

 

C: (not run as admin) - Web server kicks off fine, run into error with open/write TDMS file (requires admin rights)

C: (run as admin) - Everything works great, connects to web server, and can open/write TDMS file.

Z: (not run as admin) - Web server works fine (!!!), but runs into error with open/write TDMS file.

Z: (run as admin) - Web server fails!

 

I've tinkered around with all kinds of settings in the .conf in the parent directory of the .exe. Anyone have any idea why I might run into issue starting the web server as an admin, but runs fine as a normal user? (specifically about Z: drive) This seems crazy to me as I would expect the Z: with admin would work fine?

0 Kudos
Message 3 of 8
(3,803 Views)

That is really interesting that in the Z drive, it only runs when you run it not as admin...

Does that mean the configuration settings of not-admin are less "secure"? It kind of sounds like something in the settings of admin are blocking the web server.

 

Have you also modified the .ini file with "WebServer.Enabled=True"?

See this page: https://www.ni.com/docs/en-US/bundle/labview/page/enabling-the-web-server-in-stand-alone-application...

0 Kudos
Message 4 of 8
(3,780 Views)

Yea, it's really weird. It's hard to pinpoint it. My understanding of IT is not the greatest, and working with IT to see if we might be able to figure it out.

 

However, with some tinkering, I have been able to get it to run error free on my code now. However, when I try to access the web service, I'm now getting this error.

 

"remote panel connection refused by specified server: Make sure labview web server is enabled on specified server."

 

Any idea why this would happen? It's referencing the same files as the C:, so not sure what's going on that makes it so drastic that I'm running off Z:

0 Kudos
Message 5 of 8
(3,768 Views)

Hello, DDang, 

 

Have you experimented with disabling the firewall and seeing what happens?

0 Kudos
Message 6 of 8
(3,753 Views)

Hey,

 

Sorry late reply. Wasn't able to get access to firewall settings. I just put a band-aid on this by having my data stored somewhere on the C: where the user (as a non-admin) had write permissions. This way I was able to run the exe as a user, and get both the web server and data logging to work.

 

It would have been nice to write to my usual location. However, it still leaves my mind bewildered that if I were to run this exe as an admin, the web server will brick.

0 Kudos
Message 7 of 8
(3,744 Views)

I'm glad you found a workaround. It sounds like a difficult issue to troubleshoot. If you decide to pursue it again, let us know.

0 Kudos
Message 8 of 8
(3,738 Views)