Remote panel losing connection to the VI?

[H View Labs]

I tried to use the following example (slightly modified - see attached) as a skeleton for a future multi-user application.

http://sine.ni.com/apps/we/niepd_web_display.DISPLAY_EPD4?p_guid=B45EACE3E24556A4E034080020E74861&p_node=DZ52086&p_submitted=N&p_rank=&p_answer=&p_source=External

The problem I discovered is that on loading the generated page with a remote front panel of an instance of the common VI template (I request control right away in the HTML code) the panel display is sometimes OK - displays a numeric indicator and a graph updated, but sometimes (50% probability?) the VI is looking "running" (the Run button is black) but no update to the indicators is happening. This is "fixed" by reloading the page. Sometimes it takes several reloads to obtain a "really" running panel. I know for sure that the VI itself is running on the server, because the loop count indicator increases "behind the sceene" and when the panel finally comes "alive" it is in some number rather far from zero (proportionally to the time it has taken to "revive" the panel, of course)

I run the LV server on a Linux machine, 7.1.1 (so the HTML made for 6.1 in the example had to be updated). The effect is observed both on the same machine in Netscape and Firefox and across the network from an XP/IE machine. I don't think advising the user to keep reloading the page until he sees a "live" panel is good fix, Any ideas?

By the way, the example has been updated for working with 7.1.1. and improved to assign "unused" numbers to the instances if available, instead of ever increasing them. Anyways, Feel free to us it for your applications if you want. There is a slightly modified readme file included, so you can have everything needed to try right away.

[Ben]

Is it OK if you toss the graph?

If so try a smaller graph.

I suggest you report this to NI support.

This sounds similar to an issue that I saw.

In my case there was no fix and we had to go a different route to serve the FP.

Please keep us updated on your findings!

Ben

Message Edited by Ben on 06-16-2005 01:32 PM

[H View Labs]

Just tried to lose the graph whatsoever. Still on the same Linux machine it took several reloads to revive just the loop counter! I reported it to NI yesterday. They have not replied yet wit anything, even a confirmation. Hopefully, somebody is working on this. Any body seen this with other than 7.1.1 LV versions (I just tried it with 7.1.1. the customer has on his machine)?

[H View Labs]

Also interesting: reloading the page can kill the normally displaying panel! Well, reloading again can revive it again after that.

[H View Labs]

Here is what I found in the last couple of days:

I already tried the code served from a Windows machine as well. The issue persists. I also figured that the indicators update rate AT THE TIME WHEN THE PANEL IS LOADED INTO A BROWSER has the critical effect on the probability of the remote panel in the browser starting correctly (with indicators updating) or not. The larger the loop update rate the higher the probability of the panel to load disconnected from the VI. I just increased the default poll interval to 300 ms (from 100 ms I had before) and it significantly increased the chances to see a "live" panel upon loading. Interesting, but once the panel is loaded and running OK, I can decrease the polling interval even to 1 ms - it will be working! However, if I hit the Reload/Refresh button in the browser while having this high update rate, the panel will be loaded "dead" (disconnected) with almost 100% probability. Moreover, then there will be no way to get it back in a running (updating indicators) condition - because the VI in the background is updating the indicators so fast.

Naturally, I observed different probabilities of a "dead" panel loaded on the same machine versus a machine across the network from the server even with the same update interval. So, again, it seems like it's all about the ratio between how long it takes to load the remote panel into the browser and the interval between indicator updates the VI has at the time when it is being loaded into the webpage.

So, when you try my example, if everything looks fine, try to decrease the default value of the poll interval in the handler.vit. I am sure that, say, if you have it at 10 ms, you will get a "dead" panel on load with almost a 100% chance even on a fast machine.

The complete "fix" is to not start updating indicators in the VI right away but rather have the user to push some button on the panel to start the polling (this will guarantee polling won't start before the panel is loaded). This is just a work around, not a real solution though - why do I have to make a user to do this extra step? They already have to click on the panel to get rid of the "Control granted" yelow box. Now I have to ask them to click on some "Start Polling" button in addition. They won't like it. The want the page to load with indicators being updated right away.

[H View Labs]

I have figured it out: the NI example code, and, hence, my code based on it produced malformed HTML! I don't do HTML very often, so initially I trusted the NI code on this. I just replaced the references to 6.1 LV embedded object with ones for 7.1. As you already know, that didn't work well. So, I digged deeper and took a look at the generated HTML last week. I just compared it with the bare minimum generated by Web publishing wizard and discovered a lot of unnecessary and duplicate code in the pages generated by the example (and, again, the early version of my code too). So, I cleaned up and now it looks like it's working fine. Apparently, browsers stumbled on bad HTML and that caused losing connection between the remote panel and the VI due to some timing issues during the page loading process.

[H View Labs]

The issue reappeared for a larger size VI. Apparently, the indicators that are updated during the loading of the panel into a browser tend to get disconnected from the VI. The probability of this happening increases with the increase of the complexity of a VI (loading time?) and as reported before  with the increase of the indicator's update rate.