Interactive Webpage VI Options

[ShaunR]

. You would write code that can run on any web server or client.

 

1. You don't need a client. That's what the browser is. If you want a LabVIEW client, then you need to write one in LabVIEW. If you want a C# one. Then you need to write one in c# etc. Websockets is a protocol!

 

If you do want a LabVIEW client, then here is one that sends the time to the www.websocket.org echo test server. The Open, Read, Write and Close should be a familiar concept.

 

 

2. You don't need a web server. With websockets, a web server is sometimes used so that the browser HTML and javascript can be found and downloaded. It isn't a requirement though if the client already has the HTML and Javascript. The web server is a distribution tool for the HTML and JavaScript.

 

Here is a LabVIEW websocket server. You can see it is just a direct replacement for the TCPIP primitives and you use it exactly the same. It supports 1 connection just like it would do if you used the TCPIP primitives.

 

.

 

Here is another websocket server that supports multiple clients. You can download and play with this one here.

 

 

You can see it uses the primitives to create the server in a producer/consumer fashion just like you would with the TCPIP primitives . There's nothing tremendously complicated here and since the VI services are launched dynamically, you just need to add it to them the the "Always Include" of your build spec.

 

If you use a web server to enable the end user to download the HTML and Javascript rather than supply it, say, as a zip file. The web server still has nothing to do with the websocket communication.

 

Where the toolkits vary is in how they get the HTML and javascript to the clients browser. (which is required only for browsers)  Some rely on a web server and if they rely on the NI web server then you need all the deployment malarky. Some pretend they are a webserver and spurt out the webpage on port 80. All that has nothing really to do with websockets just ways of deploying the HTML and Javascript for web browsers. You still have to create/write the HTML and Javascript and some devs are attempting to do that dynamically (like Thomas).

 

So. I will try one more time.

What are your concerns with the available toolkits around creating multi client, browser enabled  applications. As far as I am aware, they all can but you insist they "fail"

Edited October 15, 2015 by ShaunR

[Mads]

 

 

1. You don't need a client. That's what the browser is.

 

I talk about writing code that can run *in* a web browser. NI's Web UI tool basically solved this by making us develop Silverlight applications in a variant of G, which most people with a web client would have and therefor be able to use. The decision to base it on Silverlight proved to be rather bad...but the concept would be the same. In scenario B the Web client (and/or server) is in many ways the target OS.There has been some talk lately about NI having plans to port the run-time-engine to javascript. That would constitute a move towards scenario B.

Edited October 15, 2015 by Mads

[ShaunR]

I talk about writing code that can run *in* a web browser. NI's Web UI tool basically solved this by making us develop Silverlight applications in a variant of G, which most people with a web client would have and therefor be able to use. The decision to base it on Silverlight proved to be rather bad...but the concept would be the same. In scenario B the Web client (and/or server) is in many ways the target OS.There has been some talk lately about NI having plans to port the run-time-engine to javascript. That would constitute a move towards scenario B.

 

You seem to be all over the place with this. I'm not even sure you know what you want.

 

You started off with a complaint about toolkit developers failing to deliver multi-client websocket servers. Moved onto complaining that the websocket toolkits only enable LabVIEW UIs to be exported (all of which is untrue) and ended up complaining at not being able to write LabVIEW code in a browser (which only NI would be able to do). When I try to ask you for specific examples of failures or requirements you seem to just ride off on another unicorn hunt.

 

Maybe you should post your requirement on the Ideas Exchange because I don't think it is anything I can help with.

Edited October 15, 2015 by ShaunR

[hooovahh]

I like to reference this thread occasionally when people ask about web and LabVIEW solutions.  Since it has been a few years lets see if I can give another summary of the options.  I haven't used all these but just wanted a list of NI and non-NI ones that were available.  These are not all equal, and the intention is that here is a landing page where people can find tools and do their own research on what meets their needs, while providing a little history.

Solutions From NI:

G Web Development - Came from WebVIs in NXG's Web Module. Paid toolkit.

Web Service - Great for simple request response, but the UI needs to be made somewhere else. Included with LabVIEW Full/Professional

