Datasocket write and close / remote OPC server / PC freeze when no connection

[Christ0phe]

[Labview 8.21, Windows XP SP2]

Hello

I am getting data from a remote OPC server using the Datasocket techniques. Depending on the DS family of routine that I use the behavior is different when the OPC server shuts down or Ethernet link is cut.

In the NOK application attached, as soon as the link to the OPC server is cut the application and the whole Labview environment gets stalled, either in the DS Write or in the DS Close icon. Never in the DS Read icon.

Also the Timeout to read or write does not work in neither application. Whatever the number I set it will never be taken into account.

Is there some sort of 'miracle' setting in the Labview.ini file that can make the NOK application to work correctly and step out of the DS Write or Close vi when such link cut occur? More generally could someone explain why the behavior is different between the two applications, if there are new Datasocket routines that would handle these kind of communication in a clean way?
Thanks

Christophe

[ThiCop]

Hello Christophe,

Can it be that some files are missing?

My LabVIEW cannot find the LC6.lib that you're using in your code.

Which version of LabVIEW are you using?

Kind Regards,

[ThiCop]

It's the DSClose VI and the DSOpen VI from the OK version I'm talking about.

They are located in LC6.lib\divers.llb

[Christ0phe]

Sorry, the missing Vis come from here:

http://zone.ni.com/devzone/cda/epd/p/id/3169

[Christ0phe]

I am desesperate. The Datasocket - OK version.vi 19 KB that seemed to work so well (no freeze at all) creates a huge memory leakage as you can see in the attached file. I am only reading a tag (local OPC tag, not even remote tag on another PC's OPC server) and the word document attached shows the issue:

After 15-20min during which no increase of memory is noticed (first picture) the situation starts to worsen. In 12 hours (about 7200 read operations) it reaches a consumption of 65Mb ! (to read everytime the same OPC tag). Something that I never noticed with the Datasocket - NOK version.vi 19 KB that had the freezing issue...

I really do not know what to do.

Thanks for your prompt feedback

Christophe

[viScience]

Try pulling DSOpen out  of the loop and closing the INIDSCtl.Data refnum after read its value.

[Christ0phe]

Hello and thanks for the answer. The vi that shows the memory consumption issue is that I posted in my last message:

Benchmark Datasokets.vi 38 KB

In this Vi there is only one open at the beginning then only read.

[peper2001]

Hi,

Has anybody found a solution to this problem?

I'm facing the same situation where my whole application freezes when somenone disconnects the OPC server (reboot). Actually,the time-out functionnality of the datasocket open connection vi doesn't seem to work. If you try to connect to an IP adress that doesn't exist (for instance opc://10.30.40.5/OPCSever.MyOPC/Dummy_data where 10.30.40.5 is not a valid IP adress), labview hangs whatever the time out value.

I also tried the databinding functionnality and it behaves exactly the same.

Labview 2010 SP1

Windows XP SP3

CR.

[ThiCop]

Hello,

Sorry for the late reply.

At the moment I'm also also handling a Service Request that is about exactly the same issue.

Between giving courses and holidays I lost track of this post, so I'm answering it now with quite some delay.

I was able to reproduce the "freezing" behavior.

One thing that I have noticed while doing benchmarking on the Datasocket VI's is that the code itself does work in time.

The User Interface however seems to "freeze".

I'll post these benchmarking VI's if someone's interested in them.

Regarding the "freezing" behavior: I'm currently looking for a workaround for this problem and when I find one, I'll post it for sure over here.

[Ben]

Please take this with a grain of salt since I am going on memory and this may apply else where...

But if you use the Old-school approach of doing a DS Open first, you can hang a property node on the refernces and set the timeout..

Ben