DataSocket fails intermittently with multiple NICs enabled using LV7.1

[Michael H]

Using LV7.1 and Datasocket v4.2, I was intermittently (but quite often) having problems reading and writing to the datasocket server (primarily from the server side). My application should read the value in the item and upon finding a specific string it should immediately follow it with a write of a default string. However, it can find the same string multiple times and not complete the write. Logging the errors from the write shows that no error is occurring. The client is not at fault because it only writes the string once every few minutes. I was able to finally show that by disabling the extra NIC on my system running the datasocket server that the connection seems to operate reliably. Both NICs
were set to static IP addresses, but only one was connected. I do have the program writing to "dstp://localhost/UUT" as opposed to a specific IP address (not sure if it matters).
With Labview6.1 I did not have this problem. It was only after I re-compiled my application with LV7.1 that I started having issues.

[Philip_Courtois]

Hi Michael,

Some questions:

What do you mean with �it can find the same string multiple times and not complete the write�?
Does the �DS Read� function return the specific string you are looking for?
Do you try to write the default string back to the same data member (/UUT)?
What if both clients run on the same machine?
Can you run the examples �DS Writer.vi� and �DS Reader.vi� that ships with LabVIEW?

Best regards,
Philip C.
Applications Engineer
National Instruments

[Michael H]

Philip,
Thanks for the quick response.
My default string is "Loop". Externally, I loop the attached vi searching for something other than "Loop". If something else is found, this vi will immediately write "Loop" back into that variable. If I only have one NIC enabled, then this works flawlessly. If I enable the other NIC in my system, then it does not work properly. For example, I will have a separate system write "BOOT" into the variable. The server side will see "BOOT" multiple times per my logging included in the VI. Per the logging, it is writing "Loop" and not failing with the write. But if it was successful, then it should only see "BOOT" once since it should see "Loop" on the very next iteration.
You will note in the VI, that I use a refer
ence and an explicit string to define the socket connection. This was from earlier debug. They are both directed towards the same socket variable.
I also tried replacing the "localhost" with the specific static IP address, but that did not help.
As for the DS Writer and reader vi's... I will take a look at them.
Thanks again for the help,
Mike

[Philip_Courtois]

Michael,

Try to add the UUT data items as Predefined Data Items in the DataSocket Server Manager. This will keep the item in memory between connections to the server.

Does this help in your case?

Best regards,
Philip C.
Applications Engineer
National Instruments

[Michael H]

I already have them predefined. I set them as string with initial value of "OK". I also set to "Allow Multiple Writers". I also set all permission groups to "everyhost". All else is default values.

Mike

[Philip_Courtois]

Please run the attached VI. Does it still give you problems when adding a NIC?

Best Regards,
Philip C.
Applications Engineer
National Instruments

[Michael H]

Yes, I still have problems with your VI. However, I did discover that something else seems to make the problem worse. My main application is writing to up to 8 data socket variables (UUT1 to UUT8) for 8 test units. If I run only one UUT test, then it appears to work well with multiple NICs enabled(I haven't run for extended periods yet). When I ran with three UUT tests, I got failures like I have been seeing. I'm beginning to wonder if it has to do with the NICs as well as multiple variables and/or re-entrant vi usage.

Mike

[Michael H]

Additional testing today showed that I only had one instance where I received the boot string twice in a row while running two UUTs writing to variables UUT1 and UUT2 respectively. This was one failure in 300+ cycles. As soon as I added another UUT(3), I began having failures more often. In 12 cycles I had 0 errors on UUT2, 4 on UUT1 and 6 on UUT3.

Mike

[Philip_Courtois]

Hi Michael,

It seems to me that you are running out of bandwidth when running your application. How often do you write to the data items? If you write too often you could starve the connection. Make sure to use proper wait functions in the writer loop. You can monitor your network activity using the Windows Task Manager or the free software from Ethereal.

Are you using reentrant VI�s? If you are, do you still see the issue when the VI�s are not reentrant?

If nothing makes it work in LabVIEW 7.1, but it works in 6.1, please create a complete example including the writer so I can reproduce it here.

Thanks,
Philip C.
Applications Engineer
National Instru
ments

[Michael H]

Philip,
I do not feel I am running out of bandwidth since I have run it successfully on 1Gbit NIC connections on a P4 2.4GHz system as well as a 10/100Gbit NIC on an old 650MHz system with LV6.1. I only do two writes per variable (on up to 8 variables) once every few minutes. I did not seem to be a re-entrant VI issue.
I have created two VIs which should allow you to recreate the failing conditions with multiple NICs enabled. It responds very quickly with one NIC enabled, but when one or two more NICs is enabled, it gets very slow to respond and has some timeouts.
One VI is the writer, the other is the reader. Start both VIs and start all 8 reader loops. Then you can consecutive
ly click on all 8 sender loops. Doing this with and without multiple NICs enabled should show you the problem.
Note: I think the issue I was talking about in earlier posts about getting multiple strings back before it wrote out "Loop" was due to the fact that the writes were not occurring quickly enough and the reads were happening multiple times. Therefore, in these VIs, I revised the read and close timeouts to -1.

I think it would be best if you could call me so we can discuss this issue. If you can email me, I will send you my contact information if you don't already have access to it.