Browse Category: Uncategorized

black background with text overlay screengrab

HTML On CompactRIO

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.


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.

Testing HTTPS (SSL) Connections on NI LinuxRT

This is a VERY specific post – but it took me a while to avoid red herrings so I thought it was worth sharing. Sorry LabVIEW folks – this is all about LinuxRT!

I had a system that was having issues connecting to a HTTPS server (for WebDAV). It had previously been running without issue and then just stopped.

As I couldn’t disturb the software directly I logged into ssh and tried the following:

  • nslookup <server> – This pings for DNS to make sure we have a valid address for the server. This passed.
  • ping <server> – this failed but after testing from another system that also failed, so this server probably has ping responses blocked.

My next step would be to try curl which allows command line http(s) but that isn’t installed. Instead I found that I could do a security check with openssl. This should confirm that the certificates work and the port is reachable.

The command was:

openssl s_client -quiet  -connect <server>:443

This failed! Hmm – maybe because this is an older LinuxRT distribution there is a certificate problem. So I went hunting for the certificate store.

It turns out there isn’t a central store automatically recognised by openSSL. So for the proper test we actually need to link to NI’s certificate bundle at /etc/natinst/nissl/ca-bundle.crt (On LinuxRT 2017, but I would be surprised if this moves).

I expect this is true of any command line tool that uses SSL – so if you do install cURL it will probably need a link to this.

So now the command is:

openssl s_client -quiet -CAfile /etc/natinst/nissl/ca-bundle.crt -connect <server>:443

That works and I have to move on in my troubleshooting. (At this stage it is working again without any intervention – not sure whether to be happy or not!)

Open Source LabVIEW – How To Contribute


Open source software projects are making huge contributions around the world. They allow communities to pool their resources and achieve progress that couldn’t be reached by individual teams in silos.

While there are open source projects in LabVIEW, it feels like a resource that we aren’t great at using as a community. Every project I’ve seen seems to handle things quite differently, and it can be hard to track down where to work. Since I started the first draft for this post it seems there have been discussions in the US on the same topic:

In this post (and another on setting up a project). I want to collate what appear to be best practices in other communities to see if we can’t improve the open source capabilities in our community. There are hundreds of guides out there – so I will be liberally linking to others and trying to highlight the potential differences in LabVIEW.

Open Source Project Structure

So what is an open source project?

In short, it is a project that someone has decided to make available for free to everyone to use and improve. I’m not advocating making all of your work free, but often, there are bits of sawdust – the bits of code or tools that you have lying around to make you more effective, that you can share and help drive the community forward.

Firstly let’s look at the people involved in a project:

  • Maintainers – Normally the original developer, they are responsible for the master copy of the project. It may also include trusted contributors who have taken on more responsibility. As well as working on the project, this is the group that will be involved in setting a direction for the project as well as assessing and accepting contributions.
  • Contributors – These are people that have provided code changes or documentation to the project.
  • Users – More obvious, people who are using the project themselves and may contribute bug reports and other issues.

Find Projects

There are some tools for finding open source projects to use or work on, but don’t be surprised if LabVIEW is missing from the list.

If you are looking for a project for a specific function, then Google may be the starting point. However, when I tried this with Modbus, the results weren’t great. Adding “open source” to the search got us closer, we now see download pages, but no source code.

So, to do better, we need to search some common places for open source projects to be hosted. We can stick to Google for this. By far the most common for new projects is so we add ( and can be worth trying too). Now we see two open source libraries

Of course, those sites have their search functions which can be useful too.

If you go to and enter “language:LabVIEW” into the search box, it will show you all of the LabVIEW projects on there. You can then add additional search terms to narrow it down.

A big concern with open source is how do you know if this project is reliable? There are a few indicators that you can consider:

  • Most services have some form of user rating – while the small size of the LabVIEW community doesn’t help these – you may be able to apply some judgement to them. For example, projects can be “starred” on GitHub.
  • Look at how active the project is. GitHub will show you the latest commit, and you can also see releases, commits and contributors at the top. If there is a good commit history or multiple contributors, this is a good sign the project is active which usually means a higher quality output (since maintainers are fixing bugs or improving the code base).
  • Finally, it is open source! Download the code and examples and take a look to see what you think, try it out quickly before committing to it.

Use and Report Issues

The simplest thing you can do to support a project is using it! From the GitHub page you should be able to find directions to install the project and possibly directions on reporting issues.

I try and will be convincing others to do the same, to use the built-in issue tracker on GitHub or bitbucket. This means that:

  • The issues and discussions are public so others can contribute.
  • When you have an issue, you can search this first and see if there is an existing solution. (yay for reduced support burden!)
  • The issues list becomes a list of items that new contributors can work on.

When you find a problem or something you want to change, the first thing to do is create an issue. This allows you to open a dialogue with the project maintainers about the problem. They may already have a fix, or they may suggest you contribute the change yourself.

Fix Issues and Contribute

Firstly, contributions don’t have to be code. I was delighted on the LabVIEW CLI project to have help producing a getting started guide. Maintainers sometimes leave documentation and examples to the end but they are hugely valuable. Of course, you can also contribute to the code base as well.

A good project should have a contributing guide in the repository. This will let you know how the maintainers want to receive contributions. This is also a great place for details on things like LabVIEW version, source code structure or build instructions.

If ther is no contributing guidelines, there are some excellent guides for this already, so I’m not going to repeat them here:

  • A good general description:
  • A LabVIEW specific guide to Github (covers starting from scratch):

Further Reading

I hope this article gets you interested in contributing to open source in LabVIEW. If you wanted some more comprehensive guides then I suggest the following:

  • First Timers Only – A guide for those who haven’t contributed to open source before.
  • Open Source Guides – A comprehensive set of guides for open source. The link here is to their contributing section.

But most of all – starting using a project today and let the developers know what you think!

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.