How to Ping a network device from RT controller

[Nandagopal]

Is there any ways other than TCP/IP or FTP to ping and check whether a particular network device is present or not in the network by using RT controller ??

Thanks,

Nanda

[viScience]

I believe there is a vi called 'find all targets.vi' in the system configuration api

http://joule.ni.com/nidu/cds/view/p/id/2116/lang/en

[BlueCheese]

The "Find Targets" VIs will only find NI RT controllers. If you want to do an ICMP ping to a non-NI device it will not do what you want.

A while back I wrote up this VI to do an ICMP ping on Windows, PharLap, and VxWorks controllers that should still work. On VxWorks devices there was a bug in the WindRiver implmentation that would incorrectly add a delay to the round-trip time---I do not know if this has been fixed.

Eric

[viScience]

Nice VI thanks!

[g_l_u_p]

---

@BlueCheese wrote:

The "Find Targets" VIs will only find NI RT controllers. If you want to do an ICMP ping to a non-NI device it will not do what you want.

A while back I wrote up this VI to do an ICMP ping on Windows, PharLap, and VxWorks controllers that should still work. On VxWorks devices there was a bug in the WindRiver implmentation that would incorrectly add a delay to the round-trip time---I do not know if this has been fixed.

Eric

---

I tried it on both my PC and a PXI-RT using LV2010 and it work perfectly!

The problem is I tried "translating" it to LabVIEW 7.1 and LV closses inmediately

Would you have an older version of the VI for PharLap?

[g_l_u_p]

Update!

My LV7.1 vi doesn't close inmediatelly anymore

However, it timesout on the "select" before the "recvfrom".

Any ideas?

Regards

[QFang]

This VI (after some clean-up) is AWESOME!

Thank you!

[BlueCheese]

---

@BlueCheese wrote:

A while back I wrote up this VI to do an ICMP ping on Windows, PharLap, and VxWorks controllers that should still work.

---

Someone told me that this Ping.vi was broken on newer LVRT targets running PharLap (at least in 2016, but probably was broken when some parts of the network stack were upgraded a few years back). I took a quick look and fixed the VI. Attached is a 2017 version.

[xl600]

Can you save that back in 2016?

I went through and figured out a few things with the old ping.vi.

• winsock32.dll is obviously single threaded and wants to be on the UI thread (Why, I don't know).
• The select calls can be on any thread so they don't stall the UI thread fortunately
• For some reason, I had to surround the entire thing with a timed sequence (or single-shot timed loop)

I'd bet if I understood why the above (timed structure + UI thread) were both required for this to work in ets, I'd know an awful lot more about how LabView works

[BlueCheese]

I don't have a chance at the moment to save back to 2016. However, the only two changes needed are:

• Disable the non-blocking ioctl call at the beginning as it is not needed/supported the same way
• Fix the closesocket() call at the end to use stdcall convention (this was a bug in the VI)

There is no issue with using sockets from multiple threads. I suspect the second issue was causing funny crashes that changed behavior depending which thread you were calling from.