Open Application Reference: why is timeout not working?

[Christ0phe]

Hello Labview expert,

I have 100 applications Labview 8.21 compiled applications running in different plants. All are connected to our enterprise network. One particular application acts as a gatherer, collecting data from all 100 PCs once per hour, 24h/day, 365d/year. To achieve this it uses a Labview to Labview communication link using: Open Application Reference then Open Vi reference to get the content of several globals. Then writes into an SQL database.

My question is about the way 'Open Application Reference' works. From time to time it occurs that some of the 100 Pcs are in an unstable state (slow, not completely frozen but near,...). The 'Open application Reference' to that PC cloggs and tries to make this link forever even if I play with the Timeout (ms) control. That is a catastrophy because all PCs after the one that creates this issue will not be scanned at all. How to force the application to exit this Open Application reference action and why is the timeout not working? Is there a magical switch to enable in the application .ini file?

All lights heartly wellcome

Thanks a lot

Christophe

[Ben]

I don't have time to dig right now but I think there is more than one T.O. The TCP/IP conncetion as long as it is valid and active will not timeout.

Have you concidered spawning seperate agents to do the polling so that no individual error hurts to rest?

Ben

[richjoh]

---

"How to force the application to exit this Open Application reference action and why is the timeout not working? Is there a magical switch to enable in the application .ini file?"

---

Does your "Open App Ref" output error code 56? If so that error code 56 can be used to handle the situation. U want to use the unbundle on the error out and look for 56 (if its happening of course) then clear the error (Clear Error.vi or a bundle) and loop back to try several times till your tries expired. This is handling the error... .

Yes it appears the timeout is always 21 seconds no matter what setting...posting a vi pic that requires a logical change for your case....

[Christ0phe]

Hello and thanks for your answers,

In the cases that I mentioned, my Open Application Reference does not output anything, it stays executing the yellow Open Application Reference icon forever without taking into account whatever Timeout I specify.

Running all Open Application Reference could make every other (stable) stations reachable but the fact that it can still hang into one or several Open Application Reference will make impossible to terminate the VI that calls these paralleled Open Application Reference...

Christophe

[richjoh]

Are you closing the references once your done with the specific machine. Does the hanging occur on the first Open Appl Ref (expect not) but subsequent runs hang? I believe its how your coding is handling the Open Application Ref VI.

Here a paste from the manual.

"If you do not close this reference, it closes automatically after the top-level VI associated with this function completes execution. However, it is good practice to conserve the resources involved in maintaining the connection by closing the reference when you finish using it."

[Ben]

If the T.O is being ignored completely we are looking at a serious bug (that one of my peers would have seen by now since we use VI server in many apps) or something weird on your machine.

It could be explained by something like a Firewall preventing outgoing messages or blocking access via some other thingy (I got tired of searching for the right word).

I'd try it again on a clean machine or chase down the system logs.

Desktop Trace Execution Toolkit may tell us exactly how far it is getting before it dies.

Curious about the results you find,

Ben

[Christ0phe]

References are closed at the end of the calling VI. But anyway if the target PC is unstable, the problem will occur as soon as the first time.

[Ben]

Re: one failures screwing it all up.

Multiple pollers spawned from a single template each looking a seperate machine will prevent a single node failing the others.

Ben

[Christ0phe]

Running all Open Application Reference parallel could make every other (stable) stations reachable but the fact that it can still hang into one or several Open Application Reference will make impossible to terminate the VI that calls these paralleled Open Application Reference...

It is not a question of Firewall (because when a station creates the issue, others in the same plant pass successfully through) and it happens only from time to time.

[Ben]

---

@Christ0phe wrote:

Running all Open Application Reference parallel could make every other (stable) stations reachable but the fact that it can still hang into one or several Open Application Reference will make impossible to terminate the VI that calls these paralleled Open Application Reference...

It is not a question of Firewall (because when a station creates the issue, others in the same plant pass successfully through) and it happens only from time to time.

---

Good points!

Any patterns to the failures regarding whcih one fails and any unique netowrk topography or what-not?

Since it is intermitant try to get a Sniffer running at the time of the failure is probably a challenge.

my thought are now wondering down the path that the network is giving you trouble but it is still alive enough that the T.O. is being triggered.

Yes I admit no solution from me just ideas.

Ben