Jump to content

Recommended Posts

I am running into an issue where my VI Server connection goes stale after a few hours.  Looking for a fast way to detect this and recover.

Currently here is what I am doing:

  • On first call, open the application reference and then open the VI reference.  Cache both of these.  Use the VI reference to call the remote VI.
  • On subsequent calls, test the cached references to verify they are still valid and then call the remote VI.

What appears to be happening is the references still appear to be valid in the caller but the connection is broken so the remote call fails.  Then I detect this and reopen the app and VI refs and can again call the remote VI.

The issues are:

  • The failing remote call takes a long time to timeout and I do not see how to control this timeout.
  • The test of the refs does not actually test to see of the network connection is still good.

The result is it takes a long time to recover and this is upsetting the user since it appears the system is locked up.

What I need is a way to control the timeout of the 'call by reference' node or a way to quickly test the references to verify the network connection is still good before I attempt the remote call.

Any ideas?



Link to comment

I could make a simple VI, but there is not much to it.  Open app reference followed by open VI reference followed by call by reference.  Save the app and vi refs for later.  Then wait awhile and try to call the remote VI again with the cached refs.

I am sure that IT is to blame for my open connection going bad, but I can't really control them and just need a way to recover quickly.

I don't want to incur the cost of opening the app and vi refs for every call.  Looking for an alternate solution.


Link to comment

You can get these symptoms if there is a proxy between you and the target. What tends to happen is the connection between you and the proxy is kept alive but the connection to the endpoint from the proxy closes due to inactivity. This means your connection looks good but the tunnel fails when you try to use it. The easiset solution is to heartbeat the connection.

Edited by ShaunR
Link to comment

No proxy but there may a firewall.  Need to talk to the IT guys.  Keep alives would work but the system is not designed for that and it would add to traffic.  Especially when across large distances with limited pipes.

I wish there was some docs about how long the call by ref timeout is and how to control it.

Another option is to store a time-stamp with the refs and refresh them if enough time has elapsed.  Wish there was an easier solution.

Link to comment
9 hours ago, John Lokanis said:

Confirmed that the firewall kills stale connections after 1 hour.  I'll add a timestamp to refresh the connection if it is over 55 mins old.


Still want to know why the timeout for call by reference is so long.  It appears to be 60 seconds and there is no way to change it.

If IT have said that a keep-alive will work, then that is the proper solution and you should be trouble free from then on. Checking every 55 minutes because they said the idle timeout is one hour is just asking for  it to fall over in 6 months when someone in IT decides 45 minutes would be better :)

Edited by ShaunR
Link to comment
16 hours ago, John Lokanis said:

Confirmed that the firewall kills stale connections after 1 hour.  I'll add a timestamp to refresh the connection if it is over 55 mins old.


Still want to know why the timeout for call by reference is so long.  It appears to be 60 seconds and there is no way to change it.

Well that's the problem of using layered software. Standard socket operations are normally synchronous and don't have a timeout parameter themselves. In order to program asynchronously, one has to first set the socket into O_NONBLOCK  and then use  select() or  poll()  before attempting to do a read() or write(). And the timeout for most synchronous socket operations is an option that can be changed for each socket through the setsockopt() call.

VI Server might use internally asynchronous sockets but it is designed as a synchonous interface to the user. The reason is obviously ease of use, since asynchonous interfaces are usually pretty hard to use and debug. And unfortunately nobody thought ever about adding a possibility to add a timeout property to the VI server refnum class. But that's understandable since the VI server refnum is not generally a network connection, it just can be routed over a TCP or ActiveX connection, but just as much be a LabVIEW process internal protocol layer. A timeout property would only be meaningful to the TCP protocol layer but wouldn't apply to the other two classes.

It's the classical problem of abstraction where you can't and don't want to expose all the lower level details to the higher level interfaces, especially when they are not universal for all the lower level implementations.

Edited by rolfk
Link to comment

I've had to tweak some ping/timeout settings for a build manager I wrote. My VI Server refnums were going stale because the foreign application instances would be so busy making an exe they wouldn't reliably service VI Server requests for long periods of time. I'm pretty sure I ended up putting a timeout on the order of an hour or two, so I think it is possible to tweak with this stuff. I can't remember how, if you can't find anything I can try to dust the code off early next week.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By AInvisibleNinja
      I'm trying to run a VI using the Call by Reference function, then embedded it into a subpanel in my Main.VI. Once the VI is embedded, I can't use it in the subpanel. It's like everything is blocked and it won't let me interact with any of it. If I use an invoke node and call the Run VI method, this isn't an issue. Unfortunately, this is part of a much bigger application that use Call by Reference functions, so I can't replace those calls.
      I have attach image snippets showing my code. Does anyone have any suggestions why this might be happening or a work-around to fix it? Thank you in advance!

    • By Benoit
      Hello all,
      Is there any of you ever be able to push more than 30 VI in the exported VI list of VI server?
      I think I found a bug that is there since at least LabVIEW 2011.
      WAIT... don't answer the easy one... "export all VI"... if you were about to answer that, that means you are not developing a safe application.
      Thanks for any help.
    • By ensegre
      I thought there was an easy, built in, VI server way of doing the following, but I haven't found one. Am I missing something trivial?
      So I have one application instance, spawning clones of a certain VI. I would like to get an array of the VI refs of all of these clones. I thought I could via some property like  Application:All VIs in memory, but I haven't found any suitable. All VIs in memory gets only the base VI names.
      Missing that, I resort to register all my clones in a FGV as they startup, , and consult the FGV at will. Is there a more linear way?
      I also note that I have to associate each VI ref with its clone name in the FGV, otherwise plain refs to different clones match as equal in lookups.
    • By Gan Uesli Starling
      Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail.
      I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet.
      My temporary work-around is to open a Windows file browser to that path, the twiddle my thumbs until the file list populates. Then, the path being established, I may safely start the parent VI of which this VI is a sub.
      Any ideas?
    • By Novgorod
      I'm wondering whether there is a way to monitor the SVE (or single processes/variables) on a per-client basis. The purpose of this would be network diagnostics or access control. I know the DSC module allows logging of data and events for shared variables, such as the very handy "value changed" event, but they contain no client-related information (to my knowledge), such as the client name or IP address. Are there any other shared variable events besides the value changed notification (e.g. "variable accessed"), which I have missed?
      Anyway, the SVE seems to be aware of clients, because it allows some access control through the DSC module (and with a bit of hacking even programmatically). You can define access control lists based on computer name or IP address, which is very buggy, but it works somewhat. Is it possible to somehow access this client information (number of clients, names/addresses and activities) from the SVE? I don't see any tools for that, but maybe there is an underlying API through DLL calls or whatever?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.