Remote front panel: loading VI into controller memory

Hi everyone,
I am currently using LabVIEW 7.1 and need some expert help.
I have a VI (which also include more than 80 sub VIs) that controls a system through compact Field Point module controllers. Currently, all these VIs are stored in a server computer.
At this stage, I am capable of creating a remote front panel, which allows me to control the system from a client computer other than the server computer. Instead of using the server computer to control the system, I would really rather to use my field point controller to do the job, and I have the following questions:
1. In the server computer, VI can be loaded to memory by opening the VI, how do you do it if you were to use the cFP-2015 controller as a server?
2. I created a "startup.exe" and the "htm" files for my program and stored them in my controller and set it to launch application at boot-up. For once, I can access to my controller from the web. But once I close my browser, and re-access the web, the memory in my controller seems to be lost and I got an error message saying VI was not loaded in server memory. Is it possible to store the VI in the memory of my controller for a long time??
Many many thanks in advance.
Tak

Hello Guenter,
Thanks for your explanation. I think your description match very well with my observation. Your suggestion of flashing the LED while my program is running is a good idea.
Sorry that I didn't describe what happend well enough, here is what happened to me.
I embedded the program which simply turn on and off one of the LED on my cFP controller for 20 times.
I re-boot my controller and wait some time, I then see the LED turns on and off.
Before my program finish, I can access to my remote front panel page for multiple times even after I closed my browser while the program is still running.
If I request control over the controller, I can manually stop the program, and then re-start it.
However, after I re-start the program remotely, if I closed the browser even while the program is still running. The program stops as soon as the browser is closed. When I re-open my browser, it says the requested VI is not loaded in the memory on the server computer.
So, correct me if I am wrong, it sounds like embedding my program as exe file, download to my controller, and set it to launch the application at boot-up is the only way to load the VI into controller's memory. Is there any other way?
So, having said that, I have to re-boot my controller every time when I want to start my application file that is sitting in my controller, is that correct?
Many thanks again.
Tak

Similar Messages

How to display remote front panels of subvis that are already open

