Jump to content

Recommended Posts

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.


 


post-53076-0-37069000-1442942895.png


 


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


 


post-53076-0-00572400-1442942857.png


.


 


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!


Link to post
Share on other sites

The net address is for the address of your network card and usually only used if you have multiple cards installed in the system so you can bind to a particular card.

 

You have quite a stack of network virtualisation there.You'll probably have to set up routing to forward  UDP multicast packets from your router.

Link to post
Share on other sites

You meant this: route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 ?

 

Well. Seeing as your multicast address starts with 235, I would say probably not. However, I avoid Linux whenever possible so I cannot help much further than saying what the net address is for because it will depend on how you set up the network cards and firewalls in all the layers (including Windows).

Edited by ShaunR
Link to post
Share on other sites

I quote from here :

 

  • "This will add the static route for all packets arriving from the possible UDP multicast address range (224.0.0.0 through 239.255.255.255). To make the changes persist through rebooting the device, you can either write a script to run this command on device initialization or manually add the rule to the network interface configuration file in /etc/network/interface."

Why do you say it won't work for an address that starts with 235?

Edited by Calorified
Link to post
Share on other sites

It's a bit lame but what I ended up doing was to receive the multicast on the Windows Virtual box, create a second ordinary udp broadcast to the RIO and receive the udp broadcast on RIO. Still no noticeable delay. 

 

Someone in my lab told me I could have used a shared variable engine to move the data around from my PC to RIO target. I tried this unsuccessfully with the 'Single-Process Shared Variable' as well as 'NI-PSP Shared Variable'.

 

Maybe if someone has a way out, they could further shed some light on the shared variable host send and target receive.

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 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 OlivierL
      ShaunR's recent topic on Security reminded me of a situation we explored in the summer and need to revisit at some point. We were looking for a method to protect the communication with a cRIO.
       
      The situation is that we need to communicate between a cRIO and a host on an unsecured network (manufacturing environment.) We concluded that we needed some form of encryption as well as a standard login mechanism but identified that having a single symmetrical key would not provide enough protection (for various reasons and specific use cases.)
       
      Therefore, we looked into SSL and LabVIEW Web Services because it already includes that library and all the security features that we need. We figured out that it would definitely offer the protection required but that would mean rewriting most of existing code to use Web Service instead or establish some for of communication through a new Web Service. Considering the amount of unknown and risks associated with modifying our code, we looked into an alternative and came up with the following scheme:
       

       
      In short, we would use a Web Service for the initial login and create a new symmetrical key which would be passed to the host and to the main application on the target (cRIO) and would be used to encrypt/decrypt all data during the session. This way, we could still program all of our code in LabVIEW and easily download/deploy the services and applications to the Target using NI standard tools but benefit from proper security and only have to add fairly simple wrappers to some sections of our existing code.
       
      I wonder if anyone else has already gone down that route to add protection to an existing application. Would you suggest a different implementation method or an easier path to a similar result? Is there some obvious pitfalls in this approach that we do not see?
    • By Calorified
      I have a UDP connection setup on a Windows 7 machine that runs an IMAQ code. The machine can send and receive udp connection so long as data being sent it is on the same machine. When I send the code from a different process (running on Windows 7), I am able to read the data on the RIO udp receiver VI (running on the Windows Host) as well.
      So I changed the sending program to a labview code and the udp receiver won't pick up the data.
      Could there be something I am missing?
      Attached are the PNG files (lava1 is the talker (same as the Kinect Code VI) while lava2 is the receiver).
      Any clues would be appreciated.


      Kinect Code.vi
    • 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 hilbert00
      Dear LabVIEW friends, 
       
        I'm running into a problem distribution my application. This is opening a UDP connection registering a service as explained in the documentation. It is perfectly working when running within the development system and also as a standalone application on the development computer. 
       
      The problem is with the installer and the distribution package. When I install the application of a different computer, it fails with error 63 at the Open UDP. Reading the available documentation it looks like it is a Service Locator fault. So I checked and indeed the NI Service Locator is not running on that machine and it is not even distributed with the installer. 
       
      I've tried to go through the list of additional installers in the Installer build properties but couldn't find anything useful. 
       
      I'm sure I'm doing badly something wrong, can you help me in sorting this out?
       
      Cheers,
      toto
×
×
  • Create New...

Important Information

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