topic Re: Continuous TCP Transfer in LabVIEW

Continuous TCP Transfer

Reisbicks — Thu, 14 Feb 2019 19:48:11 GMT

Hello,

I am trying to make 2 LabView Vi's detect when a change is made in the other. Here is an example. A and B are the names of the two VI's which are both running. If a true/false button is pressed in A, then B will detect it and switch its button as well. As well, if a button is pressed in B, then A will detect it. All of the examples I have seen use a server/client system for the TCP connections which I have applied and works well, but this only seems to be a one way transfer system and the server can never detect what is happening in the client.

I have attached the attempt I have made in order to detect them, which I can explain a little more about. First the TCP connection is opened the same way any server/client pairs open. The server computer sends a cluster of 5 elements which updates continuously. When a button is pressed in the server (hence the event structure), it is supposed to change the same button on the client computer. As well after the event, it is supposed to be reading the value of the button press in the client VI. Is there an easier way to do this, or a way that acts as a two way road instead of having 2 individual 1 way tunnels?

Thanks!

Re: Continuous TCP Transfer

altenbach — Thu, 14 Feb 2019 20:24:19 GMT

TCP is connection based, so it needs to be initiated from one side, but once the connection is established, data can freely flow both ways. Your current code is deadlocked because the event structure prevents it from receiving data. You need more code!

Note that writing to a local variable ("run a step") will not fire any event. Events are mostly for user interactions.

Of course what you can do is use two different connections, one established from each side.

What is your definition of "occasionally". If this is hours, unused connections might get shut down by a TCP timeout mechanism.

You might also look into UDP, which is connectionless.

However, a much better idea would be the use of "network shared variables". No real code needed. 😄

We cannot really debug a picture, so if you want help, please attach the actual VI instead. Where are the terminals? Do you really need all these local variables?

Re: Continuous TCP Transfer

crossrulz — Thu, 14 Feb 2019 20:29:48 GMT

Your problem is that the Event Structures are blocking your reading. What I typically do is use a separate loop that handles the TCP connection. That loop can just attempt to read a byte and continue reading if something comes in or let the timeout happen and try again. But for your simple example, you can just throw your reading into the Timeout case of the Event Structure. Have a timeout of something like 50ms on the Event Structure to make sure you are attempting to read often enough.

Re: Continuous TCP Transfer

crossrulz — Thu, 14 Feb 2019 20:33:50 GMT

@altenbach wrote:

However, a much better idea would be the use of "network shared variables". No real code needed. 😄

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO...

In case you didn't know, I DESPISE Network Published Shared Variables (NPSV). Been nothing but headaches for me.

Re: Continuous TCP Transfer

Ben — Thu, 14 Feb 2019 20:48:37 GMT

@crossrulz wrote:

@altenbach wrote:

However, a much better idea would be the use of "network shared variables". No real code needed. 😄

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO...

In case you didn't know, I DESPISE Network Published Shared Variables (NPSV). Been nothing but headaches for me.

Do you remember Jim Black?

He was with NI and located in OH.

He warned me early on that I should avoid shared variables.

But back to the topic of this thread.

What you need to do is figure out if you can establish a "Master" somewhere in your grand scheme. Treating both A and B as peers will crate the possibility of a race condition if the two fight over what the state of the buttons should be. A race condition can be nasty to chase down but it is even worse if the race condition is across a network.

But first question is "Are A and B different nodes on a network or two VIs running on the same machine or same process context?"

If you are indeed running across the network and they two VIs have to be peers then you will need to establish some ground rules so they are not fighting over which one gets to set/reset the button. A Semaphore that is served on one of the machines could be used where before changing the shared value, A OR B must first acquire the semaphore before making the change and then release the semaphore after the change is made. When a change is made you should include a mechanism to let the OTHER VI know that the value has changed.

Ben

Re: Continuous TCP Transfer

Ben — Thu, 14 Feb 2019 20:58:34 GMT

Now if you could avoid making them peers and set-up a Client Server relationship, the Master could keep the "Master Copy" of the data.

