second call to read tcpip is slow

[Jim12345678]

I have an problem I've never seen before.  I am communicating to two identical instruments each with their own IP address.  I wrote a program that sends a command to request information using the write tcpip function.   Then I read the response using the read tcpip function.   Since I have two machines, I just loop through the same code twice using the different IP addresses.  If I run the code for just one machine, it responds almost instantly.  If I run the code for the other, it too responds almost instantly. If I change the order, it doesn't matter.  Each machine responds.  However, if I run the loop that calls each, the second read tcpip function takes 10s of seconds to execute.  Doesn't matter the order I call the machines; it's always the second iteration through the loop that gets bogged down.  The second call works. I eventually get the response and the data is correct.  It's running on a closed local network through a switch.  I've tried power cycling the switch, but that didn't help.  Any ideas?

I attached a picture of the two function: one to issue the tcpip command and one to read the response.  It's just a snapshot of the two calls. I cut out the surrounding code that ensures the order of execution.  The surrounding code all appears to work fine.  It's not the loop that's getting bogged down between calls.  The slow down isn't between the the two calls.  It's the in the second call to read tcpip.  Again, if I just act on one machine, it responds instantly.  It's only the second call that gets bogged down.

[Eric1977]

Instead of a picture, can you upload your actual VI?

[Jim12345678]

See attached. Yes, I use stacked frames.

[Eric1977]

While I can't speak the TCPIP portion (I've never used them), I can speak to the stacked sequence structures. Don't use them. There is a place to use them, but this is not one of them.

Instead, look into the Simple State Machine template. Once you get your TCPIP issues resolved, I think you have a solid foundation for that.

[pincpanter]

I only see one TCP connection reference in your vi. So you are using Get_Temperature.vi two times in another vi?

I think you should post the calling vi because we already know that Get_Temperature.vi works if called once.

Apart from this, as already suggested by Eric, your vi is badly structured and could be greatly improved. You are unnecessarily overusing not only stacked sequences (frame 0 of the main sequence, for example, is totally useless since it contains no code), but also local variables. For example, the TCP connection reference is never changed, so you can extract it from the input cluster and wire it to all your TCP calls. Don't let you be scared by wires!

[billko]

---

@Eric1977 wrote:

While I can't speak the TCPIP portion (I've never used them), I can speak to the stacked sequence structures. Don't use them. There is a place to use them, but this is not one of them.

Instead, look into the Simple State Machine template. Once you get your TCPIP issues resolved, I think you have a solid foundation for that.

---

Curious as to when you think you should use the SSS?  It's so discouraged that it was deprecated long ago.  Were you just thinking the vanilla sequence structure?

[Eric1977]

---

@billko wrote:

---

---

Curious as to when you think you should use the SSS?  It's so discouraged that it was deprecated long ago.  Were you just thinking the vanilla sequence structure?

---

Yes, that seemed pretty simple and a good fit for what the user was trying to accomplish. Perhaps the OP has a bigger project, and this was just an example which I had not considered.

This is my own personal feelings & preferences on the subject, but it has its uses and can be a solution for some programs, especially if users want to get into some Producer/Consumer architecture using Queues and aren't ready for channel wires. I am one of those users who still likes Queues; probably because I am used to them and am unwilling to change. 😂

Curious - when was that deprecated & why is it discouraged?

[altenbach]

Your code is a jumble of stacked sequences inside stacked sequences, all controls and indicators disconnected and their terminals placed inside an otherwise empty sequence frame, and all data bounced around via local variables (In the past we labeled this as suffering from localitis and sequenceitis, a serious health condition!). If this is your programming style, all bets are off! Even the choice of connector pane is unreasonable.

We are also missing typedefs and subVIs. 

That said, this is a subVI and the IP address does not change during execution, so if you are calling it with two different IP addresses in succession (apparently needed to reproduce the problem!), we would need to see the caller, especially how you establish the connection ID and manage the connections in general, etc.

Do you get any errors (e.g. timeout, etc.).

[altenbach]

---

@Eric1977 wrote:
Curious - when was that deprecated & why is it discouraged?

---

Start reading here and follow the links. 😄

(Not sure how queues and channel wires fit into the discussion of stacked sequences)

[Eric1977]

My fault. I assumed the Simple State Machine was being discouraged. 😑 

I agree that the Stacked Sequence Structure should not be used but for a VERY short set of use cases, and, even then, look like they can be substituted for better alternatives based on the links you provided.