I have a complicated main VI that I would like to have accessed by remote users. I have built this as an executable, and the web server is running. If I test the program on the same computer that is running it, using localhost as the address, all works as it should. When I go to another computer to connect remotely, my connection is flaky at best. The remote connection is often terminated after about 15 seconds with a message in the browser saying "The conection with the server has been broken". This happens most when the program is idle, waiting for user input. If the program is doing things and the panel has lots of things changing, the connection stays on. The other problem is the remote users can not get control of the VI. The mouse click requesting control works, and the local running program knows that the control has been passed to the remote computer, but no clicks by the remote user do anything. The program contains lots of property nodes to manipulate the look of the front panel, and I have used the workaround found in the KnowledgeBase to refresh the property nodes when a remote connection is made, but these problems exist whether I do that or not. Any clues as to why the LabVIEW 8.5 web server, both in the development environment and run-time, would do this?
Have you run across this KnowledgeBase article? It seems like you may need some timing in your VI. What is the program doing? Are you communicating data between the two computers or just monitoring actions on one computer from the other?
I have looked into this and it seems like you've got a lot going on in your program with lots of events and front panel updates. The behavior you are seeing may be caused simply by the complexity of your VI. I found this article on our Developer Zone and it explains a little about using remote front panels. Under Minimizing the Amount of Advanced Communication, it discusses the potential for buffer overflow with a large number of events and property nodes. Take a look at the article and see if this seems like it would applicable to your VI and why the connection with the server may be breaking.
I have spent some time with the Profiler and the Remote Panel Connection Manager and I see that I have had a misconception of how the data is sent to remote panels. I have a loop that behaves as a sort of demon. I send a command to a serial device and read its response into a buffer (a queue) continuously. In other parts of the program I get values from the queue when I need them. I want fresh values, so this demon was set to run fast, being throttled by the response time of the serial device. None of this makes it to the front panel of any visible VI in the application ever. The speed of this loop has a dramatic effect on the Web connection behavior, as slowing down the demon results in pretty stable connections where they were very unreliable before. This shows that my idea that only front panel information was sent to the remote panel was wrong. I am close to good enough now, but I still see problems as control is passed back and forth between the local and remote panels. At times that I can't pin down yet, the local application (running as an executable) will crash when control is returned to it by the remote panel. This still makes me wonder about what info is sent to the remote panel though, since the article you referred me to suggests that slowing down panel updates to graphs would be the right thing to do. I have a table and two graphs that are updated about once a second, and that made me feel that I was more than adequately slow with information. One graph has two curves on it, with the last point being moved around by the new data. The other graph has three curves on it, and it is like a chart recorder: each new point adds to the length of the curve. The table has four cells that are updated with the new data. The only other thing changing on the panel is a string indicator displaying the time of day with one second resolution. When the program is idle, only that clock display is updated, yet the Remote Panel Connection Manager showed me around 25 kbytes/second of traffic. Seems pretty high to me. I have rambled a bit here, but we are getting closer to solving my problem.
It doesn't sound like there's too much going on between your remote front panels and the application. I'm glad slowing the demon loop helped out.
I don't know of any issues with LabVIEW 8.5 remote front panels and crashing when the host regains control, but I'll continue to look and give you an update tomorrow.