In an application developed back in LV 7.1 we needed to control the valves in a factory which routed nasty gas to or from where it was needed. No big deal there BUT... The setting had to be made available to four unique PC each controlling two stations each.

In that case we used a Master PC that had access to all of the I/O and exposed VI Served Action Engines to all of the client PC. When the stations were configured for "remote" mode, the Action Engines that were running on the Master PC but invoked from the clients would dictate what the value of the buttons were. When not in Remote mode the Master PC controlled the buttons and the clients would read the sate of the buttons on the Master PC.

That approach made it dirt simple to expose control to the clients since they were only mirroring the Master PC and submitting requests to the Master PC. The image on the client PC differed only in the which Action Engines each station invoked via VI Server. There was no real logic on the Client side. All fo the logic was handle by the Master PC.

So the answer depends on a lot of things so I should stop rambling now.

Ben

Re: Continuous TCP Transfer

Bob_Schor — Fri, 15 Feb 2019 03:39:31 GMT

How quickly do you want to recipient to react to the message? I've used Network Streams to set up Message Streams between a PC Host and a Real-Time Target. Two channels allowed two-way Messaging (which, I'd estimate, had at most a 100 msec lag time, while two more Streams sent 1000kHz Analog data to the Host (50 samples at a time, i.e. a transfer rate of 20 Hz) and episodic "event" data (such as button presses) when they occurred.

