How do I configure the TCP/IP stack on RT controller

[dacxx01]

We are troubleshooting a LabVIEW RT application running on an 8146 PXI controller. We are having problems with the controller hanging when Ethernet communications with a remote PCs is lost. Communications between PXI and PCs is via Datasockets, each of the two remote PCs running their own Datasocket server. We have explored all sorts of options with the Datasocket comms, when it works it's OK but it doesn't seem at all robust to failures of the Ethernet link.

We are now examining the configuration of the RT engine ni-rt.ini file. The TCP/IP stack configuration section is:


[TCP_Stack_Config]
DNS_Address=0.0.0.0
Gateway=0.0.0.0
Halt_On_Error=FALSE
IP_Address=192.168.1.4
Max_Sockets=64
Subnet_Mask=255.255.255.0


?What does the Max_Sockets=64 line mean, does it restrict the number of datasocket primitives we can effectively use?

Also when we build the LabVIEW Application for the PXI the build process announces that the PXI already has it's own copy of some vis, including:

elvsock.dll
niwd4c.dll

Is this something we should worry about in terms of version compatibilities etc.

[JR_A.]

What version of LabVIEW RT are you using? I had seen an issue like this with LabVIEW RT 6.1 which was actually an issue with non-Windows network sockets not reporting the connection loss. In LabVIEW RT 7.0 Datasocket this issue was resolved. Another workaround would be to add a toggling boolean value on the DataSocket Server and if the connection is lost the value will quit changing and you'll know the connection was lost. I wouldn't worry about the ini file settings.

JR A.

[dacxx01]

JR A, Thank you for your answer. We're using LabVIEW 6.1 and we're coming to the conclusion it was a system level problem in the PXI as you seem to have confirmed. We have tried a similar approach to the one you have suggested, actually using an updated DBL (holding the time) at the Windows end to act as a software Watchdog on the Comms link. This improves the robustness but it's too early to tell if it has cured it. Datasocket comms seems a bit flaky and we've observed other strange phenomena (e.g. running two parallel While Loops in a single VI each with its own datasocket comms to different URLs gives strange results on DSS reads). Is the LabVIEW 7.0 more robust? and also is there a formal fault report of the 6.1 fault somewhere on the NI website?

regards


DAC