Interactive Webpage VI Options

[hooovahh]

Topic continuing from here.  Discussion was talking about alternatives of generating interactive web pages that hook into running VIs.

 

Here is another non-free competitor.

 

Webpager

[ShaunR]

Oh just for completeness (well probably not complete) here is another non-free competitor.

 

Webpager

 

I'm feeling a bit left out

[hooovahh]

On 10/1/2015 at 3:40 PM, ShaunR said:

I'm feeling a bit left out

Oh so sorry, there are so many it is hard to keep up with.  Okay lets see if I can do this justice.

Front Panel Publisher

Websocket API for LabVIEW

Webpager

Wezarp

VIRemote

WebPanels (or this)

Web UI Builder

LabSocket

Remote Witness

 

Data Dashboard, and NI Web Services should get an honorable mention, but isn't true to what this is supposed to do, which is turn a VI into a web page.  And NI even has teased porting the LabVIEW run-time engine to JavaScript.

EDIT: Updated the list.

[ShaunR]

Oh so sorry, there are so many it is hard to keep up with.  Okay lets see if I can do this justice

 

If you're giving away free advertising I expect at least a mention

[hooovahh]

I wasn't really thinking of it as free advertising, at first this was the list of tools that you wouldn't want to try, if you don't want to spend money.  This list does contain WebPanels I think is the only free one in the list (other than the one discussed here)

[smithd]

I don't want to knock this because it really is pretty awesome (as are the many alternatives), but I'm curious for myself how often y'all end up actually needing tools like this? I feel like it should be a ton given how many different options there are, but I personally have only had a few people come to me and say they wanted this...and even then, they really only wanted to see a demo and then they promptly forgot about it.

 

 

So...is this actually a common need and I just don't see it where I'm at, or is it more like "man look at this sweet thing I can do"?

[hooovahh]

Remember it's not just 3rd party tools.  NI has shown lots of interest in their tools, and the linked keynote.  Only recently have I seen a real need for something like this and will have to choose from one of them at some point.  So no, I don't think it is common, but lots of people are asking for it, some must be using it.

[smithd]

Remember it's not just 3rd party tools.  NI has shown lots of interest in their tools, and the linked keynote.  Only recently have I seen a real need for something like this and will have to choose from one of them at some point.  So no, I don't think it is common, but lots of people are asking for it, some must be using it.

Absolutely, and I've asked this question internally too. I'm really just curious, because I think its cool too and want to use it but haven't found a problem to throw it at

[jcarmody]

I work with tight controls on what we can do with computers on our company's network.  The idea has been tossed around that we could build our own computers that never see the network so we can retain admin control over them.  Then, using a networked & not-under-our-control PC with two network cards, we can present the Front Panel of our application from the "free" PC to the "non-free" PC.

[Mads]

I don't want to knock this because it really is pretty awesome (as are the many alternatives), but I'm curious for myself how often y'all end up actually needing tools like this? I feel like it should be a ton given how many different options there are, but I personally have only had a few people come to me and say they wanted this...and even then, they really only wanted to see a demo and then they promptly forgot about it.

 

 

So...is this actually a common need and I just don't see it where I'm at, or is it more like "man look at this sweet thing I can do"?

 

