Remote front panel with labview 8.6 executable

I am trying to create a remote front panel of my application, built in an executable using Labview 8.6. I want to run that application on a target machine (not the one used for developing the project) and view and control the front panel of the VI from a web browser on another computer.
I have followed these steps: 
How can I use remote front panels with Labview Executables?
But when I finally open the web browser and navigate to the URL I obtain that the page cannot be found.
I have my Labview project created and I have built a web page using Web publishing tool. I have saved it in my Labview 8.6/www directory and added it to the project. I have built my executable including HTML file and copied all the obtained folders to the target PC.
Then, I have modified the .ini file like in the step 7, but when I arrive to the step 8 I don't know what to do. Which  niwebserver.conf should I modify? The one localized at Labview 8.6 directory of the target machine? Or the one that is created in the directory where I have copied the executable when I run the executable?
In the DocumentRoot tag  I have to replace the default Labview/www with the location of my HTML file. Should I use quotation marks or no?
Have you got any ideas of what is happening?
Thanks!

Ok, but when I create the executable, in the folder where the application.exe and .ini are there isn't a file called niwebserver.conf. When I run the application a file with this name appear in the directory (the one I include), but it hasn't the section Directives that apply to the default server as in the manual.
What I have done is to copy the niwebserver.conf file ubicated in the Labview 8.6 of the target machine in the same directory of the executable but it doesn´t work...
niwebserver.conf
ServerRoot "."
ErrorLog "./logs/error.log"
LogLevel 3
ServerName default
DocumentRoot "./../../www"
Listen 80
ThreadLimit 10
TypesConfig mime.types
DirectoryIndex index.html
LoadModulePath "./modules" "./LVModules" "./.."
LoadModule LVAuth lvauthmodule
LoadModule LVSnapshot lvsnapshotmodule
LoadModule LVRFP lvrfpmodule
LoadModule LvExec ws_runtime
LoadModule dir libdirModule
LoadModule copy libcopyModule
AddHandler LVAuthHandler
AddHandler LVSnapshotHandler .snap
AddHandler LVRFPHandler
AddHandler LvExec
AddHandler dirHandler
AddHandler copyHandler
CustomLog "./logs/access.log" "%h %l %u %t \"%r\" %>s %b"
KeepAlive on
KeepAliveTimeout 60
Timeout 60

