For a while now, I’ve worked on using HTML pages as an interface to a remote cRIO system. In the National Grid power quality system I worked on, each unit has a web page for monitoring and configuration.

One thing that is much easier with HTML is making dynamic pages. I previously worked on a project with the embedded display on the compactRIO which had to be dynamic depending on the configuration. It was a bit of a headache, I had to script positioning different panels on the UI since there are no subpanels. It worked well in the end, but there was a lot of added complexity.

So when I had a new project with the needs for a pretty simple UI, but possibly some dynamic content (different channel counts) I wondered, could I write it in HTML and display it with a browser on the embedded UI?

I hoped this would:

• Look better.
• Be easier to make dynamic.
• Integrate better with accessibility tools like the on-screen keyboard.

The Concept

The basic design consisted of 4 components:

1. The actual LabVIEW VI. This was a very state-based UI so we could just write the latest state to global variables without much trouble. There were a few commands that could be sent through a queue.
2. The LabVIEW HTTP Interface. I built a web interface so the state information and commands could be sent and received as HTTP or REST calls.
3. The web page (thin client). I wrote this using Javascript in the Vue framework, but it could just as easily use the NXG web module (or whatever that will be called by the time you read this). This is served by the LabVIEW web server and talks to the HTTP interface.
4. A browser. I need to launch a browser on the system to display the page.

Getting It Working

The LabVIEW and Javascript parts were straightforward enough. I had done similar things before and I got it working over a remote connection without too much issue. The question was, how to display this on the embedded UI?

There are a number of browsers available on Linux, but what would work on cRIO?

I went first to Firefox. It has a kiosk mode to make it appear as a full screen app and limit user interaction. And I managed to find instructions on what was needed to run it on cRIO.

The “installation” process was to install a couple of dependent libraries using the NI package feeds, then download and copy the pre-build x86 Linux binaries from the Firefox pages. As I write this, I see this complete guide exists which I missed before.

The thin client was included in the LabVIEW web services project as static files and that was included in the real-time executable. When the executable starts I used system exec to launch firefox in kiosk mode to the right page.

Aside – On Screen Keyboard

One thing I really thought this would make easier would be the on screen keyboard. I hoped by using HTML the integration with this would be automatic.

Not quite, it just didn’t work. I installed the florence keyboard but couldn’t get the auto-activation to work. There is something to do with accessibility libraries that are included with the Xfce desktop. Because of the time, I gave up on getting this working. The usage I needed was limited so I was able to integrate simple-keyboard.js instead.

First Look

Everything looked very promising. The page and display launched as expected.

I can’t share it as it is a customer project but it looked pretty good to. I had a rare experience on a LabVIEW project of a customer commenting on how good it looked!

Time to put it through final testing.

It All Falls Down

As with any embedded project, a key test is a longer running test. When I came back in after it was running overnight, it was gone. Nothing was running.

I repeated the test in case I did something wrong, same problem.

Not only was Firefox crashing, but it took the RT app with it. I tried some techniques to isolate them a bit more but fundamentally it wasn’t stable enough.

I looked at the performance and unsurprisingly, firefox was too much for a cRIO-9030. It was using significantly more RAM than phyisically existed, in itself that isn’t a dealbreaker, but something was causing it to crash. I managed to find logs that pointed to memory issues. I checked the javascript for memory leaks but no luck.

I tried to find other, lighter browsers to try but struggled to get any working easily. I think there probably are some that you could build for it, but at this point I didn’t have the time.

Back To LabVIEW

At this point I re-wrote the UI back in LabVIEW. I had planned time into the project in case I had too so this wasn’t a major concern. Here is what that meant for the system:

• CPU dropped a lot. Firefox was using around 15-25% CPU, LabVIEW was generally under 10%. This isn’t a big surprise, especially with no graphics card for Firefox to leverage.
• I couldn’t go back to a traditional LabVIEW UI. I took some time to replicate as much of the look and feel from the HTML pages as I could and it looked pretty good to be fair – just a few dynamic elements were hard to replicate like highlighting selected array items for example.
• Luckily, I already had a basic on screen numpad implementation from a previous project for the same customer, otherwise that would have made it much harder.
• I believe it took about 4 hours to rewrite in LabVIEW vs 20hrs in Javascript. Take this with a massive pinch of salt! I was basically learning the vue.js framework, writing in a numpad component which I already had for LabVIEW. I was also copying the styling and structure into LabVIEW. Still its rare you get to build the same thing twice and compare!
• The system was stable.
• When we increase the channels though, I will have to do additional work on the LabVIEW UI which I wouldn’t have to do on the HTML client. It automatically adapted to different channel counts.

Conclusions

So a failed experiment but an interesting one, I hope this might help or inspire someone else. The most interesting bits for me were:

• Remembering how heavyweight browsers are. But also UIs. If this VI was doing anything more on the RT side I would be concerned about the embedded UI too and the impact on performance. As it happens, all the hard work is done on the FPGA.
• There is a case for limiting usage of the embedded UI due to this and looking at panel PCs instead – though this really depends on how complex the communications might be. The isolation must be good for stability though.
• The LabVIEW UI is remarkably powerful and fast to work with. It just does fall down when you want:
  • something more dynamic i.e. 8 or 16 channels.
  • to add a consistent styling throughout.
  • A form style input without a lot of faff.
• HTML did look better, partly through better technology, but also through easier experimentation. Maybe using HTML to mock up panels before implementation in LabVIEW would lead to better UIs?
• A nice, lightweight way of running a single HTML view could still be an interesting replacement for a LabVIEW UI. There may be some convergence with the work I’m doing in Rust at some point.