06-29-2017 07:37 PM
[LabVIEW 2015]
I have a large LabVIEW GUI application that needs to connect to another GUI application (not written in LabVIEW) on the same computer. These two applications are used simultaneously and have certain data that must remain synced. After some searching, it seems that a TCP/IP connection to localhost is my best option. I've played around with it enough that I'm confident I can send and receive the data appropriately, given the connection is active and I know what data to send. I've decided (because it makes sense in context) that LabVIEW will act as the server while the other application will connect as the client. Unfortunately, I don't really know how to connect and send/receive data continuously in LabVIEW.
Here's what I want to do:
1. On button press, open a dialog asking to select the port (easy). Once this is chosen, start listening for connections on that port. I know I can use a 'TCP Listen' vi to wait for a connection with timeout -1, but from my understanding this is a blocking operation (i.e. when the vi is called, nothing else in the main GUI can run in parallel while it's waiting for a connection). If that is not the case, then that's one problem solved - but some explicit clarification would be nice.
2. Once a connection has been made, I want to keep it open until a certain timeout has been reached with no input, at which point I can send that connection to a 'TCP Close Connection' vi. The other application will be sending 'heartbeat' messages continuously, and when these stop I can assume that the other application has closed. I can implement this by using a while loop and a timeout attached to a 'TCP Read' vi, but again, this would intuitively seem to be a blocking function.
3. While a connection is active, anytime a variable X is changed, I want to send the new value of X to the other application via the TCP connection. Would I be able to manage this by connecting the 'connection ID' wire from the 'TCP Listen' vi to a 'TCP Write' vi elsewhere in the program? Is there some way to check if the connection exists, and if not, then skip that step entirely?
4. Anytime the variable X or Y is changed in the other application, that application sends the new value to LabVIEW via TCP. How could I read that value and update LabVIEW's data with that information, whenever it arrives, without blocking to wait for it?
06-29-2017 08:47 PM
@jalfje wrote:
1. On button press, open a dialog asking to select the port (easy). Once this is chosen, start listening for connections on that port. I know I can use a 'TCP Listen' vi to wait for a connection with timeout -1, but from my understanding this is a blocking operation (i.e. when the vi is called, nothing else in the main GUI can run in parallel while it's waiting for a connection). If that is not the case, then that's one problem solved - but some explicit clarification would be nice.
More like the loop cannot iterate until everything in the loop has completed. An infinite wait is typically a bad idea anyways. For instance, if you want an abort you have to continuously check for the abort. But in order to do that, you have to let the listener time out. Anything running in a parallel loop should be fine.
@jalfje wrote:
2. Once a connection has been made, I want to keep it open until a certain timeout has been reached with no input, at which point I can send that connection to a 'TCP Close Connection' vi. The other application will be sending 'heartbeat' messages continuously, and when these stop I can assume that the other application has closed. I can implement this by using a while loop and a timeout attached to a 'TCP Read' vi, but again, this would intuitively seem to be a blocking function.
3. While a connection is active, anytime a variable X is changed, I want to send the new value of X to the other application via the TCP connection. Would I be able to manage this by connecting the 'connection ID' wire from the 'TCP Listen' vi to a 'TCP Write' vi elsewhere in the program? Is there some way to check if the connection exists, and if not, then skip that step entirely?
4. Anytime the variable X or Y is changed in the other application, that application sends the new value to LabVIEW via TCP. How could I read that value and update LabVIEW's data with that information, whenever it arrives, without blocking to wait for it?
I recommend a state machine that runs in parallel with the rest of your code. When a variable changes, use a queue to send the information to the communication loop and let it send it. Otherwise, just keep trying to read. Use a 0 timeout on the queue and try to read when the queue times out. And you will want to keep the connection reference in a shift register.
06-30-2017
12:19 PM
- last edited on
01-06-2025
05:15 PM
by
Content Cleaner
crossrulz wrote:
More like the loop cannot iterate until everything in the loop has completed. An infinite wait is typically a bad idea anyways. For instance, if you want an abort you have to continuously check for the abort. But in order to do that, you have to let the listener time out. Anything running in a parallel loop should be fine.
What exactly does a 'parallel loop' mean? It's not clear to me whether that means a parallel for loop or simply a loop that is visually parallel to the rest of the code in the block diagram.
crossrulz wrote:
I recommend a state machine that runs in parallel with the rest of your code. When a variable changes, use a queue to send the information to the communication loop and let it send it. Otherwise, just keep trying to read. Use a 0 timeout on the queue and try to read when the queue times out. And you will want to keep the connection reference in a shift register.
Again, I'm not clear what 'parallel' means in this context. I do think queues will definitely help, but I'm not certain about how I would use them, especially if I have a variety of data that I might want to input or output. I'll have to play around with that. Would the attached snippet be something like what you were thinking of?
07-01-2017
06:05 AM
- last edited on
01-06-2025
05:15 PM
by
Content Cleaner
See Producer/Consumer for an example of using Queues.