Similar Messages

  • Programmatically Open a Remote Front Panel with Panel Open Method

    Hi,
    I am trying to open the front panel of the VI on my cRIO-9024 through a remote computer. Currently, I am able to run the VI with no problems with the RUN VI method; however, when I try to open the front panel, I receive "Error 1043 - This property or method is not supported in this version of LabVIEW" or the Front Panel is simply not visible. My cRIO is configured to allow TCP/IP protocol, The VI is visible, and I have made my project into a source distribution on my cRIO.
    Any help or suggestions regarding this problem would be great. I am very new to LabVIEW.
    I have attached a screenshot of my block diagram and project.
    Thanks,
    Jake 
    Attachments:
    Block_Diagram.PNG ‏12 KB

    Project Img
    Attachments:
    MyProject.png ‏15 KB
    MyProject.png ‏15 KB

  • Remote front panel with viewing mode in monitor jams if two browser connects

    I made a exe with the vi attached, with the web publishing viewing mode set to monitor every 1s.
    I copy all the executables and generated files to a target computer. The target computer is 4 CPU 2Ghz, 1Gb RAM, Windows 2000.
    If I open a client web browser connection to the remote panel, everything is fine, I can see updates every 1s or so.
    But if I open two client web browser connections, the display in the two web browser grinds to a halt, and the exe in the server computer slows down from 1s update to 6s update.
    If shut off one client web browser, the other client browser and the exe in server go back to normal speed.    
    So what is the problem? How do I solve this problem? Is this problem solvable?  
    Attachments:
    monitor4.vi ‏85 KB

    Bump. 

  • ASK remote front panel

    hai bro i try to remote panels with labview 8.0 professional with this information :
    http://zone.ni.com/devzone/cda/tut/p/id/4791
    http://zone.ni.com/devzone/cda/tut/p/id/3277
    and it's done, for example i give it name test then i start the web server it's works well.
    but when i try to connect again with remote panel connection manager and open the project (test)
    the remote panel connection manager says that they can find it certainly i've save and open it with the same name and folder where i save the project.
    can youm tell me why  i can't do that?
    tanx before, sorry for bad english 

    What do you do differently the second time from the first? Are you opening it up differently? Are you using an executable? It doesn't look like it from your description but if you are there is a link below that may help. do you have a firewall up or a proxy server? The second link may help if the problems are being caused by one of these.
    KnowledgeBase 3U5H27MY: How Can I Use Remote Front Panels With LabVIEW 8.x Executables?
    KnowledgeBase 2ZAC2IEG: Remote Panels Through a Firewall or Proxy Server
    Vince M
    Applications Engineer

  • How can i access remote front panel in RT with LabVIEW run time engine in client PC

    Hi to all,
    I have developed the RT application with cRIO 9075 integrated chassis. And i have access its remote front panel in client PC. Now i want to access the remote panel in the client PC without having LabVIEW runtime engine. If i connect the remote panel with that client, it shows only the vi border. i doesn't downloads the  front panel.
    How Can i access its remote front panel without LabVIEW runtime engine in the client PC?

    You cannot view a remote front panel without the LabVIEW runtime - the LabVIEW runtime is what makes the remote front panel possible.  What you will want to do instead is likely create a Web Service that you can access from a remote PC without requiring the LabVIEW runtime.  However, this will require you to develop a web-based HTML or similar UI to interact with the VIs running on your system - NI hasn't yet created a way to export a LabVIEW front panel as an HTML'ish page.  
    -Danny

  • Multiple remote front panels?

    I have two separate applications running with remote front panels from this KB:
    How can I use Remote Front Panels with Executables?
    I can not get the two to run at the same time.  I was then shown this:
    How can I run Two or more Executable with remote front panels?
    This seems to be a little old (Version 8).  I am running 2012.
    Has anyone gotten this to work?  How do you set up the web server to listen on more than 1 port?  How do you then direct that port to a particular app?

    Thank you for the solution Todd. I was having the exact same problem.
    LabVIEW 2013 SP1
    Windows 7 64bit
    Windows Server 2012 64 bit
    Windows 8.1 32 bit

  • 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

  • LabVIEW Real-Time and Remote Front Panel MemoryManager.cpp line 437 error

    Hi all,
    I'm using a smartcamera (NI 1742) with LabVIEW Real-Time 8.6.
    When I look at the Front Panel with the web browser and I close the browser or I Stop the executable, I always get this error: MemoryManager.cpp line 437. I've checked if someone else had this error, but I guess I'm the only person who got this error. I saw someone who had the MemoryManager.cpp line 406, but mine isn't on this line.
    The application works well, but when I got the error, I need to reboot the smartcam to get it works. In my application, I use the Modbus library and I read/write binary file in the hard disk of the smartcam....
    Anyone knows the solution?
    Thank you very much
    Stephanie

    Hi again,
    Still didn't find the problem on my side. Here's a picture of my code. If I put the code surrended in red at place (1), I don't get the error, but if I put the code at place (2), I get the error. Why oh why....?
    I get the error when I close the browser or click Back button of the browser or Stop the application with the red dot or stop the application with the Quit button on my front panel.
    This morning I found a post on this forum about getting an error using Property node and Remote panel (http://forums.ni.com/ni/board/message?board.id=170&message.id=252705). I did what they suggest: wire the property output to an indicator and it works (disable "Enable automatic error handling dialod" didn't work... I don't know why)... until I put extra code in my VI. 
    I really need help please!
    Thank you
    Stephanie
    Attachments:
    MemoryManager line 437 error.JPG ‏228 KB

  • LabVIEW Remote Front Panels and WebCT or Blackboard Integratio​n

    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

  • 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!

  • Able to interact with a cRIO remote front panel from one computer but not another

    I have a cRIO application that publishes a remote front panel for monitoring and control of the application. From one PC (Win7 & firefox) I can see, interact and control the cRIO through the published remote front panel. From a second PC, also Win7, I can see and monitor the cRIO's state, but the remote panel that is opened does not allow for any interaction and this is true whether I'm using IE, FF or Chrome as the browser. When either PC is connected to the cRIO, it is via a dedicated Ethernet link and only the cRIO and the one PC are on that network. For this two-device private network, the PC is always at address 192.168.1.1 while the cRIO always uses 192.168.84.199 (port 8000).
    The firewall rules on both PCs are setup to allow all incoming and outgoing programs/ports/protocols to be used between these two IP addresses.
    Both PC's have up-to-date LabVIEW development systems installed on them (which more or less guarantees they have the minimum require LV runtime needed to see and use a remote front panel).
    What might be different on the PC that view but cannot interact with the remote panel?
    Solved!
    Go to Solution.

    Sam_Sharp wrote:
    Right click on the second one and select "take control of this VI".
    As far as I am aware - only one viewer of the remote front panel can control the panel at any time - the rest can only view.
    As I tried to say in my original post, there was only one host physically connected to the private network at any given time (by virtue of the fact that the one Ethernet cable connection to the private network was being moved back & forth between the two hosts) so there was no way both hosts could be trying to control the cRIO at the same time. I even went so far at one point of restarting the cRIO while it was connected to the problem host to see if would render it functional, but it did not.
    But I did not know that it was possible to do what you suggested, much less that there was a right-click context menu associated with a remote panel, so I tried it and it worked!    Thank you!

  • Problems with Remote Front Panel

    Hi, I've seen "How to create a LabVIEW Remote Front Panel" video of Grant H.
    I've followed the steps to create a remote front panel but doesn't work. When I open the URL in Explorer, show the title, header and footer but don't show the front panel, only a image that say: "Downloading front panel 0.00% of 0 Bytes" and don't work.
    My Remote Front Server in turned on and I'm using LabVIEW 2010 in Windows 7.

    I am having the same issue.
    Is there anything I can look up to find possible solutions?
    BTW, I run the same application in a different machine and it works just fine. I just can't seem to find where I should be looking...

  • 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

  • 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

  • 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

Maybe you are looking for