10-18-2012 04:47 PM
I am currently setting up a UDP connection for a control system. I was hoping to get a little more access to the socket itself and was wondering why I cannot seem to access the system.net.sockets in the constructor node. I only seem to have PeertoPeer options and IPEndPointCollection.
I have allowed LabView to use Framework 4.0 (even though system.net.sockets is available in 3.5 and below) using http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/configuring_clr_version/ which worked nicely, but did not solve my problem.
I found this example that allowed me to set the buffer size
but cannot look under the mask for the "UDP get raw net object" VI as it is password protected.
Any help, including telling me LabView does not support this .net would be useful.
Solved! Go to Solution.
10-18-2012 04:50 PM
Any reason you are not using LabVIEW's own UDP functions?
10-18-2012 04:57 PM
Yes, I am trying to interface with a controller that uses Veristand and when I send an I32 from my controller which uses Veristand I recieve 6 bytes. This is strange to me especially since an I32 is not 6bytes long and a packet should be minimum size of 8bytes+data. So I would like to know more of what is going on and the LabView options of Open, Read, Write, Close do not give me the visability that I would like.
10-18-2012 05:03 PM
Can you post your LabVIEW code. There is no magic that the LabVIEW UDP VIs are doing. They do not alter or modify the data you send. Therefore your LabVIEW code was formating the data incorrectly. The LabVIEW UDP VIs work quite well. I have used them to implement the SNMP protocol and have successfully communicated with multiple devices from different manufactures using it.
10-19-2012 01:24 AM - edited 10-19-2012 01:26 AM
I have to echo Mark's comments. The LabVIEW UDP VIs work fine for me and are in fact only a thin wrapper around the BSD socket functions readfrom(). The only reason to try to go directly to the socket API is if you need to change properties of a socket which is seldom necessary.
Also there is no need to have a look in the UDP Get Raw Socket.vi. It simply returns the underlaying "socket" handle of a LabVIEW network refnum. This is a handle so a 32 bit value under Windows 32 Bit and a 64 Bit value under Window 64 Bit. You can pass this handle to any WinSock API function that accepts a socket handle to access it's properties and such.
UDP is a connectionless network protocol so you do not have the same safety net as with TCP. If your sender sends for instance a header and then a data frame in two different data junks it can depend on the timing (and the read parameters as "bytes to read") of your reader if you will see this as two packets or one. So you have to be a little careful and think about reliable protocol handling yourself. But that has nothing to do with if you use the LabVIEW UDP functions or the .Net equivalent.
10-19-2012 11:10 AM
I was able to resolve the extra 2 bytes by sending a packet of 512 bytes. I am using a gigabit ethernet connection.
I'm still trying to figure out how to access the system.net.sockets in the constructor node. I would like to, for instance, verify the header information (IPPacketInformation structure?), set properties such as DontFragment, and modify other socket properties to emulate my target embedded enviroment.
10-22-2012 05:57 PM
My name is Humphrey and I am an Applications Engineer at NI. I am trying to look into this to see if LabVIEW allows access to the UDP socket properties. At the moment, I don't know if LabVIEW supports this but I will take a further look into this. In the meantime, will something along the nature of what is discussed here work? I'm not very familiar with .NET so I'm not entirely sure if it is applicable.
10-22-2012 06:36 PM - edited 10-22-2012 06:38 PM
Got it figured out!
The System.Net.Sockets doesn't live in the hierarchy that I was looking. I was looking in System.Net-> to sockets. But the correct path is
On an aside, thanks Humphrey for pointing out that you can add things to the .Net list. See link above. This inspired me to look in a separate hierarchy.
And a thanks to Rolf for pointing out that if you use the UDP Get Raw Socket.vi you can use all of the functions that winsock32.dll provides. I'm still a bit new to LabView and did not even know how to access other dlls that were not part of the .Net API so thats a great bit of knowledge.
Kudos to you both