Web Publishing Tool - Simple to use, works on RT, but uses Silverlight and no modern browser supports it, just IE. Included with LabVIEW 

Data Dashboard - Tool for displaying Network Published Shared Variables on tablet devices. No longer supported.

Web UI Builder - Pre NXG no longer supported with download links missing. Linked to the 2009 Keynote. 

 

3rd Party Solutions:

Front Panel Publisher - Open source originally used Web Service but now uses Web Sockets.

MQTT WebSockets Connection - Open source. UI needs to be built by another tool.

WebSockets API by MediaMongrels - Free toolkit, MIT License. UI needs to be built by another tool.

LabSockets - Paid toolkit with trial.

Wezarp - Paid toolkit with trial.

Encryption Compendium for LabVIEW - Websocket API included among other tools.  Paid toolkit. UI needs to be built by another tool.

WebPager - Not sure never used it. The original site seems down.

VIRemote - Appears to be a paid toolkit but has a free demo.

WebPanels - Hosting site seems down, LAVA thread linked.

Remote Witness - I think it was a paid tool but the site doesn't have much.

[Neil Pate]

On 2/9/2022 at 5:05 PM, hooovahh said:

I like to reference this thread occasionally when people ask about web and LabVIEW solutions.  Since it has been a few years lets see if I can give another summary of the options.  I haven't used all these but just wanted a list of NI and non-NI ones that were available.  These are not all equal, and the intention is that here is a landing page where people can find tools and do their own research on what meets their needs, while providing a little history.

Solutions From NI:

G Web Development - Came from WebVIs in NXG's Web Module. Paid toolkit.

Web Service - Great for simple request response, but the UI needs to be made somewhere else. Included with LabVIEW Full/Professional

Web Publishing Tool - Simple to use, works on RT, but uses Silverlight and no modern browser supports it, just IE. Included with LabVIEW 

Data Dashboard - Tool for displaying Network Published Shared Variables on tablet devices. No longer supported.

Web UI Builder - Pre NXG no longer supported with download links missing. Linked to the 2009 Keynote. 

 

3rd Party Solutions:

Front Panel Publisher - Open source originally used Web Service but now uses Web Sockets.

MQTT WebSockets Connection - Open source. UI needs to be built by another tool.

WebSockets API by MediaMongrels - Free toolkit, MIT License. UI needs to be built by another tool.

LabSockets - Paid toolkit with trial.

Wezarp - Paid toolkit with trial.

WebPager - Not sure never used it. The original site seems down.

Websockets API by LVS Tools - Not sure if it is still supported, was a paid toolkit. UI needs to be built by another tool.

VIRemote - Appears to be a paid toolkit but has a free demo.

WebPanels - Hosting site seems down, LAVA thread linked.

Remote Witness - I think it was a paid tool but the site doesn't have much.

Thanks hooovahh. Now I am even more depressed. As a LV dev that list makes for pretty sad reading in 2022. 

[ShaunR]

On 2/9/2022 at 4:05 PM, hooovahh said:

Websockets API by LVS Tools - Not sure if it is still supported, was a paid toolkit. UI needs to be built by another tool.

No longer a stand-alone product. The Websocket API was rolled into ECL sans the FP and HTML library portion.

[hooovahh]

15 hours ago, Neil Pate said:

Thanks hooovahh. Now I am even more depressed. As a LV dev that list makes for pretty sad reading in 2022. 

Sorry.  I suspect part of the issue is that once NI announced WebVIs and porting the runtime engine to JAVA script, companies probably thought there isn't much sense in trying to have a 3rd party tool compete with NI's.  And either froze development, abandoned the project, or rolled it into other tools.  Still I do use MediaMongrel's WebSocket API, and I've used the Front Panel Publisher on a program or two but nothing active right now.  I've wanted to update it to add support for more data types, and clean up the examples, but without a program that uses it, and with very little Java experience, I don't think anything will happen to it.

[bjustice]

