Jump to content

Recommended Posts

index.php?app=downloads&module=display&section=screenshot&id=196

Name: Transport.lvlib

Submitter: ShaunR

Submitted: 27 Aug 2011

Category: Remote Control, Monitoring and the Internet

LabVIEW Version: 2009

License 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

  • Like 2

Share this post


Link to post
Share on other sites

Maybe you can rename it to just plain "Transport".

Well. It's not a different product, just a different version. I was kinda hoping the old one wasn't deleted permanently and it could be merged back in. would renaming mean that this would be possible?

Share this post


Link to post
Share on other sites

Version 2.0.0.0 released. Now includes a proper installer and palettes.

Edited by ShaunR
  • Like 1

Share this post


Link to post
Share on other sites
On ‎1‎/‎13‎/‎2015 at 0:19 PM, ShaunR said:

Version 2.0.0.0 released. Now includes a proper installer and palettes.

The link be lost! where can be download

Share this post


Link to post
Share on other sites
4 hours ago, ice110 said:

The link be lost! where can be download

It can't. I removed all my <very old> software from LavaG a while ago.

Share this post


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 iayestaran
      Hi everyone,
      I am perceiving some strange behavior in my UDP connections. Every time I re-start my cRIO 9063, the UDP Write block outputs ERROR 66 (LabVIEW:  The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools>>Options>>VI Server on the server side.) and it does not transmit. 
      The most bizarre thing is that if I simply stop the execution and re-launch it again (given that I am executing the code of the cRIO in Debug mode from a Windows laptop), the UDP connection behaves perfectly well. The only time it fails is the first time I launch the program after I reset the cRIO. For me, it looks like some service is not properly initialized when the cRIO is started.
      I attach a picture with the UDP connections of my LabVIEW RT program. The 'Comms RX' VI simply calls the 'UDP Read' function, and the 'Comms TX' calls the 'UDP Write'. The 'Open UDP Conn' also simply calls 'UDP Open'. 
      Can anyone help me?

    • 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 Calorified
      Hi there,

       

      I have RIO in a Windows VirtualBox inside a Ubunbtu Host OS.

       

      I am sending data from a C++ program in the Ubuntu Host system to labview within the Guest OS.

      I can receive the data on labview installed on the windows guest os. Below is the png of the Windows working program.

       



       

      But when I tried to send the data to myRIO, I was getting a udp read only error 42.

       

      Somewhere on the NI forums, someone suggested the net address of the "UDP Multicast Read-Only" vi  be wired to the address of the RIO which I have done below

       



      .

       

      Now, the code runs on myRIO but I can't receive any data on RIO. The multicast address I am sending to from Boost Asio C++ is 235.255.0.1 on port 30001.

       

      The RIO has a public ip of 172.22.11.2 and I set up a static ip address for it in NI MAX as the address of the UDP Multicast : "235.255.0.1.

       

       

       

      At this moment, I do not see what I am missing. All firewalls have been disabled and I have set the permissions for RIO through the Windows security page.

       

      Any help would be appreciated.

      Thank you!

×
×
  • Create New...

Important Information

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