Having two one-way channels means each side only needs one "receiver" and one "sender", a natural Producer/Consumer Design which is pretty (time)-efficient and (because of LabVIEW's parallelism) independent of each other.

Bob Schor

Re: Continuous TCP Transfer

Reisbicks — Tue, 19 Feb 2019 18:08:56 GMT

Thank you everyone with the help. I have made some progress on the labVIEW VI and think I have a clearer example of what I would like to accomplish. The server and client VI's attached are supposed to continuously read and write what the other boolean is reading. If one gets turned to true, the other should become false and if one gets turned false the other turns false. This way the only time any of the booleans will change is on the user command.

To run the VI's, make sure the ports both read 2055 and the address is localhost. Run the Server, then the Client and try to press the boolean button. The other boolean button should change regardless of which VI is pressed.

When these two VIs are run, they aren't consistently changed to true because they are constantly overriding the mouse click. Does anyone have a way to accomplish this.

Thanks!

Re: Continuous TCP Transfer

Bob_Schor — Tue, 19 Feb 2019 18:25:13 GMT

I haven't tested your code, and can't figure out just by looking at it what you are trying to do, but I think I can help with "over-riding the mouse click". Go to the Boolean on the Front Panel, right-click it, and look at "Mechanical Action" (there are six of them). You might try "Switch when released".

Bob Schor

Re: Continuous TCP Transfer

Mancho00 — Tue, 19 Feb 2019 20:05:35 GMT

The problem is you are constantly updating client and server with the value of the controls (with a race condition mixed in on the client side). You should only send an update when the value has changed.

Re: Continuous TCP Transfer

Ben — Tue, 19 Feb 2019 20:46:02 GMT

@Mancho00 wrote:

The problem is you are constantly updating client and server with the value of the controls (with a race condition mixed in on the client side). You should only send an update when the value has changed.

Now if someone had warned about that issue...

Quoting from post #5 in this thread

"Treating both A and B as peers will crate the possibility of a race condition if the two fight over what the state of the buttons should be."

Ben

TCP Dual Connection

Reisbicks — Wed, 20 Feb 2019 01:49:50 GMT

Hello, I have tried to make a server/client pair using the TCP connection functions in LabVIEW. In the attached VI's, the top loop is my attempt at establishing a dual connection that I know will not work because of the race that is being run sending the boolean signal between the two programs. I have tried event structures, case structures, and a few other ideas to isolate the read and write of the signal that is being passes but have not been successful. As well, I do not understand how the notifiers and semaphores work so I am hoping someone can help me fix this connection issue.

In the code below, the top while loop is where I would like someone to help me establish the ideal way to get the communication to work.

In the bottom while loop, all it does is if the boolean is true, then the server will begin counting from 1 to 10 and if the boolean is false, the client will count from 1 to 10. The boolean must read the same value at all times (except of course the amount of time for the signal to change the other one). As well, both buttons need to be able to be pressed and the change recognized by the other.

Re: TCP Dual Connection

Bob_Schor — Wed, 20 Feb 2019 03:28:50 GMT

You are concentrating on the "how", but have not clearly explained (so that I can understand it, at least) the "what". As in "What are you trying to do?". You obviously have two machines, running two programs. Describe the two programs, say (in "broad strokes") what they do, and describe their interaction. Is one running on a Real-Time system or otherwise connected to the "outside world" (and collecting data or controlling some equipment)? Is the other program a Controller/Displayer/Analyzer/Storer of Data?

Are there important constraints involving the two programs? Describe any timing/frequency/etc. relationships between the two systems.

It is often easier to "Design from the Top Down", rather than from the Bottom Up. I notice your code is developed using LabVIEW 2014 -- is that the LabVIEW Version you want to use for this Project?

Bob Schor

Re: TCP Dual Connection

Reisbicks — Wed, 20 Feb 2019 03:56:26 GMT

Sorry for the lack of the what. As you pointed out, there are two programs on different computers. One of them will be moving around some mechanical pieces and the other one will be collecting data. I have put in the numeric loops for simplicity because the loops that are in my actual programs are extremely large and messy. The most important thing is that when the mechanical VI is running, then collection VI must not be running and when the data collection VI is running, the mechanical VI must not run. This is why I need a way for the Boolean controls to always read the same T/F value regardless of which one is pressed.

Hopefully this clears things up.

Thanks!

Re: TCP Dual Connection

RavensFan — Wed, 20 Feb 2019 04:10:34 GMT

Is one program more in control than the other one? If both say they want to do something at the same time, which one determines who gets to their job when? It sounds like it has to be a master/slave relationship, or better terminology, a "server" and a "client". Which ever one is more important should be the server. When the client wants to do its job, it needs to request permission from the server. Then the server side can stop what its doing when its ready, and send permission back to the client. When the client gets permission, it does what it needs to and is required to tell the server when its done.

Don't think of it as a race between the two. Let the more significant process be in charge and let it be the server. Don't think of it as a "dual" connection. I'm not even sure what that phrase means.

Re: TCP Dual Connection

Reisbicks — Wed, 20 Feb 2019 04:21:50 GMT

I think this solution sounds like it would work for my setup, but I do not know how to "request permission from the server". I am only aware of how to read/write using the TCP connection which seems like it is enforced rather than requested. Is there a built in function somewhere which would do this in LabVIEW or is it some combination of the TCP options?

Thanks!

Re: TCP Dual Connection

RavensFan — Wed, 20 Feb 2019 05:53:29 GMT

You determine what that means! All TCP/IP communication is based on strings. So client opens a connection and literally writes "I want to do X". When server is ready, it writes back "OK, Go ahead and do X". When client is done, it writes to server "I am done with X". Server responds "Thanks, I hear you". At each step of the conversation, both sides will know whatever state they are in and can then go about doing their business or not doing their business every step whatever that business may be.

Make the text whatever you want it to actually say.

Re: Continuous TCP Transfer

Reisbicks — Wed, 20 Feb 2019 15:51:23 GMT

I understand that the race condition is occuring, but I do not know how to have both the client and server send and wait for the signal only at the time when it should be sent. I have tried using event structures, but nothing triggers the event structure on the receiving side. Can you point me to an example of how to do this?

Thanks!

Re: Continuous TCP Transfer

Ben — Wed, 20 Feb 2019 15:58:54 GMT

Create a User Event and use the ref of that User event to a dynamic event registration terminal for your event structure.

When the "Boolean change" messages is received via TCP, use the User Event ref to fire an event.

The Event structure can react to the event and act as required.

Ben

Re: TCP Dual Connection

RavensFan — Wed, 20 Feb 2019 16:43:51 GMT

Wait a minute, you've gone and created a whole new thread here when you were already discussing your issue in another thread. This makes me feel like I wasted my time.

I'm going to merge this thread into the original. It seems like some of what I have said was already stated to you in the original thread. I don't know why you didn't pay attention to that advice and decided to create a whole new thread!