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

[billko]

---

@Mark_Yedinak wrote:

---

@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.

---

Often, yes, but not if, say, all you want to do is read the contents of a config file into a global so your code can use it in different spots.

[Mark_Yedinak]

---

@billko wrote:

---

@Mark_Yedinak wrote:

---

@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.

---

Often, yes, but not if, say, all you want to do is read the contents of a config file into a global so your code can use it in different spots.

---

I agree, which is why I made note of the WORM variables above. Though I still prefer not using them as a general rule. the two cases where I would make the exception are for WORM variables (just like the case you mentioned) and in UIrelated code. Local variables are actually faster updates to controls/indictators than using property nodes. Granted you still may need property nodes to manage your UI but simple updates you can get by using local variables.

[JensG69]

Let's get back to the problem of the OP. We all agree that a race condition is the origin of the failure of the example VI.

But that only seems to be a test of a set-up of VIs used in Teststand.

Quote:

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.

[billko]

---

@jg69 wrote:

Let's get back to the problem of the OP. We all agree that a race condition is the origin of the failure of the example VI.

But that only seems to be a test of a set-up of VIs used in Teststand.

Quote:

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.

---

I admit that I didn't see that part of the post.  Why not save it as a TestStand parameter then?  Make a VI to open the connection, then pass it out of the VI and into a TestStand parameter?  I'm not particularly good with TestStand, but that's what I would do.

[stephenb2]

My thoughts exactly Bill, but saving the connection ID to a TestStand local variable of type number (avoiding LV globals, which I can see no reason to use) is not working. The attached sequence fails on the tcp-ip read labview step.

What does work is doing all the TCP-IP steps (open, read/write, close) in the same step for every step that needs a telnet command sent to my DUT.

[JÞB · Accepted solution]

Funny thing about tcp sessions

They cannot exist when all vi's in the application instance go idle (LabVIEW Garbage collection tosses them out)  So, even if you write it to a global vi, the reference will go invalid when all vi's that need it go idle.  (Sucks don't it)  

But, you do know the Address!  so (Ruffles and flourishes please....) 

Create a TCP/IP Raw socket

Give it a nice easy alias like "MySocket"

And store the VISA Alias in the sequence locals and just use VISA

(Yeah, VISA Sessions are cool like that, they stick around as long as the vi that needs them is in memory...Caveat: don't unload the VISA open module untill you want the resource gone)

[stephenb2]

Thanks, it works if I specify the telnet session as a visa session.

It appears that I don't need to create a raw socket in NI Max as long as I pass in the 'IP address' identifier in explicitly, as (in my case) "TCPIP0::169.254.1.1::23::SOCKET".

The odd thing is that passing the TCP-IP connection ID used to work, but after upgrading (from LV 2013 to SP1+patch, and perhaps visa to 16.0), it stopped.

[JÞB]

You just have too love the emoji preferences  "OCKET" 

[stephenb2]

I spoke a little too soon. I can open and pass references to the telnet session, but a VISA read is not clearing the buffer. A VISA clear does not as well. So for every command I send, I get the results of that command appended to the history of the entire session.

Anyone know what might be going on?

[JÞB]

OK, Why do you call it a telnet session?  What is the remote device?