LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Latency Issues and the Web Publishing Tool

The VI that I am making will be used to control actual devices remotely. We don't want the full interface VI to be client-side because it will have some internal time-sensitive actions to take--the user is mostly just hitting Start buttons and pre-setting the timers--so we're using the Web Publishing Tool (WPT), which as per my understanding does all the behind-the-scenes actions on the server computer. (Right?)

Since we're controlling actual devices, we're interested in preventing rubberbanding, where (for example) the user tries to increase the voltage, sees it go up, sees it drop back down to an intermediate value as the server updates, and has to try again. My question is: When using the WPT, what is each computer actually doing? Is the client's display being updated locally while commands are being sent, or does the WPT require that the server report back with a picture of the front panel to update the client?
0 Kudos
Message 1 of 4
(2,787 Views)
Bump.
0 Kudos
Message 2 of 4
(2,759 Views)
DJDDA,

When you use the web-publishing tool to create a page with an embedded front panel, the application will actually be running on your host computer.  I believe that LabVIEW sets up another VI on your client computer which has an identical front panel and which communicates with the host application.  So any information updated on the client application will need to come from the host computer.  Forthis reason, it's best to minimize the amount of information displayed on your front panel unless you have a high-bandwidth connection.

Have a look at the following article for some ways to improve the performance of remote front panels.  It might be a bit dated, but the same principles should apply:
Developing Remote Front Panel LabVIEW Applications

Message 3 of 4
(2,747 Views)
Ugh... well, now I know. Thanks.
0 Kudos
Message 4 of 4
(2,731 Views)