I've used the G Web Development Module (fairly heavily) once for a project.  Also used the MediaMongrels WebSocket API to then have the WebVIs talk back to a LabVIEW application.  Worked out quite well.

The most alarming aspect of the G Web Development module seemed to be the lack of a user-base.  I struggled to find any examples online excluding NI's own examples.  The darkside forum felt like a ghost town when I asked for help with a problem.  Even now, looking online, I don't see any published roadmap or planned features for the G Web Development.  It's kinda sad.  I really liked working with what existed.

[JKSH]

20 hours ago, bjustice said:

I've used the G Web Development Module (fairly heavily) once for a project....  Worked out quite well.

The most alarming aspect of the G Web Development module seemed to be the lack of a user-base.  I struggled to find any examples online excluding NI's own examples.  The darkside forum felt like a ghost town when I asked for help with a problem.  Even now, looking online, I don't see any published roadmap or planned features for the G Web Development.  It's kinda sad.  I really liked working with what existed.

I used the NXG 5.0 Web Module (direct precursor to the G Web Development module) for a large SystemLink-hosted project.

The biggest issue for me is missing functionality. Despite SystemLink touting Tags + Messages + Files as the 3 pillars of data transfer, NI did not provide a Web Module API for downloading/uploading files from/to a SystemLink server. I thought... "That's OK, I'll just use the raw HTTP API instead". And then I found out that the HTTP API itself was unfinished. NI provides a WebVI for making a HTTP Multipart request (which is required for uploading files), but if you open up that VI it simply spits out an error constant that says, "feature not implemented". So I had to implement it in JavaScript in the end.

The next headache is the rigid UI. It is near impossible to get the UI to even resize with the browser window; the result feels rather unprofessional next to non-NI web UIs.

The Web Module is fine for making very basic, static dashboards. But if you want to do anything complex/interactive/dynamic, you'll need to delve into HTML + CSS + JavaScript.

Edited February 12, 2022 by JKSH

[Antoine Chalons]

4 hours ago, JKSH said:

The Web Module is fine for making very basic, static dashboards. But if you want to do anything complex/interactive/dynamic, you'll need to delve into HTML + CSS + JavaScript.

I think it’s a pattern at NI, only scratching the surface.

lots of products or support for standards are superficial. They exhort us to engineer ambitiously because they don’t.

[hooovahh]

On 2/11/2022 at 10:52 PM, JKSH said:

The next headache is the rigid UI. It is near impossible to get the UI to even resize with the browser window; the result feels rather unprofessional next to non-NI web UIs.

Agreed.  I did use WebVIs when they were part of NXG.  And I did get a UI that had a decent amount dynamic UI stuff.  But it was primarily done with many duplicate controls, inside transparent tabs, so I could show and had data, while making it look like things were moving around.  Of course at the time this wasn't straight forward, not sure if it has gotten better.  It got so bad that the IDE just chugged to a crawl.  I contacted support at NI and showed them the several hundred controls I needed to make it look normal.  NI's original reaction was "Why would you need so many controls?" and then after explaining the UI/UX I was trying to make their reaction was "Yeah I guess that is the only way to get what you want".  Luckily once built into HTML it ran just fine.  

On 2/12/2022 at 3:13 AM, Antoine Chalons said:

I think it’s a pattern at NI, only scratching the surface.

lots of products or support for standards are superficial. 

I've found a couple times when these limitations are arbitrary, or just based on incomplete testing.  A few times a VI will return an error when on a platform that it wasn't intended for.  If you look at the block diagram it is a conditional structure just set to generate an error.  In a couple cases when I removed the structure the code ran just fine.

[Neil Pate]

I did use the Web VIs to make a data dashboard several years ago. Pretty simple stuff, retrieval of data from a LabVIEW implemented WebService, and a bit of data wrangling and graphing. All in all the experience was awful and I wish to never go through the pain again. Doing anything in the editor was tedious and frustrating, and the built in web server stopped working many times during development (for no reasons that I could tell). Eventually I hosted it with IIS and it worked pretty much first time and then perfectly afterwards.

Definitely cannot recommend it for anything other than trivial webpages.