LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error "Remote panel server failed to send requested VI"

We are using the G-Web Server to embed VITs into an html webpage. We are able to view the VITs perfectly in development code, but once we build the VITs into libraries, we get the error:

"Remote panel server failed to send requested VI"

We believe that our server is setup correctly, and we have checked to make sure that the VI is in memory on the server machine. If anyone has any ideas, we would be very grateful.

Thank you in advance,
Chris Bauer
0 Kudos
Message 1 of 7
(4,276 Views)
I thought I would let you know we are using a combination of G Web Server for CGI scripting, and LV Remote Panel Server to serve up the VIT's (VI clones). Here's some more detail about what's going on...

The order of events:

1) Server Application runs on port 80. This is both G web server (set to share port with LabVIEW), and the LabVIEW built-in web server.

TCP Access is enabled for all connections for both servers, and VI access is enabled for all VI's for the LV Web server. We have ensured this is also true for the built application using the appropriate settings in the application.ini file and the [application] section.

2) Client requests a CGI page. G web server catches the CGI request, runs a small CGI VI. The CGI VI (a) opens and runs a VIT (vi clone), and (b) creates and returns to the client a small HTML document which embeds the cloned VI's front panel. This method follows the structure of the NI example in "Creating Simultaneous Instances Remote Panels LabVIEW Applications".

The VI clone is running properly at the CGI request. We've added code to open the clone's panel on the server at the time of request to ensure this.

3) We *think* we understand the licensing issues surrounding the Remote Panel server. Further, we enable logging on the server (WebServer.LogEnabled=True), and we can see the license granted to client connection at time of request (timestamps/user/ip removed for clarity):

localhost - - FPP ConnAllowed - - Total licenses checked out = 1 localhost - - FPP VIReqAllowed - "Spartan Home 1.vi"
localhost - - FPP ConnClosed - -
0 Kudos
Message 2 of 7
(4,272 Views)
Hi cbauer,

The Creating Simultaneous Instances Remote Panels LabVIEW Applications tutorial that you are following, is correct in stating that the VIT approach is possible when publishing multiple Remote Panels simultaneously. One thing that's not too clear is that the clone VI has to be saved to disk before being able to be embedded to the HTML page. However, when trying to do this on a Runtime system (executable) problems occur when trying to save the clone to disk. This is because the "Save Instrument" method not only saves but only tries to compile the code before saving (a clone created from a VIT will always have unsaved changes). Only the Development System can compile VIs, so the executable will return an error 1043 when trying to save the clone VI.

Well, let's call the above limitation a challenge and look for a new approach. Instead of using a VIT as a "master" for the clones, use a normal VI instead. The trick is now to use the standard File I/O functions to make a unique copy of the VI and use that as a clone instead. The only downside is that you will have to manually create a unique name for the copy - something the VIT method automatically took care of. Well, the best thing about the copy method is that you can use it from an executable since no compiling is ever required.

One thing that is important though is to save all subVIs and VI.LIB VIs inside a folder or DLL so the VI is not dependable of the executable. Also, the copy VI has to be placed next to the original VI, so they have the exact same relative paths to all subVIs.

I have created a small example that you can play with. Each time Launcher.vi or Launcher.exe is run, they automatically creates a copy of "a.vi" and gives the copy a unique name ("a1.vi", "a2.vi", "a3.vi", etc.). Then it launches the copy and then stops. Therefore calling Launcher.vi or Launcher.exe will create multiple instances of "the same VI" and let then run simultaneously.

Please give my example a try and let me know if you have any questions, thanks.

Have fun!
- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
0 Kudos
Message 3 of 7
(4,253 Views)
Hello,

I'd like to update this thread with an important limitation.  Philip's method will work as long as your main VI uses only regular subVIs, not *.vit subVIs.  Template subVIs, which may be used as instance-specific globals, will not be instantiated correctly using this method and end up behaving just like regular subVIs.

In my particular application, this means it is still impossible to use remote panels.  I was hoping LV8 would fix this limitation, but no joy unfortunately.  The core of the problem seems to be that Remote Panels insists on using saved VIs (not VIs in memory as created by templates).

Refer to http://forums.ni.com/ni/board/message?board.id=170&message.id=110471&requireLogin=False for the original post on this problem.

-Dave

0 Kudos
Message 4 of 7
(4,091 Views)
I follow what the examples that has been presented here are doing and that seems fine as long as you don't have to distribute it without giving out code.
 
I have an application where I insert VIT clones into subpanels and it works great as a stand-alone application that I can distribute. The template clones in the subpanels all operate independantly just like I was running 12 instances of an executable and the subpanels contain the clones and looks nice and orderly.
 
But now I need to publish it to the web and distribute it and have found out recently that web publishing does not support templates.
 
Can anyone suggest a solution? The template is where the real meat and potatoes of the code resides and is not easy at all to duplicate it 12 times in a single high-level vi. For an example of what the template looks and feels like go to http://avcom.dnsalias.com/avcom.html There are several spectrum analyzers online, the best one is the RSA-1100
 
Thanks for any suggestions,
David
0 Kudos
Message 5 of 7
(3,717 Views)
Hi David,
 
I understand that you are working with one of my colleagues at NI on this issue.  We are both working on finding a solution for you and will be in touch both here on the forum and via e-mail.
 
Thanks,
David_B
Applications Engineer
National Instruments
0 Kudos
Message 6 of 7
(3,697 Views)
This is actually functionality that we hope to include in the future, and has been reported to R&D.
 
Currently a work-around, would be to create a separate VI for each of the subpanels (rather than using VI templates).
 
Let us know if this works for you,
David_B
Applications Engineer
National Instruments
0 Kudos
Message 7 of 7
(3,694 Views)