LabVIEW
detecting a closed TCP connection
Usually this is done in the server. In the server you should have a loop that keeps polling the connection(s) for incoming commands with TCP Read. If you do this with a timeout of 0 seconds you can actually serve several connections in the same loop without having to resolve to one independant deamon per connection. This read function will either return with data or with an error. The error itself is the interesting part. Mostly this will be 56 (timeout error) and of course should be ignored. Any other error would indicate something has gone wrong with the connection and you probably should close the connection at your end as soon as possible (don't wire in the error cluster from the read function into the close function since you want to close the connection always on error.
@Ken Kearney wrote:Dear All,I use a GPRs module to connect to a labview tcp server. Sometimes the module disconnects from the server and the server doesn't notice that the connection has shut down. Is there any way I can check for a connection that has shut down? How can I check that the TCP connections that Labview thinks are open are really open?
There is a small chance that you won't see any other error than timeout eventhough the connection has been dropped somehow by the client. This can happen if the disconnect handshake in the TCP IP protocol gets hung somewhere. I've seen this with certain network hardware when the cable was disconnected. The only way to resolve this is by requesting the client to always send some sort of heartbeat message that needs to be acknowlegded by the server too. If the server then does not receive a message for a connection for some time you want to disconnect that connection too on your side (and the client should disconnect too after not receiving an acknowledgment for its messages for a certain time).
Rolf Kalbermatter
Message Edited by rolfk on 07-07-2006 09:57 PM
LabVIEW is not in the picture here at all. What you need is a mobile network provider that can tell you how to setup your network configuration for the OS your are using. In the past this has been proven to be a major hurdle with tech support telling me that since I wasn't using the specific Windows version they were using it couldn't work. Basically it does work with just about any Windows version down to NT4.0.
@patchchen wrote:
Ken
how do you use LV to connect GPRS and TCP/IP? could you tell me? I try three all days and still not work.
thanks a lot
PatchChen
The magic is to configure a dialup connection with the service provider specific settings. First you setup a modem for the COM port your GPRS modem is connected too. This will be dependant on the COM parameters the modem interface of your GPRS device requires. Here the first possible hurdle can be already encountered as you will usually have to add an extra strings under Ëxtra Parameters" in the modem configuration. Your network service provider needs to tell you the axact parameters you need here (Something like "+CGDCONT=1,"IP", "office.vodafone.nl")
Then you create a dialup connection and here the second hurdle will show. Create a phonebook entry and the phone number to dial will be something like "*99***1#". Again this is provider specific AND also can depend on the modem you have. The server settings in the dialup connection would be similar to Server Type = "PPP: Windows NT, Windows 95 Plus, Internet", Protocol = TPC/IP, and local TCP/IP setitngs are usually assigned by the server. Then you need a username and password to log in that will be provided to you by the service provider.
The last hurdle is that this dialup connection is now a link in your Network Folder. You can open that folder and click the link to connect to your network before using your LabVIEW software with simple TCP/IP primitives or you can find a LabVIEW library to control the Remote Access Interface in Windows directly to invoke and disconnect the GPRS network dialup whenever your application requires it.
This information comes from a setup that is a few years old and was done for a Windows NT 4.0 machine but is in principle still valid. The real challange for me was to find someone from tech support at the phone company that did understand enough basic details about their GPRS network setup that he could tell me the necessary details that are always network provider specific. After a few calls with incompetent tech support people that could not go beyond the most basic questions such as what Windows version I was using and if the modem was hooked up I was lucky and got a guy that could tell me the correct setup for Windows and from there it was just figuring out the differences in Windows Dialup configuration between my version and W2K.
Rolf Kalbermatter
@SCMAJA wrote:
I am doing a connection to another TCP server with my VI client, is it possible to get the VI register if the connection is somehow lost, e.g. if the server has crashed or the cable has been unplugged without sending this heartbeat signal? If I have to send this heartbeat signal, the server will have to be able to register this signal too? I am not able to make the server handle this signal because it is remote, therefore I cannot change the serverprogram.Simon Bøgh
No there is no way in TCP/IP to do that. In most cases the connection should return an error to indicate that the remote side has dropped the connection, but as said sometimes the connection can get hung and you see nothing on your side that the connection is already dead unless you attempt to do some communication.
Rolf Kalbermatter
