Network checking

[chembo]

I think option 2 can confirm only that your PC is connected to the network and can see the DNS server. It doesn't make sure that the server you need to connect to is available.

On option 1 you need to check if the string contains 'Lost = 0', not 'Lost = 1'. But again, I think that it is better to check the return code, if it is equal to 1 when the ping times out. Then a return code equal to 0 means that the server is online, so connected = return code 0

[chembo]

I take that last reply back. Ping has return code = 0 also in some cases when the the host is not online, for example Destination host unreachable.

You need to parse the return string. I think it is better to check if the command was successful. I guess it is pretty safe to assume that something like 'Approximate round trip times' is present in the reply only when the host is online. So, something like that may work:

Just FYI. I noticed something strange, but I guess this is related to our particular network. I tried to ping a workstation which is a dual boot WIndows 7 machine. And surprisingly I can ping both instances, even if it is absolutely impossible that their are simultaneously online. This happens because the IP address of the offline partition is used right now by a different PC.

This shouldn't be a problem for a server which is constantly online and probably doesn't change the IP address.

[altenbach]

---

@Munna232 wrote:

What about second idea? I think option-2 is much faster than option-1.

---

You need to test for two cases:

1. network connected
2. network disconnected.

On my computer, I get the following results:

1. network connected
1. Timer 1 = 0.08s
2. return code = 0
3. Timer 2 = 0.001s
2. network disconnected.
1. Timer 1 = 2.25s
2. return code = 1
3. Timer 2 = 2.25s

As you can see, they both take a long and similar time if the network is not connected.

[Munna232]

Dear Chembo & Christian,

Thanks for your replys.

I checked both the options in my office PC. Always I’m getting like below snippet (in option-1 standard output).

Return code = 1

Lost = 1  (When network is connected)

[chembo]

There is a 'Request time out' message in your first example. You didn't get any response from the server, i.e. the packet was lost. This maybe cause by firewall setting. Try to ping a host in your local network, for example the one that you need to connect anyway.

I noticed that 'ping' has many different types of errors and I am not sure when the return code of the System Exec will be = 1. This indicates indicates an error, respectively unsuccessful ping.

It is probably better to parse the ping return string for specific text. I was trying to keep the 'match pattern'  regular expression simple. But if you want to make sure that the ping received a packet back, just use as regular expression:

received = [1-9]+ instead of 'approximate round trip times'.

Sending one packed and receiving it back should be good enough in order to assume that the server is really accessible.

[rntaboada]

Dear chembo.

I'm not really sure if the 'return code' is useful to know if I have connectivity. I was doing some tests sending a ping to an IP number with guaranteed connectivity and I got as response: bytes=32 time<1m TTL=127. On other IP number I got as response: Destination host inaccessible, in both cases the 'return code' was always 0. What this tells me is that if the ping gets a response the 'return code' is 0.

I did a test by disconnecting the network cable from the computer (set the computer offline) and in this case the 'return code' was 1.

[rntaboada]

Dear Munna232

Looking for a solution to my problem, which I believe was the same as yours, I came up with another approach to the one presented in this discussion. I don't know if it will work for you, but I think it would be good to consider.
The idea behind it is as simple as using a PHP function to check the connection to the server. On the server you should leave a file, for example 'connection_status.php' with the following code:
<?php
echo connection_status();
?>
In my particular case, I left the connection_status.php file at: \\IP_address\web\iot\config\php. Of course, this will be possible as long as you have access to the server, but in case that is not the situation this project will not work for you, unless the server administrator agrees to your request to place this file on the server.
The rest of the work is done by LabVIEW.

Then with proper error handling you can handle the rest, for example if the IP address is not correct, it may give you 'Error 56 occurred at LabVIEWHTTPClient.lvlib:POSTBuffer.vi:6120001', or in case you lose the network connection, the error may be: Error 363500 occurred at LabVIEWHTTPClient.lvlib:POSTBuffer.vi:6120001.

I hope it will help you.

Note that check_server_connection.vi is for LabVIEW 2014.

BR.

[Frozen]

---

@rntaboada wrote:

Dear Munna232

Looking for a solution to my problem, which I believe was the same as yours, I came up with another approach to the one presented in this discussion. I don't know if it will work for you, but I think it would be good to consider.

I hope it will help you.

Note that check_server_connection.vi is for LabVIEW 2014.

BR.

---

I am hoping that the OP has found a workable solution in the past 8 YEARS!

[rntaboada]

Dear Froze.

It was just an idea that might be useful to consider, but it is by no means finished. I'm working on improving that code because I need it. I'll upload it later.

Thanks.

[Kyle97330]

Just a general note:

If you want to "ping" an IP, using the command line tool is a bit of a kludge.  Instead, use a .NET call to "system.net.networkinformation.ping":

https://learn.microsoft.com/en-us/dotnet/api/system.net.networkinformation.ping?view=netframework-4....