From: T.
Sent: Monday, October 11, 2010 11:04 AM
To: Zbynek Zahradnik
Subject: OPC server

Hallo Zbynek,

.....

I visitied a customer last week who have had some strange problem with two installations. He is using the OPC server I developed last year. They are running in virtual machines on Server 2008 platform. The client is a WebFactory SCADA. Common to both are also that the link is unstable (GPRS and heavily loaded WAN) which make the server reply OPC_QUALITY_BAD now and then, just as it should. It seems that sometimes when a timeout occurs and state changes from OPC_QUALITY_GOOD to OPC_QUALITY_BAD the OPC interface is stopping. When this have happened and I start another OPC client, the tags WebFactory have subscribed to are reported as OPC_QUALITY_GOOD, all others are reported as OPC_QUALITY_BAD. However, even if I subscribe to the tags using another client, they will not be polled. It seems like it never gets to the Leaf::Read() call.

The timestamp is when the timeout occured and quality changed. Really strange.

Have a look at the attached JPG.

The server seems to be running and could be shutdown and restarted without any problems. Also my comm-threads (one for each channel) seems to be running,

I can connect using my comm-trace tool (I'm using a socket connection to a comm-debug thread within the server).

The failure occurs within a couple of weeks. Number of timeouts occuring before failure occurs is several hundreds.

There are about 25 other installations around running without any problem, but I believe most of them are running on 2003 or XP.

I will get a VMWare session with Server 2008 and the customers config within a couple of days and will do some bench-testing the next coming weeks.

Anything you have noticed somewhere else, or do you have a clue?

Regards,

// T.....

Zbynek,

I have got a Server 2008 VMWare session I will use for 'in house' testing, running Visual Studio in debug mode with simulated devices. The problem seems to arise when devices go online/offline and it is not easy to setup a real environment. However, the ::Read thought is just a feeling. I do have some critical sections wrapping common device data (it is a front-end-back-end driver), but the CS's are device specific (one thread per device) and all seems to stop. It could certainly be caused by one device anyway. The only common CS is the trace thread CS, and it is still alive. It reports device names at connection time as it should but not comm is taking place. The comm is triggered and kept alive by the ::Read calls.

Just leave it for now and I will get back to you with results, I more or less wondered if you have seen this somewhere else before I put in some effort into debbuging.

Thank you for now,

// Tomas...