LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Same Old Issues with UDP Multicast Running on RT Device

Hi all, 

 

firstly I named this topic Same Old Issues with UDP Multicast Running on RT Device because the issues I am experiencing with running UDP multicast fucntions on an RT device are the same issues I've seen reported by another user back in 2015

https://forums.ni.com/t5/LabVIEW/UDP-Normal-and-Multicast-Not-working-on-Linux-RT-based-NI-RT/td-p/3...

however with my current issue being along the same lines as the issue reported here the fix offered up by the threads author still does not give me a functional UDP multicaster, I am using the same device as in the thread, an sbRIO-9636, which is what lead me to the thread, out of shear luck and a last ditch effort to find some usefull information regarding the issue I am experiencing. 

Reading the above thread the authors frustration is immeadiately apparent and ya know what, its extremly relatable, when the example given by LabView doesnt even work then what are you supposed to do except waste time banging your head against a wall trying to get what is a simple task in other languages to work.

Getting to the crux of the issue what I am trying to achieve is to set up a UDP multicaster write only sender on the sbRio that any number of seperate applications/devices on the same network can recieve, sounds simple right? Given thats theres a built in function for that! Well to my boss and client it apparently is but in practice this has been a nightmare, allocate a day or two to get it done and a week later its still not finished and doesnt look to good on me or LabView for that matter 

So following the above thread the first issue I was experiencing was the same as the author experienced on page 3 where he set up the sender on the RT and recieved the error 59, this was resolved by following the authors solution and wiring the devices IP address to Net Address input of the multicast open write only vi, which did get rid of the error but my reciever on my host PC is not recieving the sent messages.  Also I am not able to set up a multicaster read only session the device and get the same error 54 as seen on page 2 of the thread 

 

I am using static IP's, firewalls are completely disabled and everything is on a private network we have a ethernet hub, connected to it is the sbRio, an RT PC (PharLap OS with an idle VeriStand engine on it), a PC and a Laptop. 

 

I have tried LabViews UDP Multicast example and the thread authors example code but to no avail and like the threads author I have managed to get single and multiple regular UDP streams workingwithout much hassel.  I also wasted time coming up with a work around but we'll not talk about that, needless to say it not ideal and doesnt work so we really need to get multicast operational

Any insight available as to how to get my host PC recieving UDP packets from the sbRio would be very much appreciated, also we are only using the sbRio as a test board and will need to migrate this to a cRio once finished  

ecleary42_0-1616465750378.png

 

 

ecleary42_1-1616465809051.png

 

ecleary42_2-1616465934424.png

ecleary42_3-1616466879899.png

 

0 Kudos
Message 1 of 3
(826 Views)

Hi all, 

 

firstly I named this topic Same Old Issues with UDP Multicast Running on RT Device because the issues I am experiencing with running UDP multicast fucntions on an RT device are the same issues I've seen reported by another user back in 2015

https://forums.ni.com/t5/LabVIEW/UDP-Normal-and-Multicast-Not-working-on-Linux-RT-based-NI-RT/td-p/3...

however with my current issue being along the same lines as the issue reported here the fix offered up by the threads author still does not give me a functional UDP multicaster, I am using the same device as in the thread, an sbRIO-9636, which is what lead me to the thread, out of shear luck and a last ditch effort to find some usefull information regarding the issue I am experiencing. 

Reading the above thread the authors frustration is immeadiately apparent and ya know what, its extremly relatable, when the example given by LabView doesnt even work then what are you supposed to do except waste time banging your head against a wall trying to get what is a simple task in other languages to work.

Getting to the crux of the issue what I am trying to achieve is to set up a UDP multicaster write only sender on the sbRio that any number of seperate applications/devices on the same network can recieve, sounds simple right? Given thats theres a built in function for that! Well to my boss and client it apparently is but in practice this has been a nightmare, allocate a day or two to get it done and a week later its still not finished and doesnt look to good on me or LabView for that matter 

So following the above thread the first issue I was experiencing was the same as the author experienced on page 3 where he set up the sender on the RT and recieved the error 59, this was resolved by following the authors solution and wiring the devices IP address to Net Address input of the multicast open write only vi, which did get rid of the error but my reciever on my host PC is not recieving the sent messages.  Also I am not able to set up a multicaster read only session the device and get the same error 54 as seen on page 2 of the thread 

 

I am using static IP's, firewalls are completely disabled and everything is on a private network we have a ethernet hub, connected to it is the sbRio, an RT PC (PharLap OS with an idle VeriStand engine on it), a PC and a Laptop. 

 

I have tried LabViews UDP Multicast example and the thread authors example code but to no avail and like the threads author I have managed to get single and multiple regular UDP streams workingwithout much hassel.  I also wasted time coming up with a work around but we'll not talk about that, needless to say it not ideal and doesnt work so we really need to get multicast operational

Any insight available as to how to get my host PC recieving UDP packets from the sbRio would be very much appreciated, also we are only using the sbRio as a test board and will need to migrate this to a cRio once finished  

ecleary42_0-1616465750378.png

 

 

ecleary42_1-1616465809051.png

 

ecleary42_2-1616465934424.png

ecleary42_3-1616466879899.png

 

0 Kudos
Message 2 of 3
(825 Views)

This device is running VxWorks as OS and there are known issues with UDP support and especially multicast operation on that OS. Unfortunately VxWorks is a third party provided OS for NI and they have very limited possibilities to change the functionality of the OS components itself. Quite possible that upgrading to a newer VxWorks version would have solved that (all LabVIEW versions since 8.5 use VxWorks 6.3) but that is a passed station since NI has standardized in 2014 on their NI Linux RT as OS for all newly designed real-time hardware with the exception of some PXI controllers. As of LabVIEW 2021 all but NI Linux RT will be unsupported for embedded devices and LabVIEW 2022 will also remove support for Pharlap ETS based PXI controllers.

 

Basically if you plan to use another cRIO controller anyways, it would make more sense to try to use a NI Linux RT based controller for your testing. Because that is the only type of cRIO controller you will be able to buy after end of this year anyways. NI has announced a last buy statement for all non-NI Linux based real-time cRIO controllers and even some of the earlier NI Linux RT based controllers are being phased out.

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 3
(767 Views)