11-28-2023 01:42 PM - edited 11-28-2023 02:05 PM
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?
Solved! Go to Solution.
11-28-2023 02:14 PM
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.
11-28-2023 04:06 PM
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?
11-28-2023 04:20 PM
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.
11-28-2023 04:28 PM
Thank you, that works. Now, if I have to figure out if this would work for our application.
11-29-2023 08:31 AM
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.