Jump to content

Recommended Posts

Hello everyone,

My project:

We have 2 PXI-RT communicated by 2 connections: a fiber optics connection (not Ethernet), and an Ethernet connection. The FO connection is the main connection used to wsend a receive data. The Ethernet connection is only use when the FO connection is lost, in order to check if the "mute PXI" has lost the FO connection but is still on, or if the PXI has been switched off.

The problem:

Originally we used the "RT Ping controllers.vi" on the "Real-Time Utilities", but unluckily we changed the PXI controller and the new one is not supported by the library.

The main issue is the application was developed using LV7.1 and cannot be upgraded.

Options already disscarted:

We tried opening a TCP connection, but the operation takes too long.

I found this great VI, but its for LV2010. I tried it and it works perfectly. (http://forums.ni.com...er/td-p/1535420)

I tried translating it to LV7.1, but something is wrong, because LV closes as soon as I play Run :(

Have any of you worked using wsock32.dll on a PXI?

Best regards,

g_l_u_p

ping_PharLap_LV711.vi

Link to post
Share on other sites

Just found out why my VI was closing LabVIEW. The first "Call Library Function" was using "Calling Conventions = C" instead of "stdcall (WINAPI)". :frusty:

Now, the VI doesn't close LV, but timesout on the call to function "select" (befor the "recvfrom"). It actually behaves the same running on my PC or on PXI-RT.

Could anyone have an idea :lightbulb: ?

Thanks again

g_l_u_p

ping_PharLap_LV711.vi

Edited by g_l_u_p
Link to post
Share on other sites
  • 1 month later...

Could you implement a UDP heartbeat instead? Have the mute controller send hb to a port on the other controller. If it times out waiting for it then the other controller is off/down. This would be a typical alternative to ping and confirms not only that the controller is on but that it is running.

(null)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By John Lokanis
      I am running into an issue where my VI Server connection goes stale after a few hours.  Looking for a fast way to detect this and recover.
      Currently here is what I am doing:
      On first call, open the application reference and then open the VI reference.  Cache both of these.  Use the VI reference to call the remote VI. On subsequent calls, test the cached references to verify they are still valid and then call the remote VI. What appears to be happening is the references still appear to be valid in the caller but the connection is broken so the remote call fails.  Then I detect this and reopen the app and VI refs and can again call the remote VI.
      The issues are:
      The failing remote call takes a long time to timeout and I do not see how to control this timeout. The test of the refs does not actually test to see of the network connection is still good. The result is it takes a long time to recover and this is upsetting the user since it appears the system is locked up.
      What I need is a way to control the timeout of the 'call by reference' node or a way to quickly test the references to verify the network connection is still good before I attempt the remote call.
      Any ideas?
      thanks,
      -John
    • By Gan Uesli Starling
      Attached is my VI for writing a tiny HTML file to a intranet network directory. This is on Windows for writing to a file path like \\foo\bar\wtf.html (fictional!). But when the network is slow (quite often) the file write will fail.
       
      I've got a patch in there so survive the error and just wait till next time. But what really I need is a way to tell the write to hang in there longer and not give up just because there's no reply yet.
       
      My temporary work-around is to open a Windows file browser to that path, the twiddle my thumbs until the file list populates. Then, the path being established, I may safely start the parent VI of which this VI is a sub.
       
      Any ideas?
      Write_HTML.vi
    • By Novgorod
      Hi,
       
      I'm wondering whether there is a way to monitor the SVE (or single processes/variables) on a per-client basis. The purpose of this would be network diagnostics or access control. I know the DSC module allows logging of data and events for shared variables, such as the very handy "value changed" event, but they contain no client-related information (to my knowledge), such as the client name or IP address. Are there any other shared variable events besides the value changed notification (e.g. "variable accessed"), which I have missed?
       
      Anyway, the SVE seems to be aware of clients, because it allows some access control through the DSC module (and with a bit of hacking even programmatically). You can define access control lists based on computer name or IP address, which is very buggy, but it works somewhat. Is it possible to somehow access this client information (number of clients, names/addresses and activities) from the SVE? I don't see any tools for that, but maybe there is an underlying API through DLL calls or whatever?
    • By ShaunR
      Name: Transport.lvlib
      Submitter: ShaunR
      Submitted: 27 Aug 2011
      Category: Remote Control, Monitoring and the Internet
      LabVIEW Version: 2009License Type: Other (included with download)



      Transport.lvlib is a LabView API to simplify and accelerate networked communication development.
      It simplifies development by abstracting TCPIP, UDP and Bluetooth and TLS interfaces
      into a single polymorphic vi which is a thin wrapper around the conventional
      open, read, write, close and listener VIs for all the network interfaces.
       
      Features:
      Supports TCP/IP, Bluetooth, UDP (p2p, broadcast and multicast) and TLS.
      Supports symetric encryption (blowfish).
      Supports compression (zlib).
       
      INSTALLATION:
      Run the supplied installer and follow the instructions.

      Click here to download this file
    • By John Lokanis
      I need to find a transport for message objects that allows two way communication without polling but is limited to server side connections only.  So, the client can connect to the server but the server cannot connect to the client.
      First some context:  My application communicates over the network using VI Server.  My client app (the UI) opens a ref to a VI in my server app (the engine) and sends a message object containing the client app’s machine name and VI server port.  The server app then opens a ref to a VI in my client and sends a message object with the reply data.  I now have a two way communication channel via VI server and can pass any message object back and forth without polling.
      I learned today that our IT department plans to block all incoming connections to all non-server machines in the future.  So, my client would still be able to connect to the server app within the network, but the server would not be able to connect to the client app because of this rule.  This will completely break my networked messaging system.  I do not know a way for LabVIEW to setup VI Server so only one end can connect to the other but allow two way communication without polling.
       
      Does anyone use a message system that would work in my situation?  I would prefer to continue to use VI Server but I am willing to look at other solutions, as long as they were very robust and had low latency.
       
      thanks in advance for you help.
       
      -John
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.