Webserver With RT Desktop (ETS)

[bradth]

I have worked with cRIO applications that have RT code running on the FPGA (target) and serving the front panel as a webpage on the host (the cRIO's processor).  Now I am working with a less performance demanding but still RT application.  It is being deployed on a stand-alone desktop RT setup (ETS). 

I wanted to get thoughts on using a RT desktop with a webserver.  So there would only really be a target application.  This target application would have the front panel (unlike most RT setups where there is no FP on the target).

[nathand]

What is your question?  We use an RT desktop system to serve a front panel (mostly for confirmation that the system is running properly, not for interactive use).

[bradth]

I have always followed the best practice of not placing controls on the user interface on the FP of a RT target (PXI, cRRIO).  Since on a RT ETS, the deterministic code and the webserever/user intereface would end up on the same layer this breaks that "rule".    

Do you use the webserver on ETS desktops?  Is the above considered bad practice with desktop ETS?  

I have verified procesor and memory usage, but I am concerned about webserver resource usage variabilty. 

[nathand]

I've never seen this stated as a best practice on any RT target and do not believe it is accurate.  Can you cite a source?  An ETS desktop is no different than any other real-time target, other than that the desktop may have more processing power than a cRIO or Fieldpoint system.

Put time-critical functions into separate VIs set to run at time-critical priority and update the user interface in a VI running at a lower priority.  The web server runs in the background at low priority so it should not affect VI performance.

In our case, we place mostly indicators on the front panel; we use the web server only to view the program running on the RT target, not to control it.  If you need a full-featured user interface for a program running on an RT target, you will need to design a separate host application for that purpose that can run a desktop PC, because many common user interface elements do not work as expected over the web server/remote front panel connection (one example that comes to mind quickly is file selection dialogs).

[bradth]

I think we are talking to the same point here....Typically a couple of indicators is fine on a RT target front panel as long as you are not using them to store state information (as the front no longer exists when you disconnect).    I think the RT cources state as a best practice - stay away from have anything on the front panel of RT and this mitigates people getting into this problem.

ETS is different than a cRIO/FPGA in that you are missing a layer... you have both a target and a host on the cRIO/FPGA.  We use a full interface webserver on the cRIO uP host with a webserver with no problems, user controls and all.  This is nice because you do not need to develop/deploy a target PC application.  Never seen the selection list issue or had issues with other controls (there are a couple of tricks though that need to be done when a connection is made though).

I have not seen a way to set the webserver's priority, so that's partially where my concern is in running it on the same layer as deterministic code which inherently has to be done on an ETS.

Anyone used webserever (with user control) and ETS?

[nathand]

---

bradth wrote:

ETS is different than a cRIO/FPGA in that you are missing a layer... you have both a target and a host on the cRIO/FPGA.  We use a full interface webserver on the cRIO uP host with a webserver with no problems, user controls and all.  This is nice because you do not need to develop/deploy a target PC application.  Never seen the selection list issue or had issues with other controls (there are a couple of tricks though that need to be done when a connection is made though).

---

Any desktop you use is going to be much more powerful than the processor in the cRIO, so if you find the cRIO works fine, I doubt you'll see any issues on a desktop.   I usually split the processing between the FPGA and the cRIO host so I don't think of it as two separate layers.  Note that I didn't say selection LIST, I said file selection dialog, which won't work on RT.

---

bradth wrote:

I have not seen a way to set the webserver's priority, so that's partially where my concern is in running it on the same layer as deterministic code which inherently has to be done on an ETS.

---

Based on your comments, you're worrying about a non-issue here.  If you can run all your cRIO code on an FPGA with no need for the host to do any work, I can't imagine that you'll be taxing a desktop that heavily.  Also, I seem to remember running across an NI document that specifically said the web server runs at low priority - search ni.com for best practices for developing RT applications.

[bradth]

This is a different application/project from previous cRIO/FPGA applications/projects. (It was mentioned because we typcailly put the deterministic code on the FPGA and thw webserver and lower priority code is on the uP.  Can't do that on an ETS. Hense the question and concern.)

[Aldo_A]

Hi bradth,

For an ETS System, it can also have 2 sides: the Real-Time Side and the FPGA Side (if you have an R Series card on the PC). The webserver will run in a lower priority just like the cRIO and should not get in the way of the RT/FPGA side. If the PC is being taxed, LVRT will shut down all comm. to allocate resources for the RT application. There shouldn't be a problem with an RT PC if there is no problem in a cRIO. I hope this clears up any questions.