LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Ping from LabView RT 2014 (PharLap)

I am unable to get the LabView RT capable ping.vi to work from LabView RT 2014 (PharLap).  Upon the first FIONBIO call to ioctlsocket, a SOCKET_ERROR (-1) is returned for all addresses including 127.0.0.1.  This is preventing the vi from functioning.  I need to ping from all interfaces (i1000e and nigev based) on my PXIe RT controller.

 

According to multiple posts in the original thread and this thread, this vi should work fine.  So, is there some recent LabView RT incompatability with ioctlsocket in PharLap that I need to account for with trying to use this VI?

 

Thanks,

 

XL600

 

p.s.

 

Come on NI!  Why on Earth do you not provide a ping vi natively in labView RT?  I mean, really... that is a seriously basic network thing to need.  Having to hammer on ioctlsocket just to get ICMP pings working seems silly.

0 Kudos
Message 1 of 8
(3,695 Views)

Never mind. For some reasons I read VxWorks instead of Pharlap

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 8
(3,666 Views)

I'm not sure that I understand what you are trying to do.  Are you trying, from you Host Computer, to discover the IP (or other information) of all the PXI controllers on the same network (one of which should be the RT Target for your code)?  In LabVIEW 7, I used a function that I think was called "RT Ping" to do this, but in LabVIEW 2012 and 2014, this wasn't present.  

 

Have you tried the Find Systems function, found on the RT Utilities sub-Palette of the Real-Time Palette?  If I'm "answering the wrong question", I apologize -- point me in the right direction.

 

Bob Schor

0 Kudos
Message 3 of 8
(3,651 Views)

No, my RT PXIe controller IS the host for an SBC running vxWorks (Not LabView) and needs to ping that module periodically.  I need to ping FROM the RT controller as a result.

 

Pinging the RT controller from my host laptop is not an issue.

0 Kudos
Message 4 of 8
(3,644 Views)

If you're just trying to see if it's responding, why don't you throw a small application on the PXIe chassis?  You can use shared variables or any of the other communication means to pass messages between the two devices.  If it's running VxWorks, you can run a RT application on it.

0 Kudos
Message 5 of 8
(3,622 Views)

Interesting thought... I'm not sure how I would do that without affecting the other application running on that system.  It's a very specialized hard real time application which may not cooperate with a labview application on the same controller and trying to use the same network interface.  I doubt I could get the engineers who designed it to agree to this type of alteration in their architecture.  I'd rather just get icmp pings working from the pharlap pxie controller like it should already be able to support via a native vi or getting winsock to work.

0 Kudos
Message 6 of 8
(3,601 Views)

A ping isn't a very smart response.  It's just a response.  You only care about it in some moments.

 

Make a SV called Ping.  In your app, set it true.  In the PXIe chassis, have an independent loop do nothing but check that SV and set it false if it's true.  It's a loop that won't interfere with the rest of the application.  When it receives a request, it responds.  It'll take minimal effort to add it to the project they already have running. 

 

If the Ping VI isn't working, this is an easy way to replicate the behavior isn't it? 

0 Kudos
Message 7 of 8
(3,595 Views)

I'll have to look into how I would go about creating a vxworks app from labview.  Trust me though, this vxworks Sbc is highly tuned and not under my direct control, hence the desire to ping in a normal fashion.  Thanks.

0 Kudos
Message 8 of 8
(3,574 Views)