Datasocket bug in Win2K -- stops updating

[josborne]

===OVERVIEW===

I have a simple Datasocket system that produces a very strange problem on Win2K

After a variable amount of time (between 30 seconds and 30 minutes), the datasocket reader simply stops receiving updates from the writer.

The system involves a basic DS Writer and DS Reader which communicate through the localhost DS Server. I have included the Reader and Writer VIs for your testing. Also, it seems to be easier to reproduce if the VIs are compiled into executables. I have included the executables for testing. The problem is also reproducable when the "reader" is actually a C++ program (using Measurement Studio) that is built into an OCX component (not included).

NOTE: This bug does not seem to be reproducable on WinNT.

I have spent a lot of time debugging this system... with no luck. I have narrowed it down so that it is very reproducable. Just run the Datasocket Server and the two attached EXEs on Win2K (Professional) and wait a while... eventually you will see the reader stops getting updates.

===SYSTEM DESCRIPTION===

The DS Writer connects to the DS Server in "write" mode and sends an array of doubles. An "attribute" is specified as another array of doubles. The writer then updates the connection. The two arrays are meant to represent values and timestamps.

The DS Reader connects in "read-auto-update" mode. It waits for an update and then reads the array and its "attribute array".

Have a look at the attached examples... they are very simple.

===PROBLEM===

The problem is reproducable on our Win2K machines.

After a variable amount of time (usually not more than 10 minutes) the reader simple stops receiving updates. The DS connection is reported to be "Active: Connected" and status is "ConnectionActive".

===NOTES===

I am using LV6.02 and the latest version of Datasockets 4.0 (370).

The 2 VIs are in the same execution system: User Interface.

Power management on the PC is set to "always on" and all power saving, sleep functions, screen savers, etc. are disabled.

I am using the "old" datasockets VIs (open connection. read/write double vector, close connection, etc.). I realize that the "bug" I am reporting might actually be fixed if I used the new Datasocket VIs that come with LV6i, but we really don't want to use those VIs. We find the older VIs better because:

1. The older VIs seem to be faster at writing large vectors. We discovered this through testing.

2. Reliability of maintaining connections. The older VIs appear to be better at maintaining connections.

3. The new VIs have trouble getting the items to appear (and with the correct icon) in the "browse measurement data" window.

No other significant network activity is seen when this bug occurs. It seems to happen randomly.

[Roadkill]

Sorry, this isn't an answer, but just confirms what you already know.

I have the exact same symptoms while using the DataSocket Server with VB 6.0 and the NI Measurement Studio. We too are using Windows 2K. After anywhere from 2 minutes to 30 minutes the reader socket just stops working. The write socket still seems to work. I am still investigating causes and solutions.

[josborne]

I have an ongoing "support request" with NI concerning this bug. They can reproduce it too. It appears to ocurr only when the writer is "compiled" (i.e. and not running in LV) on Win2K, and only for large data transfers.

So far, NI hasn't provided a solution except the obvious - to switch to WinNT. I will post any more info that I get from them.

[Roadkill]

We set up a test machine with Windows XP and the datasockets seem to work properly now. The speculation here is that the TCPIP stack in Windows 2000 is the problem.

[Doug R]

Experimented with XP today. Server stopped putting out data about 20 minutes after starting.

[Doug R]

I have the same problem.
system
- dual Xeon 1.6ghz P4
- 1 gig ram
- 100 gig scsi 3 HD
- dual monitors

Original programs used Visual Basic to write to MySQL database. Program 1 captured data and sent out via array. Program 2 recieves data and stores it at 2hz. Program 3 recieves data and charts it on a nice HMI.

After talking with NI decided to use Labview DSC. App is built but get same symptoms on any newwork reader applications. Sometimes the app never gets new data once the error happens occasionally it will start running again. Code is very simple.

[Doug R]

Tested reader on NT4. Had loss of data again.
writer win2k ( not compiled )
reader nt4 ( compiled )

the writer is a DSC app with 192 analog IO and 2 32bit port reads of binary data.

[Doug R]

New test:
Server = win2K labview6.02 DSC 192 analog tags
Computer1 = NT4 compiled viewer program
Computer2 = XP compiled viewer program
Computer3 = 98 laptop compiled viewer program
Computer4 = win2k Athlon system compiled viewer

viewer program simply charts data connected to an indicator via datasockets "logos://m2_strip/labview/bias_i" ( 24 tags are viewed the same way )

Server program is my DSC app running tag engine. No code except the HMI wizard code for the charts.

I witnessed two times all three readers stopped getting fresh data. To get all three to work I only need to stop one viewer and restart it. ( STRANGE )

[Doug R]

Spent the day putting XP on the server. Finally got everything going and found XP stopps after average of 20 minutes.

I am trying to get my copy of labview 6.1 to see if that fixes anything.

[Anonymous]

I am sorry, I coudn't find the original post,
so I am not sure what the problem is.

Just though to tell that that I had problems with
LV 5.1 on win98/NT and datasocket(?).

I am not sure if datasocket is the cause of problem,
since we haven't been able to explore and test the
system properly.

We have a measurement system which measures data
through serial ports, saves it and uses datasocket
to share data accross a factory.

Sometimes like once in two weeks or in two months
or once in a year the measuring system jams. The
Windows still works. We haven't been able to
find where the jamming happens but it started
after I changed the program to use datasocket
instead of netdde.

Juha L