I have a few VIs written using the LabView desktop application which I'm trying to convert as web-based panels. As I went through the documentation I see that the G Web Dev Software is the current official way to do this so I have been trying it out but I have ran into a few issues. Can someone please help me with the following questions:
1. Is there a tool to convert my existing VIs into Web VIs without manual intervention? I have seen the tutorials for creating Web services and HTTP method VIs but I'm afraid that these won't scale up to my requirement as there are quite a few complex inputs and I do not want to risk the existing setup.
2. Can G web development software refer to my VIs (NOT Web VIs) without additional controls/ conversions being introduced? If yes, can you please provide any documentation on how to do this?
3. My fallback right now is to use the web publishing tool in LabView which embeds the VI using the NPAPI plugin system. Since the architecture is deprecated now I can only use this with IE in the current state. Is there an updated alternative to doing this?
It would be great if there was an updated option for #3 since manually re-working the existing VIs is difficult to scale since the VIs have been stabilized for a while now.
Thanks for the help!
Solved! Go to Solution.
LabVIEW and G Web are completely separate, unrelated tools. Well at least outside of the fact that they're both made by NI and are programmed in G. The best way to think about G Web is that it is a webapp tool where you can make an application that can talk to other applications like any other webapp can, plus some APIs included for doing so through SystemLink services (Tags, Messages, Files). To use LabVIEW apps with G Web interfaces you need to write the LabVIEW app in a way that it can be accessed by a Web App through web technologies which can include: LV Web Services, WebSockets, and SystemLink APIs.
NI has prototyped an update to remote panels and demoed it at the last NI Connect but there's no timeline on that.
You can get an idea of integrating web communication within a QMH based app in this example: https://github.com/illuminated-g/lv-sl-gweb-demo which as the repo name implies, uses the SystemLink APIs as a low barrier-to-entry way of linking the webapp and the LV app. You don't need a SL server to utilize the APIs though of course you can or use SL cloud if you'd like even easier remote access and don't have restrictions about data hosting and cloud access.
Derrick stated it beautifully. Another resource that will help you understand how G Web Development Software relates to your existing LabVIEW application is the How to Build a Web UI for Your LabVIEW-Based Test System presentation.
It will guide you step-by-step through the tools included with G Web Development Software and how you can put them together for your LabVIEW application.
Thank you very much for making the differences clear. So, to confirm my understanding, I'd have to make changes to all of my planned VIs before I can access them through web using the G web dev s/w. I'm afraid that would not scale for me but I will try to see what I can do.
On the same note, is there an updated form of the embedding option made available through the 'Web Publishing' tool in the LabView desktop s/w? I can get the current version to work on IE only since the other browsers have dropped support and it seems to be the best option for what I'm trying to do.
This is where software architecture really becomes important. A purpose-built VI or small collection of VIs made for a single task isn't easy to change how its interacted with. When you start abstracting user interaction and UI away from the logic of an application, it becomes much easier. It can seem silly for small test apps but it can become second nature. The repository I linked uses the QMH template from the New Project wizard in LabVIEW and tacks some remote interaction logic in as a 3rd loop to the application. I didn't have to change the local UI handling code at all and the message handling loop only minimally changed to publish UI updates as messages in case any web UIs are connected. LabVIEW makes it overly easy to intermingle UI and business logic which makes refactoring and adding in additional interaction mechanisms difficult.
As for the embedding option, that's the remark I made about them having prototyped an update and demoed it but there's no timeline yet.
Actually there is one way, but it is very ugly...
If you have LabVIEW NXG, it has the ability to import classic LabVIEW files and even entire projects.
The G Web development software can open these NXG projects and save them as a G Web library.
Of course, not as *.webvi, but as a standard *.gvi
Code revision is required at every stage of this transformation!
In fact, if your LabVIEW project is too complex, it's best to create everything from scratch in G Web.
Sorry for stomping on the suggestion but it really shouldn't be suggested trying to go through NXG at this point with all the manual effort needed anyways. While that may produce something in G Web, there's a 99% chance it isn't what anyone would be looking for. Most LabVIEW applications are running on a specific machine because they need to talk to connected hardware. Perhaps they're doing file I/O. Also keep in mind that UI functionality in G Web is drastically less than what's available in LabVIEW. Now they have a Web UI that still needs to be changed to communicate with an app doing the real work so 3/4 of what the conversion made gets thrown out, assuming it succeeded. And then if anything is still being updated, the whole process has to be gone through again which isn't a very maintainable process. NXG also doesn't get any more support so if any issues are run into, good luck as you can't email NI about them.
It really is best to think of the two apps as isolated tools. It's annoying having to creating matching typedefs on both sides to use across communication mechanisms and make a new UI if it's anything complex but that ultimately matches what's being done: creating a different remote view app that runs in someone else' browser.
NI was getting a handful of support issues regarding embedded remote panels being gone so hopefully that's tracked and they prioritize the update at some point because otherwise what's left is doing your own web app development.
I agree with this. In my current scenario, the VIs are running some critical stuff so taking them apart or re-writing them would require quite a bit of time to get things back up safely and in time. It's a little surprising that the embedded option isn't used more often since that seems to be the fastest way to get the panel up without having to fiddle with the configuration itself. Well, I just hope that they prioritize it at the earliest 🙂