TCP-IP connection ID doesn't work after being assigned to a global

[stephenb2]

Can someone help me understand why the following does not work? A direct connection of the connection ID works fine.

The error is "TCP Read in tcpip test open and read combined using global.vi".

My goal was to open a telnet session and use the connection ID throughout my testing in various VIs called as TestStand steps, and finally close it once the testing is done.

[JensG69]

Classic case of a race condition!!!

The reading of the global variable has no data-flow dependency to the writing/setting of that global variable. LabVIEW will run everything it can in parallel hence the global variable is already read out at the beginning of your code - in parallel to the "TCP open connection", before a new value gets set.

Regards, Jens

[stephenb2]

So what is the best strategy to adopt? Should I open and close a telnet session every time I want to send a telnet command?

[JensG69]

Should I open and close a telnet session every time I want to send a telnet command?

NO!!

So what is the best strategy to adopt?

Respect the dataflow-paradigm of LabVIEW and make sure, that the global variable gets read only after it was written.

For your screenshot, a flat sequence would solve the problem:

Regards, Jens

[Mark_Yedinak]

Why are you using a global variable in the first place. Directly wire the TCP reference. I try to avoid using local or global variables as much as I can. Exceptions are what are called WORM (Write Once Read Many) variables. However, there is no reason that your code snippet above needs to use variables.

In fact, you don't really need to use the delay between the write and the read either. Simply incorporate the extra time in your read timeout value.

[billko]

---

@Mark_Yedinak wrote:

Why are you using a global variable in the first place. Directly wire the TCP reference. I try to avoid using local or global variables as much as I can. Exceptions are what are called WORM (Write Once Read Many) variables. However, there is no reason that your code snippet above needs to use variables.

In fact, you don't really need to use the delay between the write and the read either. Simply incorporate the extra time in your read timeout value.

---

The zip file had the original in it that was directly wired.  I believe he is trying to scale this thing beyond this VI.

[billko]

---

@jg69 wrote:

Should I open and close a telnet session every time I want to send a telnet command?

NO!!

So what is the best strategy to adopt?

Respect the dataflow-paradigm of LabVIEW and make sure, that the global variable gets read only after it was written.

For your screenshot, a flat sequence would solve the problem:

Regards, Jens

---

Let's not teach bad habits - i.e., using sequence structures when they aren't really needed.  Provided that you aren't going to use this connection any more in this VI, there's nothing wrong with this:

IF, of course, this VI runs before any other VI which relies on that global.

[stephenb2]

The reason a global was used is because I inherited it from older code. The global would be set in one TestStand step, and then a later step would use the global to continue the persistent telnet session.

[Mark_Yedinak]

---

@billko wrote:

---

@Mark_Yedinak wrote:

Why are you using a global variable in the first place. Directly wire the TCP reference. I try to avoid using local or global variables as much as I can. Exceptions are what are called WORM (Write Once Read Many) variables. However, there is no reason that your code snippet above needs to use variables.

In fact, you don't really need to use the delay between the write and the read either. Simply incorporate the extra time in your read timeout value.

---

The zip file had the original in it that was directly wired.  I believe he is trying to scale this thing beyond this VI.

---

I would still look serious at variable usage. I rarely ever find a need to use them and I work on VERY large systems. Our current system uses over 125 packed project libraries with hundreds of classes. Variable usage is often a sign of a poor design.

[JensG69]

I admit my example is bad LabVIEW coding. I just wanted to explain the race condition in more detail. Think of the sequence as a representation of different subVIs.

Regards, Jens