What can cause a UDP Connection ID to Stop Working?

[StoneTrees]

Nope, I've run it both as a standalone VI and incorporated into the top level VI and in all cases, there was never an input error.

[PhillipBrooks]

I think I would try placing the CHIP Host and CHIP Port values in shift registers rather than using property nodes. 

[StoneTrees]

Yeah, that's better stylistically, but since the CHIP port and host aren't used by the Read case, I don't think it'll affect things.  Thanks for the feedback.

[tst]

Since the stripped down version doesn't work either, I suggest you upload that with an exact explanation of how you run it so that we have a common baseline. Consider using Jing or something similar to record a video of what you're doing.

Since you say you don't call the disconnect case, I would still go with my previous guess, since that's the most likely source for error 1, maybe even the only possible source.

I would also highly recommend moving the control and indicator terminals to the outer layer. For controls, this may mainly be a performance enhancement, but for indicators you get a different behavior when they're inside structures and that behavior is non-intuitive and confusing.

And I would again suggest considering checking the error and calling the init case again if there is one. That would require that you keep the other values in SRs as well.

[B2.718]

Hi,

I realize this post is a few months old, but I know why your VI doesn't work. Its because the while loop only executes once. You are assuming that the connection ID is static, but in LabView this is just not the case. The connection ID can only be held throughout a single code execution. Every code execution you get a new ID.  Therefore, you must open the port, read, then close the port in one execution.

You could change your while loop to have a shift register output that takes you from init to read then to close so the port would be active for 3 iterations that way the connection ID would be constant for those three iterations.

Been having the same issue for the last few days so I thought I'd chime in, albeit late.

Hope this makes sense,

Brent

[nathand]

---

B2.718 wrote:

Hope this makes sense,

---

Sorry, but no, it doesn't. 

If by "code execution" you mean pushing the "Run" arrow, then yes, every time your code stops it will close all connections, and using the Run Continuously button falls in that category too.  If you need code to run repeatedly, use a while loop, not Run Continuously.

You can keep a UDP socket open and reuse it between calls to a subVI within one run of the top-level VI.  You should NOT constantly close and reopen connections if you plan to reuse them.  Sounds to me like you're doing something wrong in your code if you think this is necessary, and if you upload your code I'd be happy to help you with it (unless it's the use of Run Continuously, as already explained).

[B2.718]

I cannot use a while loop because if I use a loop then the outputs of the VI will not update the Veristand FIFOs until the loop ends. (I am using Veristand by the way)

I need to make separate calls to a code that can execute once and update its output. Therefore, like the VI in the beginning of this post that has a while loop which executes once (stop always true) the connection ID will not stay constant and must be recreated during each call to the code. I have tried using a global variable to store the connection ID, but that didn't seem to work.

I thought that like a serial port I could grab a connection ID and type cast it as a constant but this doesn't seem to work. This is the implementation I have uploaded.

I would like to call the code at a 1kHz rate during which time the entire code executes. I would be grateful if you were able to tell me how to store the connection ID during separate calls to the code.

[nathand]

Your implementation doesn't make a lot of sense.  What do you mean by "type cast as a constant"?  You're typecasting to a string, but I can't imagine why.  A network socket is not like a serial port.  What happens if you remove the type casts and leave the left side of the shift register unwired from outside the loop?  In normal LabVIEW that will work.

I haven't used Veristand, and I don't know how it works.  If it calls a VI and waits until execution terminates, then it may be like hitting the run arrow once per call, in which case LabVIEW will clean up open references (network sockets, file handles, etc) when the VI terminates and you'll need to do the open-read-close sequence within a single call.  If this is the case, my apologies for being too quick to criticize your initial comments.  The original poster said nothing about using Veristand or anything else outside standard LabVIEW.

[B2.718]

I was only typecasting to a string to see what the refnum looked like. I just wanted to be able to put a constant connection ID into the shift register since yes making a call to the model in Veristand is like hitting the arrow once.

[B2.718]

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.