Web interface solutions would be interesting for us if they were multi-session (that is - support many users working on the same system in parallel), and handled multiple VIs/windows elegantly. If there was an out of the box solution for *that*, then we would definitely use it. Basically we would really want the client to be replaced by the web browser...(Controlling single front panels is in the "man look at this sweet thing I can do" category. We have only used such solutions occationally, to control internal test equipment.

Most of our commercial systems are client-server based, and one serious drawback to that is that the user interface has to be implemented in the client. - It cannot be dynamically loaded from the server side. So if we have some complex functionality that requires a new user interface on the client side we actually have to modify the client (we could transfer Vis from the server on demand and run it on the client side, but then that would break if the run-time engine differed between the server and the client, so it becomes a mess. A web-based solution could solve this, but it should work in a way that minimizes the need for extra development (even today's solutions can be made to work in a web client, but then you need to design the web interface using separate tools, and just link it to the server side using web services. It easily becomes a bigger part of the development, and is a hassle to get flexible/dynamic enough).

Edited October 2, 2015 by Mads

[ShaunR]

Web interface solutions would be interesting for us if they were multi-session (that is - support many users working on the same system in parallel), and handled multiple VIs/windows elegantly. If there was an out of the box solution for *that*, then we would definitely use it. Basically we would really want the client to be replaced by the web browser...(Controlling single front panels is in the "man look at this sweet thing I can do" category. We have only used such solutions occationally, to control internal test equipment.

Most of our commercial systems are client-server based, and one serious drawback to that is that the user interface has to be implemented in the client. - It cannot be dynamically loaded from the server side. So if we have some complex functionality that requires a new user interface on the client side we actually have to modify the client (we could transfer Vis from the server on demand and run it on the client side, but then that would break if the run-time engine differed between the server and the client, so it becomes a mess. A web-based solution could solve this, but it should work in a way that minimizes the need for extra development (even today's solutions can be made to work in a web client, but then you need to design the web interface using separate tools, and just link it to the server side using web services. It easily becomes a bigger part of the development, and is a hassle to get flexible/dynamic enough).

 

That just boils down to "I don't know how to do it and I won't pay someone to do it". When you realise that it is just messaging for control and UI updates you end up at a point where you can use any user interface in any language and two main possibilities come out  when web browsers are concerned - REST and Websocket Then you start pressurising the IT departments' web developers to stop playing Doom and do something useful .

 

Hooovahhs list is proffered as all products being equivalent. They are not. They just have the common denominator of being able to display a LabVIEW UI in a web browser and demo as such for LabVIEW developers. If your current client server/relies on NI Server remote functions. You are locked in, I'm afraid. If you use messaging, you can create headless, back end services with rich browser interfaces to serve multiple users.

[drjdpowell]

Question:  Do these toolkits support events (such as Shortcut Menu events, Cursor Events, etc.) and do they work with subpanels?

[hooovahh]

Hooovahhs list is proffered as all products being equivalent. They are not. 

That wasn't the intention, sorry if I didn't spend the time to research each and give a more detailed table of the pros/cons of each.  The intention again, was to show that there are many similar toolkits trying to accomplish a similar task. Make a webpage which hooks into a VI running on a server, usually by replicating the VI's front panel in a webpage.  

 

No idea about the limitations of each, I suspect runtime menus, events, subpanels, tabs, .NET, ActiveX, and XControls to have varying levels of support.  I would be very impressed if there is one that does all of these somehow.  We should probably make this a new topic if we continue with this discussion soon.

[smithd]

Question:  Do these toolkits support events (such as Shortcut Menu events, Cursor Events, etc.) and do they work with subpanels?

Is there a way to dynamically generate those non-value-change events? I was under the impression that was one of the roadblocks to UI testing automation. This thing seems to work around it but I dont know how.

[ShaunR]

We should probably make this a new topic if we continue with this discussion soon.

I think it is a good idea to do so. This is detracting from ThomasGutzlers software solution which is an ongoing development and that is getting lost in the general debate.

[hooovahh]

Is there a way to dynamically generate those non-value-change events? I was under the impression that was one of the roadblocks to UI testing automation. This thing seems to work around it but I dont know how.

I never really thought about the implementation details.  I guess an option would be to use user events that get generated when those UI elements are interacted with.  Of course that would mean you can no longer just auto generate a web page from a VI, you'd need code to create those user events, register for them, and handle them separately.  I kinda like the simplicity of the auto generated stuff so I might just live with value changes.  I mean that's all the RT Linux HMIs have right?

 

EDIT: I started making this and idea exchange but wasn't sure if it was actually what I wanted.  I was thinking given a reference generate a specific event, but wasn't sure if the webpage could even support that type of dynamic changes for things like menus popping up on right click.

[Mads]

That just boils down to "I don't know how to do it and I won't pay someone to do it". When you realise that it is just messaging for control and UI updates you end up at a point where you can use any user interface in any language and two main possibilities come out  when web browsers are concerned - REST and Websocket Then you start pressurising the IT departments' web developers to stop playing Doom and do something useful .

 

Hooovahhs list is proffered as all products being equivalent. They are not. They just have the common denominator of being able to display a LabVIEW UI in a web browser and demo as such for LabVIEW developers. If your current client server/relies on NI Server remote functions. You are locked in, I'm afraid. If you use messaging, you can create headless, back end services with rich browser interfaces to serve multiple users.

 

In our case the client-server solutions are all message based, so the client could be made in a different language to run in a web browser yes. But how fun is that   As you know good engineers are lazy  , so anything that would allow us to develop a GUI right there in LabVIEW, and deploy it as an interactive rich web site, handling multiple parallel connections, would be sweet...No need to stop anyone from playing Doom then     (reminds me of two girls behind me in the movie theater that suddenly realized that the film they had bought tickets for was *not* a bright and sunny story...- Whaaat? )

Edited October 2, 2015 by Mads

[ShaunR]

Question:  Do these toolkits support events (such as Shortcut Menu events, Cursor Events, etc.) and do they work with subpanels?

 

Sort of the wrong question. It's like saying can my TV pick up satellite? Well. Yes, if you have the right receiver.

 

Can you build browser interfaces to LabVIEW with menus, cursors and sub panel mimic screens with these tool-kits? Many of them, yes. Getting UI information out of LabVIEW into a browser is trivial. Getting the user control requests back in to affect LabVIEW is far more complicated and requires a protocol your specific LabVIEW implementation understands. Is there a wrapper solution that you flip a switch and it is in your web browser? Yes. It's called Remote Panels.

 

I think people see these technologies fundamentally differently to me. I see it as a way to "fix" what NI refuse to do. Maybe I have to address the general need rather than just my own and my customers' for this technology. I see developers being able to view/gather information and configure disparate systems in beautifully designed browser interfaces with streaming real-time data from multiple sensors (internet of things)  Interfaces like this but with LabVIEW driving it. Customisable dashboard style interfaces to LabVIEW and interactive templated reporting - all with LabVIEW back ends. You can do this with these toolkits.

 

Most LabVIEW developers, however, just seem to want their crappy LabVIEW panels in a browser frame . That is like being given a house and using it as a shed.

[CraigC]

I was actually playing around with websocket development with Unity and LabVIEW.  Sadly my c# skills suck however I could get bidirectional data in and out of the unity game engine.

 

This would open up a whole world of UI exquisiteness as the unity engine just ports the said front end into whatever target platform you desire... HTML5 web based, android, iphone etc.

 

Making 2D User interfaces within the environment is fairly straightforward.  Every game you play has a UI element to it.

 

3D LabVIEW front ends!!!

[smithd]

I think people see these technologies fundamentally differently to me. I see it as a way to "fix" what NI refuse to do. Maybe I have to address the general need rather than just my own and my customers' for this technology. I see developers being able to view/gather information and configure disparate systems in beautifully designed browser interfaces with streaming real-time data from multiple sensors (internet of things)  Interfaces like this but with LabVIEW driving it. Customisable dashboard style interfaces to LabVIEW and interactive templated reporting - all with LabVIEW back ends. You can do this with these toolkits.

 

Wow, that freeboard.io page is pretty sweet. I played around with it and made something simple using the CVT, might post a little tutorial for interested parties if I have time. I like that it just takes a json blob and then lets you display it.

 

The only downside I can see (vs something like data dashboard) is you don't seem to have the ability to set values using it. Its probably not too hard to add some js to send value change events, but it'd be cool if it were baked in.

 

 

Also, if anyone ever uses their own web server like apache or nginx or whatever, and have found that its annoyingly painful to use, I found a shiny new alternative:

https://caddyserver.com/

Basically everything in the folder with the exe will be served up by default, and then you can put in a "caddyfile" which has additional instructions. For example if you wanted to host freeboard using the main server and forward requests to /lv to a labview web service called "myWebService", you'd put this one single line in the file:

"proxy /lv localhost:8081/myWebService"

[ThomasGutzler]

Web interface solutions would be interesting for us if they were multi-session (that is - support many users working on the same system in parallel), and handled multiple VIs/windows elegantly. If there was an out of the box solution for *that*, then we would definitely use it. Basically we would really want the client to be replaced by the web browser...(Controlling single front panels is in the "man look at this sweet thing I can do" category. We have only used such solutions occationally, to control internal test equipment.

 

In theory my solution should be able to do that. It was certainly designed with that feature in mind - I just haven't tried it yet

As long as the front panel is running somewhere and visible it can be interacted with.

In fact, my plan was to have a navigation menu inserted into every html page to allow the user to navigate between all available front panels without having to type in a new URL or make an awkward link on the actual front panels. Unfortunately, all that only exists in my head...

[ShaunR]

In theory my solution should be able to do that. It was certainly designed with that feature in mind - I just haven't tried it yet

As long as the front panel is running somewhere and visible it can be interacted with.

In fact, my plan was to have a navigation menu inserted into every html page to allow the user to navigate between all available front panels without having to type in a new URL or make an awkward link on the actual front panels. Unfortunately, all that only exists in my head...

 

There are two modes of operation that users typically want.

1. A single application which deals the same data to multiple clients. This is fine for read only interfaces but for bidirectional you have to decide who has control for sending data to it. One client  to rule them all otherwise you get config whack-a-mole.. It is the preferred option for resource reasons.
2. An instance for each client which allows each client to control their instance. Each client sees something different and if making them all see the same thing is required, you have to handle it in the software itself (centralised data store) . This is extremely resource intensive and can bring your server to it's knees with enough clients.

Wow, that freeboard.io page is pretty sweet. I played around with it and made something simple using the CVT, might post a little tutorial for interested parties if I have time. I like that it just takes a json blob and then lets you display it.

 

The only downside I can see (vs something like data dashboard) is you don't seem to have the ability to set values using it. Its probably not too hard to add some js to send value change events, but it'd be cool if it were baked in.

 

There are lots of similar projects around the web . With this one, you create plug-in data sources that interface to your back-end. I prefer that model otherwise they would have to define a propriety protocol and dictate comms methods. This way they leave it up to you, which I prefer.

There are examples and fairly easy to implement.

[Mads]

I was asked privately by ShaunR what I disliked/missed about the existing alternatives, and go through the strong/weak points of each of the solutions.

To answer the question in part at least (it has been a while since I tested some of these options so I do not want to revisit to do a comparison etc...), I think the best starting point is to draw up two extreme scenarios:

 

Extreme A:  No web support in LabVIEW at all. We develop applications that run on a given OS, and the only way to let web browsers view and interact with the applications is if we add a client-server interface to the application, and then use different tools/languages to develop a web client for it.

 

Extreme B: Web server and client side applications are available as build options or defined as "targets" in LabVIEW. You can develop, build, deploy and run such directly from LabVIEW. With the target option, just like with LabVIEW RT targets, you would get a different set of functions available when working towards the web server or client as a target. Some functions are no longer supported, while other functions are added (compared to the regular desktop target).

 

So, where are we (the currently available solutions) between these two extremes today, and where do people want to be? (And/or are there other extremes going in a completely different direction...?)

 

Scenario A is obviously already available; and with web services etc. available, we do not need to develop this all from scratch. To get a complete client side application we can get a lot of help, either by getting controls or front panels on a web page, but we still need to use other tools to sow a complete GUI together. And if multiple users are supposed to work on the system in parallell a lot of the available solutions fail. Somewhere between A and B you have a scenario that many add-on makers seem to love; namely "put a front panel in the web browser". Great to have if that is all you need...

 

Having seen too many of the latter solutions though I might have fallen into a habit of dismissing new solutions as soon as I see that the examples the developers have used is just that; get a front panel into the web browser/on your iPhone...So I'm waiting for something that presents itself closer to scenario B (which is where I would love to be, although I do realise that that might never happen...).  National Instrument's got me interested when they launched the Web UI Builder - It was not integrated into the regular LabVIEW IDE, but it allowed us to code in G etc...so that was close, but not quite a sigar after all...

[ShaunR]

Hmmm.
 
Extreme A isn't an extreme, IMO. It is what all languages provide when it comes to servers - diddly squat. Servers are applications, not language constructs so you have to write them.
 
Extreme B has been sculpted by your LabVIEW experience and again. I don't see this as an extreme. I don't know of many corporate environments that use the NI webserver. They all want interfaces to their Apache, Nginx, Lighttpd etc. I don't know of a single IT department that I could convince to install the NI webserver, let alone supporting it so I'm not quite sure where to start with this.
 
That aside. Probably the only place the NI webserver is used exclusively is to embedded NI products, so that may be why this particular method is appealing to you The deploy/undeploy capability from the project manager is an abomination in my opinion. I don't want to have a full version of LabVIEW just to install servers. This is before we get to how undocumented and how no NI support is available when interfacing to the project explorer. It's a lot of effort for very little gain with probably you as the increase in sales due to this feature with what? One licence? There is nothing stopping you using one of the toolkits and creating such a deployment method but this is a very subjective requirement based on a particular workflow in one use case. So I am not surprised you don't see this unless you specifically commission someone to do it.
 
But in relation to the available toolkits. I'm not seeing any arguments around issues to create multi client, browser enabled  applications. In particular can you expand on:
 

And if multiple users are supposed to work on the system in parallell a lot of the available solutions fail.

Your terminology concerns me here."Work on the system" implies that you think these toolkits are an IDE extension for multi developer  programming environments. This is clearly not anywhere near their remit.

Edited October 14, 2015 by ShaunR

[Mads]

 

 

Servers are applications, not language constructs so you have to write them.

 

Who's talking about language? This is in a context of toolkits/general system design solutions available in or tightly supported by LabVIEW, the IDE and ecosystem.

 

 

 

Extreme B has been sculpted by your LabVIEW experience and again. I don't see this as an extreme. I don't know of many corporate environments that use the NI webserver. 

If I say it is an extreme you might need to evaluate it as such and see what light that sheds on the scenario

I never talked about the NI web server, and in scenario B (the true extreme one) you would probably never care about it at all. You would write code that can run on any web server or client.