View Executable on Web browser

[Cat]

Maybe it's because it's Monday and I haven't recovered from either Cinco de Mayo (tequila) or the Kentucky Derby (bourbon) yet, but this one is twisting my little brain.

After years of managing to avoid LabView and the Interwebs, somebody got the great idea of running some of my code via a web browser. Sure! I say, LabVIEW's got stuff to do that!  Three hours later and it just ain't working right. I've read all sorts of things like:

http://zone.ni.com/reference/en-XX/help/371361M-01/lvconcepts/ws_distributing/

http://zone.ni.com/reference/en-XX/help/371361L-01/lvhowto/enabling_the_web_server_in/

http://zone.ni.com/reference/en-XX/help/371361M-01/lvconcepts/ws_web_server/

http://zone.ni.com/reference/en-XX/help/371361M-01/lvhowto/build_web_service/

etc., etc.

They just don't seem to be fully addressing my situation. Unfortunately there doesn't seem to be document that goes thru it all from start to finish.

Here's my setup:

Computer A: Running a LabVIEW application -- call it TestWeb.exe

Computer B: Running Explorer/Chrome/Firefox. No software can be loaded or installed on this computer, including any NI software.

Is there something I can do to be able to view/control TestWeb.exe, via a web browser, from Computer B?

 

I've gotten it to work wonderfully -- using source code, but even tho I think I'm doing what the various docs say, it isn't working with an executable. Are there more complete directions somewhere someone can point me to?

 

Cat

[hooovahh]

Oh sure there are tons of ways to do this with 3rd party tools.  My favorite happens to be one I helped develop posted here.  With it I have been able to run a VI on a remote system which generates an HTML5 webpage, which I can view using chrome on another desktop, or my phone, or firefox running on an embedded Linux RT target.  It has several limitations, like all clients connected will see the same UI but it is all open source and could be updated to your needs.

Here are a list of other options, most of which I can't speak to the feature set of.

As far as I know all of the official ways to do this (other than the new hottness teased at the last NI Week) all require some part of the run time engine to be installed.

[infinitenothing]

If you're looking for NI's web service examples to walk you through some of your links look here: C:\Program Files (x86)\National Instruments\LabVIEW 20xx\examples\Connectivity\Web Services

You won't need the RTE on the client computers but you'll also have very limited interaction. Think text and pictures and not panels. If you need a remote panel look into the above post.

You should also look into your client requirements. Some other options open up if you are willing to run silverlight or flash. Those options are becoming obsolete over the next decade or so.

[smithd]

8 hours ago, Cat said:

Computer A: Running a LabVIEW application -- call it TestWeb.exe

Computer B: Running Explorer/Chrome/Firefox. No software can be loaded or installed on this computer, including any NI software.

Forgive me if I'm going too basic but I figure it can't hurt...I can't quite tell from your post where you're at.

NI used to have a product called remote front panels (I pretend it doesn't exist anymore in order to feel safe) which was a tool which converted your normal VI front panel into a little applet which could run in a browser.

The preferred way is to use a web server to host your application and explicitly expose features through a well-defined and structured web interface. The basic interface is through http which consists of 4 main request-response types: get, post, put, and delete. Another mechanism is through something called websockets, which basically piggybacks off of http to create a full duplex data packet layer over TCP.

To communicate with a web server you need some client. You could write this in a standard language like labview or c# but because no executable software can be loaded on the computer you're limited to either a system already there like flash or javascript in a browser. Assuming you have a soul and thus don't want flash, you are left with exactly 1 option for your client, html/css/javascript. These files will be hosted as static files in your web server (or could be dynamically generated too) and retrieved using a http get request. Once downloaded into a browser, an html page will typically load a javascript file for execution, and that javascript file can issue ajax requests (which just means the javascript can ask your web server for more resources). The javascript can then manipulate the html to display whatever you want to your user. Fortunately, for the basic case, various people have already done this for you (hooovahh's link is a good one).

Depending on where you are on the learning scale, NI did an ok job of writing some of this stuff here:
https://forums.ni.com/t5/LabVIEW-Web-Development/Web-Services-Getting-Started-Series/ta-p/3498686
https://forums.ni.com/t5/LabVIEW-Web-Development/Web-Services-Publishing-Data-Series/ta-p/3501626
https://forums.ni.com/t5/LabVIEW-Web-Development/Web-Connectivity-Options-in-LabVIEW/ta-p/3501679

(all part of the same community group, different hub pages)

[ShaunR]

Viewing is easy. Just Save a FP image to a file and reference it in a webservers HTML page (NI Webserver, Apache NGINX,whatever.)

Control is much harder which is why many of us use Websockets. The NI webserver is based around calling individual functions (Vis) in a command/response manner from the browser which is why they have Remote Panels as Smithd has mentioned. There are indirect methods like VNC or surrogate "SendKeys" software but direct control of a LabVIEW application requires you to embed a server in your application which can respond to browser clicks

[Cat]

On 5/8/2017 at 3:48 PM, hooovahh said:

Oh sure there are tons of ways to do this with 3rd party tools.  My favorite happens to be one I helped develop posted here.  

Wow.  So after a day or so of flailing around I finally got this working.  I think I only ended up making 2 changes to the Example.vi, the rest of the time I was trying to figure out all the networking stuff to make it actually work.  Some of that time was spent combing thu this link for little hints.  Some was spent figuring out what firewall setting I needed to turn off.  Along the way I learned about symbolic links and how to configure an Apache web server.  It was fun!

Thanks hooovahh!  And thanks to everyone else who contributed to this code.

[hooovahh]

Oh yeah lots of fun for sure, glad you got something working.  I'd say you can thank me with a drink in Austin, but it sounds like you won't be making it.

[Cat]

Grrr.   Yeah, the schedule change messed up my plans there.  Hopefully next year I'll be there and can buy you a belated round.

[Cat]

On ‎5‎/‎9‎/‎2017 at 0:47 AM, smithd said:

Forgive me if I'm going too basic but I figure it can't hurt...I can't quite tell from your post where you're at.

Thanks for the process walk-thru.  Unfortunately when I first read it I didn't know enough for it to help.  Now it make perfect sense!  

 

On ‎5‎/‎9‎/‎2017 at 0:47 AM, smithd said:

Assuming you have a soul and thus don't want flash, you are left with exactly 1 option for your client

 

[Rolf Kalbermatter]

On 5/8/2017 at 11:54 PM, infinitenothing said:

You should also look into your client requirements. Some other options open up if you are willing to run silverlight or flash. Those options are becoming obsolete over the next decade or so.

That sounds a bit optimistic considering that all major web browsers nowadays disable Flash by default and some have definite plans to remove it altogether. Similar about the Silverlight plugin, which Microsoft has stopped to develop years ago already and support is marginal today (security fixes).