Web Server remote panel control/indicators 'synchronization'

[M37Eddie]

I've made my first attempt at using the Web Server publishing tool and it sorta 'almost' works. I am able to successfully access and open my application.exe running on the 'local' machine and gain control to the assorted front panel controls. (so the application.htm portion is correct)

However some of the controls on the remote panel are 'out of sync' (?) with the actual app.exe on the local machine. Some of the booleans are inverted and don't appear to be programatically reset back to, let's say, a FALSE state as they should be when certain key click events happen. And some pages of a TAB control that are supposed to be ENABLED are actually DISABLED and 'grayed-out' incorrectly. It's almost like the remote panel can't 'keep up' with the pace.

The 'app.exe' on the local machine runs perfect with none of these exhibited problems seen on the 'remote' machine. Thus I'm not quite sure where I'd even begin to troubleshoot in the actual VI itself. Nothing's broken. (Both the VI and the EXE run perfect as expected on the local machine.) What could cause front panel objects to be out of sync (?) on a remote panel? FYI the objects that appear incorrectly on the remote panel are consistently incorrect. So it's quite repeatable. Any thoughts about what's going on here? Anything I've overlooked or done wrong?
Thanks.

[Ankita A.]

Hi,

I remember there was a delay when using remote front panel on a VI with event strucure in LabVIEW 7.0 Express. This was fixed in LabVIEW 7.1. Could you please let me know what version of labVIEW you are using?

Regards,
Ankita A.

[M37Eddie]

I'm using LV 7.1. The event structure and overall program works correctly on the remote panel, no problems. However it's the appearance of the buttons that is essentially 'out of sync'. Very frustrating.

[Ankita A.]

Hi,

Please check out the following link that explains how to reduce the amount of advanced commmunication when using remote panels, so as to avoid any delay.
http://zone.ni.com/devzone/conceptd.nsf/webmain/e789515b9976253786256b1f007e039b?OpenDocument#3

Regards,
Ankita

[Mache]

Hello,

Unfortunately, I am having a similar problem. The Web Server is Published and the remote panel connection works well. I have tried it on several Computers, on intranet as well as over the internet.

I am using XY chart in my app. which updates every 500ms or so. It is actually a real time chart and uses current system time on X-axis. Every thing else works ok, except this real time chart. The remote panel connection displays the chart but the time display on the chart differs by almost 10 minutes or so. Also I have the X Axis Scroll Bar on. Invariably when you load the remote panel in the browser. The scroll bar comes is dead (disabled?).

I have observed also that if I request Control of the vi, and then refresh the web page a couple of times. The XY chart on the remote panel falls in synch with the server, however it looses all its buffer and starts as if the history is reset to zero. Once that happens and the buffer builds up beyond the screen, the scroll bar comes alive too.

I need to solve this problem, Any help is appreciated.

If any one wants to see the app. It is currently available for viewing over the net. Email me your contact details and I will send you the link to see it.

Thanks again in Advance.

Mache

[Ankita A.]

Hello Mache,

I would suggest a couple of things in that situation.

If you are continuously reading the data from the some hardware, then try to slow down the reading process by adding a small delay. It is possible that the web server is taking a lot of processor time and the real-time data acquisition is trying to get a big chunk of that data. The bandwidth issue would be the next, which you have already considered (refer to the link I posted in my previous post).

The second option would be trying to communicate between two computers by using a cross over cable thus making sure that there is no issue with the network switch or router on your existing network.

The third thing I would suggest is taking a very simple VI that just gets some data from a file and displays it on the screen in a continuous mode (say a loop). See if that is working, if it is then change it to read the data from the hardware. Also, if there is a loop make sure that the hardware configuration, start and stop are outside the loop.

If none of the above things work, please provide some feedback on the above situation and your program with the link to the remote panel.

I hope it helps,
Ankita

[Mache]

Hi Ankita,

First, Than you for taking time and attempting to answer my query.

I am reading data at the rate of about 500ms. I can slow this down further, but then the application is worthless. It must monitor at a brisk rate. As far as processor usage goes, I don't think Web server or the application is taking a sizable chunk. The app is built with this in mind so when I am connecting over the Ethernet The next data acquisition doesn't take place for a second or two till the connection is established.

As part of the same application I have other forms of data on XY graph. These are transmitted fine and in almost real time. This is also acquired and processed data.

Another thing I have discovered since my last post is this - My app. is running in EST. I had some one log into the app over the net from CST. Well the Whole Strip chart time was off by One hour, the time difference + the delay I mentioned above. It seems the Strip chart that is run in the browser is pulling the time from the local Computer...!!

Here is my take on what is happening - See if you can shed some light on this.
My XY chart has 1024 points of Buffer History which roughly translates into 8.5 minutes of XY chart history. When I connect to this remotely, The server tries to send this data FIFO to the Client, point by point on every update of the XY Chart. But on every update the FIFO adds one point!! So the Client is seeing one end of FIFO and Server is displaying the other end, and the twain shall never meet. What ideally should happen is When the Web Connection is invoked, the server should take precedence transfer all the buffer to the Client and then resume the data Acquisition. If it takes a minute to start the remote client no big deal. Then since the buffer is already transferred It just has to send the most recent point. Seems like a bug in Server Implementation and also a bug in client implementation as the time on the chart differs in different time zones

I have checked the Network Traffic rate, It is appox 20Kbytes/sec which is roughly 300kbps. Technically this should be handled easily over a broadband connection, not withstanding overheads.

So Now I am thinking of ways to solve this Programmatically or generate XY chart programmatically and show it on XY graph and keep an array for Buffer memory. Bummer!!
Any spark of genius is appreciated.

Ah, I will email you the link and you can take a look at the panel.

Thanks Again

Mache

[Ankita A.]

Hi Mache,

LabVIEW stores time-zone-independent number of seconds that have elapsed since 12:00 a.m., January 1, 1904, Universal time. When displaying the time it takes into account the time zone of your computer and displays the time accordingly. So the one hour delay you are seeing is expected.

As for the delay in receiving the data, please post the smallest VI that exhibits the behavior and I will try to reproduce the behavior.

Regards,
Ankita

[Mache]

Ankita,

Thanks again for the information. I understand the UTC time and time zoning, which is a little difficult to rationalize to a customer who browses in to monitor his equipment and sees time on his equipment differ from what they are expecting. I will try and rationalize that part. The delay is a different matter.

Here is a small VI which will exhibit this problem. Make sure you let the VI run for 10 minutes or so before connecting to it via the Browser. When you Invoke the "WebPublishing Tool" under the "tools" menu make sure you choose Viewing Options = Embedded.

Good Luck

Mache

[Ankita]

Hi Mache,

Sorry for taking a while to reply. I could reproduce the behavior you reported and I do not have an explanation for it. I have brought the issue to the notice of LabVIEW R&D for further investigation.

Ankita