LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is it possible to send TCP Open to multiple units without having to wait for each timeout to expire?

Solved!
Go to solution

Hi all, 

 

I have a system with 20 units that must continuously poll them, described by this pseudo-code

 

while:

{

Unit1:

1. TCP Open command (if connection is already established, goto 3)

2. TCP Read to ensure that connection is established

3. TCP Write to request data

...

Unit20:

1. TCP Open command 

2. TCP Read to ensure that connection is established

3. TCP Write to request data

 

Unit1:

1. TCP Read data if connection is established, else end

...

Unit20:

1. TCP Read data if connection is established, else end

}

 

Say units 5-9 go down, I still have to poll them to see if they come back. Code attempts to TCP Open with timeout of 3 seconds, I now have 15 seconds delay in real time, meaning that I miss on the events that may occur with the remaining operating units 1-4 and 9-20. 

 

If I set timeout for TCP Open to 50-100 milliseconds, this seems to work, but is that a good programming practice, and are there risks associated with that? Are there other solutions? 

0 Kudos
Message 1 of 6
(794 Views)
Solution
Accepted by John32d

Some options below, with decreasing levels of brute force:

 

1. Create a while loop that handles your TCP process to a single unit.  Then, copy/paste that process 19 more times, one for each unit.

 

2. Make that while loop TCP handling process into a preallocated reentrant subVI (VI Properties >> Execution >> preallocated clone reentrant execution).  Copy that preallocated reentrant subVI 19 more times, one for each unit.

 

3. Use VI Server (probably with Option 0x80 "call and forget") and a Static VI Reference (may need to right click and set to "strictly typed") to programmatically launch N number of asynchronous preallocated reentrant clone subVIs.  In your case N will be 20, which could be controlled by feeding an array of 20 sets of config info into a for loop that contains the "start asynchronous call" node.

Message 2 of 6
(776 Views)

I have attempted to implement #2 of your suggestion, but this doesn't seem to do what I want. I was able to create two clones of the same subvi, but they still run in series when I enable light bulb view. Should I rewrite my subvi in a way that does not involve error lines such that both instances are inside of a single loop? 

Screenshot 2023-11-28 170107.png

0 Kudos
Message 3 of 6
(740 Views)

The error wire is forcing the two subVIs to execute in series due to dataflow.  You want the subVIs to execute in parallel, so remove the error wire input on the second instance of the subVI.

0 Kudos
Message 4 of 6
(731 Views)

Thank you, that works. Now, if I have to figure out if this would work for our application. 

0 Kudos
Message 5 of 6
(727 Views)

And in "light bulb view" or "execution highlighting", you will still see sequential operation, although the active node will randomly jump around between the two loops.

 

Humans are very bad at interpreting parallel events and debugging parallel things through execution highlighting is at least annoying but often simply undoable.

Rolf Kalbermatter
My Blog
0 Kudos
Message 6 of 6
(666 Views)