LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

web server connection broken


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?
BJ
0 Kudos
Message 1 of 12
(3,927 Views)

Hi BJ,

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?

Donovan
0 Kudos
Message 2 of 12
(3,903 Views)
Hi Donovan:
I had not read that particular KB article, and I do have plenty of loops running.  The second (remote) computer is just for monitoring progress on the local computer as it takes measurements over time, but with the opportunity to take control to modify the measurement procedures if things are not quite right.  I will have to see where the loops might not have delays in them.  The basic structure is a queued event loop feeding an action loop.  There are a couple of other loops as well, feeding data from an instrument into a buffer so recent readings are always available, and looking for remote connections and taking control back to local if the remote computer keeps it too long.  I may not have waits is some of those, although they do not influence the panel directly.  The problem is worst when the action loop is not doing anything, so wait may be the answer I need.  Thanks for the tip, I will try it by Friday.
BJ
0 Kudos
Message 3 of 12
(3,898 Views)

Hi BJ,

Glad to help.  Let me know if the Wait function works for you.

Donovan
0 Kudos
Message 4 of 12
(3,887 Views)
Hi Donovan:
I have added waits to loops that I thought might need them, but no real solution came of that.  The "Connection Broken" message still happens, but maybe a bit less often now, and as before it won't happen if the remote computer has control of the VI.  I did not add delays to event loops, as I think they are already "waiting".  These event loops do have timeout cases with a timeout generally around 50-100 msec.  The main VI has only one event loop, but some subVIs are user interface items that use their own event loops.  Is there a minimum time I should add, as some loops are user interface loops where I am comfortable adding 100-200 msec, but there are other loops that are paced by hardware where I only added delays of 5-10 msec to not miss data from the hardware (serial ports in this case).  Another thing I noticed is that the remote computer is still not capable of using control of the VI.  The mouse click works to get control, but from there the mouse seems to be dead as far as its clicks being seen.  The remote computer can not click on any user interface buttons and have them respond.  The remote user can not right click to release control of the VI.  The local computer can not right click to regain control either, but I have a loop running (with a wait) looking for remote connections.  When a remote connection goes into Controlling status, I start timing, and 2 minutes later I take control back to local.  After that happens the remote computer can not get control back as the mouse clicks, left or right, continue to be ignored.  Any more ideas as to where to look would be appreciated.
BJ
0 Kudos
Message 5 of 12
(3,872 Views)

Hey BJ,

Let me look into this further and I'll let you know what I find out.

Donovan
0 Kudos
Message 6 of 12
(3,843 Views)
Hi Donovan:
Just a question to see if you have learned anything yet.  This is coming back to the top of my list of priorities tomorrow.
BJ
0 Kudos
Message 7 of 12
(3,764 Views)

Hi BJ,

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.

Donovan
0 Kudos
Message 8 of 12
(3,739 Views)

Hi Donovan:

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.

BJ

0 Kudos
Message 9 of 12
(3,727 Views)

Hi BJ,

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.

Donovan
0 Kudos
Message 10 of 12
(3,711 Views)