I inherited an RT project that uses remote front panels for nearly all the user interfaces. The host application opens a remote front panel the the top level RT vi, and there are several subvis on the RT system that are opened from that top level vi and thus displayed on the host (i.e. their "Show Front Panel When Called" properties are set TRUE).
If the Host loses its connection to the RT system when any subvi front panels are opened, and the host application is restarted, it can re-open the top level vi remote front panel, but all the RT subvis that are already open will not display their front panels. I am looking for a way to open the front panels to these subvis from the host application.
The kicker is, I need to know which subvis are actually running before I attempt to open remote front panels. Is there any way to determine what subvis are actively running (and not just in memory, such as subvis that won't get executed until the top level vi reaches a certain state)? I am thinking that I could create a list of the subvis that I need access to, check to see if any are actively running on the RT system, and then invoke a remote front panel connection with those that are running.
Does anyone have any ideas as to how I might be able to do so? Or any other suggestions? [and yes, I know that RFP communication is probably not the best way to go, but we're too entrenched in this software to start over with a new system!]

TurboPhil wrote:
If the Host loses its connection to the RT system when any subvi front panels are opened, and the host application is restarted, it can re-open the top level vi remote front panel, but all the RT subvis that are already open will not display their front panels. I am looking for a way to open the front panels to these subvis from the host application.
It might be possible to work around this behavior by placing VI invoke nodes in your top level VI that reference each of your subvis and setting the Wait Until Done invoke method to false. This should cause the subvi to close when the top level VI closes even in the case of an unexpected restart.
You can access this invode node in the functions pallet by selecting Application Control » Invoke Node and also selecting Application Control » Static VI reference. Wire the Static VI Reference to the vi reference input node and double click the Static VI Reference and select the appropriate subvi in the dialog window. Left click on the Method section of the invoke node and select Run VI. Finally right click on the Wait Until Done invoke method and select Create Constant and ensure this constant is set to false.
TurboPhil wrote:
The kicker is, I need to know which subvis are actually running before I attempt to open remote front panels. Is there any way to determine what subvis are actively running (and not just in memory, such as subvis that won't get executed until the top level vi reaches a certain state)? I am thinking that I could create a list of the subvis that I need access to, check to see if any are actively running on the RT system, and then invoke a remote front panel connection with those that are running.
You can access this information by using the Real-Time System Manager (Tools » Real-Time Module » System Manager). This can be used to show what VIs and subvis are loaded into memory and which are running.
For more information on using this tool please referere to this Knowledge Base article.
Message Edited by BLAQmx on 02-18-2008 11:40 AM
Mark
LabVIEW R&D

Remote Front Panel Problems and Best Practices

All,
Problems
I'm currently attempting to host a Remote Front Panel from a cRIO 9073. The intent of the front panel is to control and configure the services running on the cRIO. Currently I've been experiencing quite a few problems getting this to operate smoothly.
These are the problems I'm currently experiencing.
* Front panel takes a very long time to load (~45 Seconds).
* On close the front panel may reset the cRIO.
* Front panel may cause excessive CPU usage.
* Plugin has problems in Firefox.
I'm fairly sure that I've installed all of the Latest NI software (I'm using LV 2009f2)
I currently cannot post the code as it's proprietary.
Currently the front panel consists of two timed loops one running at 500ms intervals and the other running at 1000ms intervals. The GUI is basically a tab control and on the heaviest tab contains about 15 buttons.
Questions
Is it not possible to use event structures in embedded LabVIEW? So far I've had to code my own event loop to handle all the events I wish to process on the remote front panel, and I feel this might be causing a problem.
Is the sort of functionality I'm trying to achieve acceptable in Web Front Panels?
It seems that the reason it takes very long for the VIs to load is that the VI Front Panel Server must fire up. Is there a way to make this or whatever the component is that handles it fire ahead of time?
Thanks for your time, I look forward to discussing this.
Regards,
Ken

Hi Ken,
Is this a remote front panel for a real-time VI? Is it built into an executable? If this is a RT VI, you cannot use event structures. More details are available in this KB:
Can I Use the Event Structure in LabVIEW RT?
I assume you have seen this?
How Can I View Remote LabVIEW Real-Time Front Panels in a Web Browser?
Are you still having the cRio reset issue and CPU usage increase?
Kristen H.

Do you need a web browser and internet server to run LabVIEW remote front panel?

Does anyone know if ones needs an internet server to use the Remote Front Panel application of LabVIEW, or is it also possible to use a LAN/WAN for the same application? if it is possible, how does one set up such a system?

You can do this on any IP based system (which includes LANs).
Basically, you need to be able to ping the server and to have the RFP port allowed in the firewall.
Then you need to enable the option in the application. If this is an executable, you will need to configure this in the Options dialog or copy some lines from the LabVIEW.ini file into your EXE's INI file. You will also need to take the htm file created by the publishing wizard and make sure it points to your VI and that it is located in a place where it can be accessed from outside the server (read the LV help or search the site for more on this).
Then, you just need to enter the URL for that htm file in the browser on the client (e.g. 192.3.42.5/c/rfp.htm) and it should load.
Try to take over the world!

RT Remote Front Panel issues.

I'll start with my setup:
2 PXI-1042 chassis connected via fiber-optic using NI PXI-8336 (MXI-4) cards.
Chassis 1: PXI-8108 embedded controller running LabVIEW Real-time OS (2010), PXI-6528 DIO, PXI-8336 MXI-4.
Chassis 2: MXI-4 in slot 1, 4 PXI-8334 DMM, PXI-6528 DIO, PXI-6281 M-series DAQ.
The real-time executable monitors analog and digital inputs and DMM measurements, displays the values using numeric and boolean indicators, generates alarms and allows users to acknowledge alarms via a Remote Front Panel. The code has a custom error handler that traps errors and stores them in a global array. This allows the code to display them on a console and allows the user to acknowledge and clear errors, and scroll through multiple error messages. We used property nodes sparingly.
The system is monitored by two laptops with the correct run-time engine installed (both laptops have the LabVIEW development suite). Under normal conditions, one laptop keeps control of the Remote Front Panel at all times.
The problem:
The system was running flawlessly for 3 months of continuous use. Then, for no apparent reason, the indicators that display measurements from "Chassis 2" (specifically the DAQ) stopped updating.
If the user refreshed the browser, the Remote Front Panel client would reconnect to the RT Web Server and get updated values, but they were always static. Essentially, refreshing the browser took a "snapshot" of the data, but the indicators did not update continuously as before. At the same time, DIO inputs to "Chassis 1" responded appropriately to changes in state.
Refreshing the browser on one laptop would update the values for that laptop only, and the other laptop could be refreshed independently and have different values displayed, but both laptop's indicators were static. During this time, the DMM measured inputs were not changing and the "Chassis 2" DIO inputs did not change state (i.e., we could not perturb the inputs), so we could not determine if those indications were affected.
Also, the error console did not respond to user input until the browser was refreshed and the client reconnected to the target.
We know the RT application is running on the target because there is code that monitors the status of the loops by changing state every loop iteration and displays the status to the user.
Our short-term solution was to reboot the RT controller by powering down both chassis, starting "Chassis 2", then starting "Chassis 1". It's been running for a few days now without incident.
Since the data displayed after refresh was accurate based on comparison to gages in the system, we do not suspect a measurement problem.
Possible culprits:
1. The RT Web Server has malfunctioned in some way (memory problems, synchronization, etc.)
2. The MXI-4 link.
3. Cosmic rays? Sunspots? Nearby radar stations? Neighboring HAM radio operators (with massive amplifiers)?
If anyone has any ideas, they are welcome. We are concerned that this will be an ongoing problem, if only every few months or so.

Could you clarify a bit on how the PXI-6528 was acting while you were seeing these problems? Does this card have values display on the Remote Front Panel, and if so were they still updating properly? I believe you were saying that, but I wanted to be sure because that makes a big difference.
If everything became static, including the DIO card, at the same time, then I'd say see if your browser updated, or something in your network settings was changed without you noticing. Perhaps an update ran and reset some of your firewall settings, or an Internet Explorer update changed something that required a reboot.
If just the outputs of chassis 2 were the problem, and the DIO card values on your remote front panel still worked well, then it is most likely a problem with your MXI-4 cards or your fiber optic cable that cause the change in behavior.
Miles G.
National Instruments
Applications Engineer

How can I close a remote front panel by closing only the browser window?

I control a remote front panel in a browser (from the client PC). If I don't use the 'close' - button in my program to end the remote front panel, but instead of this the 'x' of the browser window (in the right bottom corner), my program won't be close, it continues on the server. Do you know how to end a VI by closing only the browser windows?
Thanks for any help!
wolfe

I found the examples. Thanks.
But I could not find a solution yet. Now I know how to end a VI by clicking on the x of the VIwindow.
My problem is, to end a VI by clicking on the x of the BROWSER window after I loaded and controlled a remote panel VI in a browser (e.g. IE).
If you have any ideas ... I'd be happy.
Thanks for your help.

LabVIEW Remote Front Panels and WebCT or Blackboard Integration

Hi,
Has any one had any experience with getting LabVIEW Remote Front Panels working with WebCT or Blackboard E-learing software?
Generating the Remote Front Panel is easy enough, it's incorporating the Remote Front Panel into WebCT or Blackboard that am interested in?

Hi,
Are you using FieldPoint 6.0.2? We have a Corrective Action Report (#125870) for the remote front panels for the cFP-2220 with LabVIEW 8.6 and FieldPoint 6.0.2. R&D is currently working on a fix, until then, the only known workaround is to using LabVIEW 8.5.1.
Regards,
Jeremy_B
Applications Engineer
National Instruments

Configuring Remote Front Panels on a Real-Time Target,smart camera,but there is no image in the web page.

I do see the web page, but the image itself is not loading.i know a problem is with the installation of the LabVIEW ActiveX plug-in or the IMAQ ActiveX plug-in. The LabVIEW ActiveX plug-in is required for ALL remote front panel viewing, and the IMAQ ActiveX plug-in is needed for VIs that use the Image Display. how can i do ?where can i get the the IMAQ ActiveX plug-in. help me！

Got it working, after much experimentation. Seems to require installing exactly the right combination of items on the RT target, as some items (web services? web configuration? the "application web server"?) apparently run a separate web server - or instance of the web server - on port 80, which prevents remote front panels from being served on that port.

Why does refreshing my web browser page increment the number of users connected to my Remote Front Panel?

Hi,
I'm using LabVIEW 2010 and a cRIO-9118 to broadcast my RT Front Panel on the web with a Web Server.
I successfully configured the web server to be able to control my Front Panel remotely. However, I have an issue with "Refreshing" the browser.
When I press "Enter" to search the adress of the web server, the number of users connected seems to increment by one and then tells me that "Too many users are connected to the front panel". Once this has been done, the only way to "unlock" the web server is to reboot the cRIO.
Is there any solution to avoid this behavior?
My current web browser is Internet Explorer 8.
Thank you
Mathieu Veillette, Ing Jr.
Solved!
Go to Solution.

Hi Mathieu,
Unfortunately, there currently isn't a very good solution for the problem you are facing. It seems like this is a known issue that R&D is working on. It so happens that in addition to simply refreshing, this issue also occurs if you try to access the Remote Front Panel using a second tab in a tabbed browser. One "fix" would be to invest in a higher count Remote Front Panel license. If that's not feasible, then the current recommendation would be to avoid connecting to the Remote Front Panel from a second tab or refreshing the view in your browser. Once you exceed the number of connections to the Remote Front Panel, you will have to restart the RT controller -- there isn't a way to change this default behavior. You can track any fixes by R&D by keeping note of the CAR (corrective action request) ID for this issue, which is #202702.
Sanjay C.
Embedded Software Product Manager| National Instruments

Remote front panel SSH support?

Does the LabVIEW HTTP server which delivers remote front panel "content" have the option of running in SSH mode? If not, what are my alternatives for securing connections to remote front panel servers?

I am not aware of any options for SSH in LabVIEW. However, there are other ways to keep you remote panels secure. To prevent a user from gaining control of a VI, click the lower left corner of the front panel and select Lock Control from the shortcut menu. This option prevents a viewer from requesting control of the VI on the Web until you unlock it. Similarly, you can regain control of a VI from any Web client.
To configure more Web Server security options, select Tools»Options, select Web Server: Configuration from the top pull-down menu, and enter the Root Directory. After you enter a root directory, Web clients have access only to files in that directory and its subdirectories. All other files on your computer are not accessible on the Web. Select Web Server
: Browser Access to grant or deny viewing and/or controlling access to different IP addresses, so only known clients can view or run your application. Select Web Server: Visible VIs for control over which VIs in your Web Server directory are visible to a client, and to limit the time that a client can maintain control of a VI. Refer to the LabVIEW Help, which you can access by selecting Help»VI, Function, & How-To Help, for more information about configuring the Web Server.
Alternatively, you can program security into the VI itself. For example, you can require a user to log in when the VI first runs, and disable all other aspects of the VI until you verify the login. To do so, place a login field on one page of a tab control, the other controls on subsequent pages, and enable the other pages after the user successfully logs in.
J.R. Allen

Remote front panel

Hi, I'm new to labview. Now i have a program which is running in server mode. The application also build for the remote front panel. So my question is whether the client use the remote front panel to download the require file from the server to client computer under different 2 networks ? Thank you.

My main vi is just displaying data in graph where data are from MODBUS module which using LAN port. The main vi will gain all the data and generate a file (such as Excel file) after clicked a button. This file is generated at the server computer. With this function, i also published the front panel into web which is remote front panel. So now i want to generate the excel file by using another computer (client computer) access through the remote front panel to generate the file and the file is save to the client computer. The two different networks i mean was the server computer and the client computer is not connected under same network. So i want ask that whether remote front panel can do this function or not? If yes, then how to do it? Sorry that let you confuse

Remote front panel in tablet

Hi all
I am trying to establish a remote front panel connection on to a windows 8 32 bit OS on 64 bit atom processor tablet from an exe deployed on myRIO. I had verified the remote front panel connectivity on the development PC (windows 8 64 bit OS on i7 processor), installed LV RT engine 2013 and the 32 bit drivers on the tablet. The problem is that the remote front panel connection gets stuck after some time. I am connecting the target to a B type USB which is connected to an OTG cable and then to tablet microUSB port.
1. I reduced the data rate to some 200 samples per second (displaying 20 values on a graph per 0.1 second), still the problem persists
2. The remote panel works pretty well when connected to development PC and to another PC (windows 8, 64 bit OS with LV RT 2013 installed) via USB, it is just the tablet that is losing the connection after a while (it says remote panel connection refused by specified server)
3. I connected target to a local network, enabled WiFi on the tablet and got remote panel working perfectly. It is just the physical USB connection to the tablet via OTG cable that is creating the problem after sometime
I came to the conclusion that the problem could be with the 32 bit drivers (the display gets stuck only after sometime though), OTG cable (i tried another one too) or that the tablet is running on 32 bit OS. I even installed LV 2013 on the tablet, developed a test exe and tried getting remote front panel, still the same problem persists. Any inputs as to what the problem might be?
Thanks
Arya
Solved!
Go to Solution.

If the WIFI works, I would just use it. Alternately, I would look into a better cable. With cut-rate calbles the first place thay start trying to save money is with the connectors.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Where does the processing take place when using a remote front panel?

Hi,
I am considering upgrading my LabView software from 6i to 6.1 for the new "two click" remote front panel feature. I have already seen a demo of this feature but have just a few questions before I get the upgrade:
My setup consists of several pieces of equipment connected to Labview via GPIB, to aid in the evaluation of a new microchip.
1. I wish to grant control of the setup to anyone with a web browser, Is the remote monitoring feature compatible with both Netscape and IE?
2. The VI which controls the setup is currently located on the PC beside my setup. When I embed a VI in a remote front panel, where does the processing take place, is the local VI still controlling the setup? and
the remote panel just sending and receiving data from the local VI.
Thanks, Troy

> I am considering upgrading my LabView software from 6i to 6.1 for the
> new "two click" remote front panel feature. I have already seen a demo
> of this feature but have just a few questions before I get the
> upgrade:
>
> My setup consists of several pieces of equipment connected to Labview
> via GPIB, to aid in the evaluation of a new microchip.
>
> 1. I wish to grant control of the setup to anyone with a web browser,
> Is the remote monitoring feature compatible with both Netscape and IE?
>
Yes. Provided they are resonably modern versions.
> 2. The VI which controls the setup is currently located on the PC
> beside my setup. When I embed a VI in a remote front panel, where does
> the processing take place, is the local VI still controlling the
>
setup? and the remote panel just sending and receiving data from the
> local VI.
>
The computer which we refer to as the server, the one with the GPIB card
in your case, will execute as it does now. In fact, its window will
even be open. The remote client computer, the one with the web browser
will be running the runtime engine and processing user events, value
change and property/method events from the server. So in reality, both
computers will be sharing the load a bit. This allows for very small
packets to be sent between the computers. It is in fact quite similar
to publishing the data between the computers using datasocket.
One thing to keep in mind. Standard LV includes a license for one
connection. If you want to allow for multiple web browsers to view at
the same time, additional licenses are available. Also, only one user,
remote or server may be in control of the panel at a time. That means
that if you want to be able to operate the panel, changing kn
obs or
flipping switches, the others will become viewers only until you give up
control. Hopefully this isn't a surprise, but I thought you might want
to hear about it now.
Greg McKaskle

Remote front panels

when I use remote front panels in LAbVIew 6.1, The Web Server and the client interact using DataSocket Technology through the ActiveX controls embebed in the web page?

> when I use remote front panels in LAbVIew 6.1, The Web Server and the
> client interact using DataSocket Technology through the ActiveX
> controls embebed in the web page?
No, it is a low-level TCP based protocol that passes the data values and
property values similar to datasocket, but not using datasocket.
Greg McKaskle

Server does not support remote front panels

hello
I'm about to command the front of my labview program remotely. I followed all the steps that I found on the NI website. when I do the test on my Intenet Explorer browser it gives me the following mesage: "Server does not support remote front panels".
I await your propostion and solutions. Sincerely

Hi,
This KB might help.
Christian

Remote front panel: loading VI into controller memory

Similar Messages

Maybe you are looking for