Viability of a web interface hosted on cRIO

[cbutcher]

So whilst I'm sure this is possible, before I head off down a rabbit hole I wanted to ask for encouragement or reasons to avoid...

I'm considering implementing a web UI for code running on a CompactRIO (9045), initially for display of slowly changing information and perhaps configuration of settings, but perhaps later for the visualization of recent data (I imagine this would require the storage of the most recent data acquired into a circular buffer, with the accompanying memory cost).

I'm not sure if for this I should

a) not do it

b) use a Web Service and (GET) Web Resources, along with LabVIEW-based parsing of html (I've done a very basic example of this for my build system, it works but I wouldn't consider it particularly scalable, see basic image below)

b2) as in b), but with some different HTML generation method. Not sure what this might look like...

c) use something like Node.js (either Linux binaries, or compiled on cRIO, or cross-compiled) and writing a server-side website hosting system, and then storing data from LabVIEW in some accessible format (things like settings/config and slow historical data, forming the first goal, can be stored in e.g. SQLite using James Powell's library, I already have this working).

Basic implementation of a 'website' a-la b) above:

Top-level GET VI

One of several subVIs, here taking a 2D string array and producing an HTML table

Feedback also on the possible performance costs of running a web server (LabVIEW or otherwise) on cRIO would be appreciated - will this cause problems with jitter, how careful do I need to be regarding that, etc.

[wiebe@CARYA]

If you're going low level, and not planning to make things complex, you might as well use raw TCP\IP.

I know there are embedded (microchip) examples. Can't find one now though.

The Web Service tools might make things a bit easier. HTML packages can probably be encoded, encrypted and split up, and that library might handle that for you.

I've done a few raw web servers long, long ago. A server isn't that different from a client. It's a pity that the HTTP VIs are made inflexible, or lots of it could be reused. A copy could be made of course...

[Jorn_Deruyck]

I wouldn't generate the HTML of a webpage inside a webservice request.

Instead, you can also include a folder that contains static html documents inside the LabVIEW Webserver:

This folder can contain any document you want, and the labVIEW (Embedthis) webserver will 'host' it.

This roughly translates to sending the contents of the file to the client when a GET request is performed on a resource that represents any of these files.

You can develop your html page including javascript and css files as you would when creating a normal web page, then put them in that directory.

Use the webservice request handlers to pass sensor/configuration from/to the javascript code running inside that web page.

Configure the vi to use 'streaming' and pass the information as JSON text for easy interfacing with your js code.

When you want periodic asynchronous updates from your LabVIEW code to the front end, use either SSE streams or websockets.

Long story short: go for option b2 🙂

[DerrickB]

To add to Jorn's reply: I tend to dislike being forced to interact with Web Services through globals so for any kind of dashboard / interactive web app that would repeatedly be talking to the controller I'll avoid Web Services and just run a WebSocket server. Then it's more or less just like a TCP stream once the handshake is done that I can send JSON (or anything else really) back and forth across. The web app also doesn't need to poll the controller for updates, the controller can just send updates to connected UIs. Perhaps I'm just used to working through TCP so the similarity in architecture is nice and fits in right along side communication with HMIs written in labview and running on desktops.

With any solution, you have the freedom to host the web app anywhere, it doesn't necessarily need to be on the relevant controller. If there's other systems available on the network that could host the static files I'd prefer running Apache/Nginx/NodeJS there and not burden the cRIO with serving those files. The web app hosted on another machine can still do the AJAX or WebSocket connections to the cRIO, or even be written to coordinate data from multiple systems. Then again 90% of my work is still done on 9074s with much more limited resources so maybe just ignore me!

[Sizeland]

I run React based web apps through web services on cRIO 9063s all the time, with no noticeable performance issues. The client browser runs the JavaScript anyway. I use FGVs to get data and queue APIs to post back to the LabVIEW backend, works very nicely.

[nibuddy1777]

Which browser are you using on the cRIO ? Chrome ? I need to launch a web browser from my crio’s embedded LabVIEW UI and then close it . 

[IlluminatedG]

You don't use a browser on the cRIO, the main idea for web services is to be able to serve data to other networked computers. If you have local access to the cRIO and the app it's running, why not just have a UI built into the cRIO's app?

[nibuddy1777]

We have a embedded UI on the cRIO already, but we have another web interface that interacts with both the cRIO and another system that we are using a tablet to interact with. It would be better if we could pop open a web browser to interact with it.  Also there are some things that are not that flexible or even impossible to do with the labview UI.     It is similar to this blog post --https://devs.wiresmithtech.com/blog/html-on-compactrio/

[cbutcher]

---

@nibuddy1777 wrote:

We have a embedded UI on the cRIO already, but we have another web interface that interacts with both the cRIO and another system that we are using a tablet to interact with. It would be better if we could pop open a web browser to interact with it.  Also there are some things that are not that flexible or even impossible to do with the labview UI.     It is similar to this blog post --https://devs.wiresmithtech.com/blog/html-on-compactrio/

---

I think what you want is what Derrick is suggesting - that your cRIO provides a server behaviour, hosting HTML/a webservice/whatever and that then your tablet/computer/phone uses its browser (Chrome, Safari, whatever) to browse to http://my.compact.rio/awesomePageGoesHere.html or similar.

A combination of Jorn's webservice or Derrick's WebSocket server (to provide an API to fetch data, send commands to the cRIO, whatever) and perhaps Sizeland's ReactJS frontend (I'd probably host it directly on the cRIO, but as Derrick pointed out, you could do this on some other network-attached host, and then connect there, but consider if CORS will impact you...) would be how I'd set this up if I worked on it today. (I believe several if not all ReactJS template tools (is this the appropriate name for CRA etc?) give options to build a static page if appropriate, which could help with hosting via the LV webservice if desired - but not required.)

Indeed, I might try this in the not so distant future, perhaps even considering NI's new push for gRPC. But maybe not...

[IlluminatedG]

I was meaning to host all the web content on the cRIO, just view it on another system. Of course the only roadblock to this is if its on an isolated network but I'm assuming that's not the case since they mentioned there's already another web interface for other uses.