LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Remote Front Panel versus Web UI Builder

I am designing a system that will be monitored by a computer on a remote network and I'm having trouble trying to decide between using Remote Front Panel or Web Services (NI's Web UI Builder).

 

Can anyone provide me with a comparison of why someone would use one over the other? I've learned a little bit be reading the FAQ.

 

Web UI Builder FAQ

http://www.ni.com/white-paper/11604/en

 

 

Thank You,

Craig

0 Kudos
Message 1 of 6
(3,011 Views)

Is the system (aka data server) on the same network as the PC (aka data client) you need to monitor it from? How much development time can you spare? How secure do you need want it to be?

 

Web Services and Web UI Builder take more time to develop but have extra security benefits that you can enable. Web UI Builder doesn't need a LabVIEW Run-Time Engine installed on computers to view. Only Silverlight (which comes pre-installed on newer Windows machines) and a web browser.

 

Remote Front Panels is really quick and easy to implement but need the LabVIEW Run-Time Engine installed on any data client that wants to use it. There are no extra security measures with Remote Front Panels and the data being communicated between the server and client is a NI proprietary encryption that some firewalls have fits over. Web Services are a web standard built on top of TCP and HTTP so firewalls like them better.

 

Overall, I use both quick often but normally if I need something quick/easy and the system is on the same network then I use Remote Front Panels. If I need something that has security and works with external networks (i.e. I can access my test system at work from the airport) then I use Web Services. Web UI Builder I use if all the clients are going to be Windows PCs because Silverlight is a requirement and doesn't work on mobile devices or Mac/Linux. 

0 Kudos
Message 2 of 6
(2,996 Views)

Slight correction.  Silverlight works just fine from a Mac if you are using Safari or Firefox (Chrome has issues).

0 Kudos
Message 3 of 6
(2,994 Views)

JoshuaP is correct. The run-time plug in does work on Windows and Mac OS X. There were some efforts to port Silverlight to Linux and Unix, called project Moonlight, but that was abandoned. 

0 Kudos
Message 4 of 6
(2,982 Views)

G-money,

 

The data server (a cRIO) is not on the same network as my data client. I'm not sure how to answer your "Development Time" question buts lets say my application has 10 inputs and 10 outputs that I'd like to display and control respectively. I would prefer to spend no more than 16 hours of development for something this simplistic.Security, I'd like a basic login in order to access the data server. SSL would not be required at this time.

 

I think your comments about Remote Front Panels vs Web Services makes sense. I assume that another advantage is that the Remote Front Panel Application must be the main application running at startup on my cRIO where the Web Service would be a parallel VI/process that would be independant of the Real-time process? Let me know if this assumption is correct. Thank you for the response.

 

Craig

0 Kudos
Message 5 of 6
(2,956 Views)

craige,

 

          Your assumption on Remote Front Panel (RFP) over web services is correct. User Login in could be done two ways:

 

1) You could add username/password functionality to the front panel of your LabVIEW application (adding logic to handle security to your block diagram of course) and then use RFP. RFP functions the same way as your application so users would have to log in to interact. Only one person can control an RFP (many people can view though) at a time so this might not work for you.

 

2) Web services has an option where you can easily add this functionality through NI Auth permissions. It basically a 5 minute setup on your system and one extra "check box" when building your web service. Through this you could define that people signing in with this information can do <blank> while another set of information can do <blank>. If it was me, I would go with this option.


Going with web services is also preferable because it is a web standard. It will be easier to get through your firewall with no issues. RFP using TCP at a low level but we have a "NI wrapper" around it that makes it proprietary data transfer. Some firewalls see this prorietary transfer as a potential threat and can lock it out. You can add exceptions to your firewall of course for RFP but web services normally have a better time getting through networks. Since you are communicating from an external network (one that your cRIO is not on) then networking could be more challenging. Save yourself some potential headaches and go with web services.

 

If you would like a quick demo of web services with username functionality, shoot me an private message on the community and I can do this easily (I'm doing it today in fact for a group of LabVIEW developers in Austin, TX).

0 Kudos
Message 6 of 6
(2,948 Views)