03-06-2019 11:38 AM
Hi,
I am programming a RT application that sends data via TCP/IP from the RT to a computer. Now, it might happen that the computer crashes and the TCP connection is lost. In my RT program, I would like to have sort of a "TCP connection monitor" that listens constantly for a TCP connection. Once a new TCP connection is established, a second, parallel loop should use this "new" refnum for sending data. (There will always be just one client.)
Now I wonder about the best practice to implement this. I thought of using the same approach as in the example "TCP named service", i.e. creating a TCP listener and constantly waiting for an incoming connection. However, I cannot store that connection refnum id in a local variable that could be used from within another loop...
Why is that? What would be a nice way of distributing the connection refnum from one loop to the next? I would prefer to avoid STM since the amount of data might become large and perfomance might decrease...
Thanks
Solved! Go to Solution.
03-06-2019 12:00 PM - edited 03-06-2019 12:01 PM
Can you explain more why you can't pass a refnum through a local variable? There is nothing in LabVIEW that makes this specifically impossible but there might be situations that can make this look more difficult than you expect.
03-06-2019 02:20 PM
What I tried: I right click on the output terminal "listener ID out" of "TCP Wait on Listener". The submenu "Create" did not offer "Local Variable", as it does for e.g. front panel objects...
03-06-2019 02:26 PM
All local variables are associated with a front panel control or indicator. You cannot simply create a local variable from the output of a subVI.
03-06-2019 03:03 PM - edited 03-06-2019 03:06 PM
oh, I wasn't aware. Thanks!
Just on a side note: would you implement the whole thing differently, e.g. without local variables?
03-06-2019 06:42 PM
@TomD3 wrote:Just on a side note: would you implement the whole thing differently, e.g. without local variables?
2 options:
1. Make an Action Engine (AE) that handles the communication. The entire Send-Read Response (or just Send) should be handled inside of the AE.
2. Make a Queued Message Handler or Actor that runs in parallel with your loops. You use a queue to command that loop to send data and possibly read a response. That QMH should be in full control of the connection.