What can cause a UDP Connection ID to Stop Working?

[Mark_Yedinak]

I am not familiar with VeriStand but if possible you could have a step in VeriStand that opens the connection and stores the UDP reference. On the following steps you would pass in the reference to the VI which would perform your UDP read/write operation. At the end of teh sequence you would have another step that would close the UDP reference.

[nathand]

---

@B2.718 wrote:

I was only typecasting to a string to see what the refnum looked like.

---

A refnum is a wrapper around an integer, so probably better to typecast to an integer.

---

@B2.718 wrote:

Got it, had to build a custom device for Veristand which contains a timed loop, then I stored my connection ID in a shift register.  I still think that you should be able to create a constant connection ID, but maybe that's just my inexperience with UDP/LabView.

---

Is the timed loop in Veristand, or in LabVIEW?  Again, I haven't used Veristand, but if it's in LabVIEW I'd be curious why a timed loop is necessary versus a standard while loop.

A network socket is very different than a COM port.  A COM port is a physical piece of hardware that's been part of a PC for years - I'd guess that for compatibility it can still be accessed through a hard-wired memory address although I don't know enough to be certain - so you can have a constant reference to it.  A network socket is a software construct; it doesn't exist until you create it and ceases to exist when it is closed.

[B2.718]

VeriStand runs the VIs which are compiled to .lvmodels or custom devices (or .dlls if they are MatLab) so its all inside VeriStand, but built elsewhere.

The key that fixed it was that .lvmodel's  and custom devices work a little differently in VeriStand. A while loop would probably work just as well inside a custom device, but since I have a required sample rate a timed loop works better for me.

I know a network socket is software, but isn't the socket defined by the address, port and protocol? This would imply that the connection ID should be a constant if all of these things are constant, but it changes. 

[Mark_Yedinak]

No, a socket is defined by the source IP, source port, destination IP and destination port. So everytime you open a socket you get a new pair. You normally don't give a source port to the open and so the OS assigns a random value. The reference you get back from open refers to a specific pair or source and destination IP addresses and ports.

[nathand]

---

B2.718 wrote:

I know a network socket is software, but isn't the socket defined by the address, port and protocol? This would imply that the connection ID should be a constant if all of these things are constant, but it changes. 

---

A better analogy is a file.  You can have a path constant that uniquely identifies the file, but you still need to open the file to get access to it.  When you open a file, the operating system returns a file handle - an integer that is temporarily assigned as a reference to that file.  Same thing with network sockets.