Fast Ping

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

It will still work on 32-bit LabVIEW. The 32-bit Windows Winsock is documented to use 32-bit SOCKET values,

Then they can't use the upper bits in a future version if they want it to work on 32 and 64 then  If it was Linux, I'd be worried but M$ tend to keep backwards compatibility.

1 hour ago, Rolf Kalbermatter said:

That may go fine as long as the upper 32-bits aren't used but it may also go wrong. If you change it to be a LabVIEW 64-bit integer everywhere in LabVIEW itself and configure those parameters everywhere as pointer sized integer, it will always go right,

I think we are talking at cross purposes, I am talking only of the FD arrays for the Select Single VI in this API but I think you are talking about the socket type generally. I just fixed the error in select to get it to work. You'd have to speak with the original developer, All my socket API's use a U64 on the compane and usz in the CFLN - which was why I fixed the select the way I did. I'm not planning on using this API so if there are more issues, then the owner should address them (otherwise there'll be hundreds of variants kicking around; each with their own buglets).

[Rolf Kalbermatter]

40 minutes ago, ShaunR said:

Then they can't use the upper bits in a future version if they want it to work on 32 and 64 then  If it was Linux, I'd be worried but M$ tend to keep backwards compatibility.

I think we are talking at cross purposes, I am talking only of the FD arrays for the Select Single VI in this API but I think you are talking about the socket type generally. I just fixed the error in select to get it to work. You'd have to speak with the original developer, All my socket API's use a U64 on the compane and usz in the CFLN - which was why I fixed the select the way I did. I'm not planning on using this API so if there are more issues, then the owner should address them (otherwise there'll be hundreds of variants kicking around; each with their own buglets).

If you are not using this code anywhere then you are fine here. I thought you may use it in some production code and I would find it in that case not a very responsible choice to swipe it under the rug with the reasoning that it just works anhow.

[ShaunR]

1 hour ago, Rolf Kalbermatter said:

If you are not using this code anywhere then you are fine here. I thought you may use it in some production code and I would find it in that case not a very responsible choice to swipe it under the rug with the reasoning that it just works anhow.

Nope. I can't use anything that I didn't write myself unless it has an explicit licence that I can adhere to . I have another solution that also supports IPv6.

Edited April 10, 2022 by ShaunR

[CT2DAC]

On 4/1/2022 at 5:05 PM, hooovahh said:

Attached is my terrible and hacky solution that works pretty quickly.  On Windows it uses the Ping View Info program calling it from the command line, then parsing the results.  It uses a couple of functions from the OpenG File I/O.

Find Ping IP Devices.vi 77.1 kB · 18 downloads

In LV2018, please, please....

 

[hooovahh]

2018 attached.  It does require the OpenG File package.

Find Ping IP Devices (2018).vi

[CT2DAC]

👍
Thank you so much!!!