Remote Panel bandwidth

[gnm]

I am attempting to use the remote panel to connect over the Internet - the server VI is fairly intensive in terms of the controls/indicators etc., so that there is a bit of a draw on the available network bandwidth when I access it.

Is there a way to set the refresh or update rate for the the remote panel (either the client or the server), so that I query the remote panel at a slower rate (or update on demand)?

Or, would using data sockets on selected controls/indicators be a more efficient way of minimizing the bandwidth (this means I have to create a duplicate app on the client PC that subscribes to the selected controls, I imagine).

Thanks.

[Danger]

If you don't need to actually control the panel (ie, fiddle with the knobs and change settings via the web), there are a couple of options. One is to simply select Snapshot Mode under viewing options on the web publishing tool. Then you can just hit refresh whenever you want to update the panel.

Another option is to use snapshot mode with a tweak to the URL such that you set an automatic refresh rate on the browser. Here's a the KB for it ... 2G3IQJVS.

[gnm]

Actually, I need to change control values occasionally, so I need the full functionality. I'll look at the knowledgebase article you referred to as well, though. Thanks.

[Greg_McKaskle2]

> Actually, I need to change control values occasionally, so I need the
> full functionality. I'll look at the knowledgebase article you
> referred to as well, though. Thanks.

Keep in mind that writing properties and updating indicators and
controls affects the traffic rate. It may pay off to see how often
these things happen in your VI by using the profiler tool. The details
button in the profiler will show how much time is spent doing displays
and drawing.

Greg McKaskle

[mikeporter]

Another solution is to not try to transfer the screen image back and forth but just the data that's significant. I have done this in the past and it works well. A major advantage to this approach is that you get to control what data gets passed and how often it's transfered. For example, you could only send data that changes.

To implement this approach you will need to define a communications protocol. It could be built on the LV TCP/IP routines, Telnet, datasockets, remote VI server calls or any of several methods. It all depends on what features you need--and how much time you want to take.

If you have specific questions about this sort of technique I would be glad to answer them.

Mike...

[gnm]

Based on my (limited) knowledge, I'm thinking of doing it using datasockets - can anyone point me to any decent examples on implementing datasockets for remote control/data acquisition - or if an alternative method would be more efficient?

Basically I have a fairly complex VI at the actual site, but I only need to control a few parameters remotely - start/stop, enter some numeric values like sampling frequency etc., and receive some periodic data. The problem is that I will most likely only have a phone-line connection to the internet.

[mikeporter]

For datasockets there are several good examples that ship with LV or are available through NI's website.

Mike...

[gnm]

Thanks, Mike - I've been going through the website and the LV examples. I think I have a handle on data sockets now. I have a couple of questions, though:

How do I set the refresh rate of the updates, if I am attaching front panel controls directly to an URL (using the pop-up menu), as opposed to using a ds VI? Right now, it seems to be refreshing data at ~ 10 secs. I need to change that to a longer period.

Also, I seem to have a problem with the DS VI's that ship with Labview. I have LV 6.1, Prof. Dev. version, but on my palette under datasocket, I only have 'Read', 'Write' and 'Select URL' vi's. The documentation on the website indicates that I should have a whole bunch of 'Read' VI's specific to all the data types (the Read VI I
have is a variant type).

Any ideas?

Thanks,

Gerald

[mikeporter]

Ni has been reworking the DS vis and have come up with a smaller number that do everything. The 10 sec update rate is probibly coming from the default read timeout which just happens to be 10 seconds (actually 10000 msec). Checkout the online help for the read VI.

Do you know how to deal with variants?

Mike...

[gnm]

Thanks, Mike. I eventually figured it out - I did end up using the variant 'all-in-one' VI's to do what I have to do - seems to be working OK. Only thing is, now I have some timing issues, where, if the sync rate is not correct, I end up getting redundant/duplicate data from the remote. (i.e., the data sampling rate of the remote machine has to be less than the timeout value so that the client's DS vi doesn't time out and use the old value instead).

Problem with setting the timeout to a large value is that then the while loop I have slows down to a crawl (it's like putting a wait timer inside) - since my data update rate is on the order of minutes! Any ideas on a better way of sync'ing the data? (I can't compare values
because sometimes the remote data values can be equal to each other).