Continuous TCP Transfer

[Ben]

---

@Reisbicks wrote:

Here is the attached code.  The problem is that when the boolean gets switched to true it needs to send the signal to the other VI, THEN wait for an incoming signal.  I currently don't know how to get this to happen sequentially.  the goal is 

1) Start the Server

2) Start the Client

3) Click the Boolean on the server

4) Boolean on Client turns True 

5) Click on Client Boolean (Turns it False)

6) Boolean on Server turns false

7) Repeat Steps 3-7 to infinity

Thanks!

---

Like Ravens Fan wrote, your requirements or too simplistic.

Do the following;

New Project save it

New library save it

Inside the library new Variable Select Boolean

Project>>> My Computer >>> New VI

Drop a Boolean on the FP and make it a control

Right-click Boolean and select properties

Goto the Data Binding tab

Select Shared Variable Engine

Make Access type = Read/Write

Use the brows button next to the path to navigate to the Variable you created in the project.

Clcick OK two times to get back to the VI.

Save the VI.

Do a Save As >>> Open additional copy >>> Add to project

Use the Run Continuous button to run both VIs.

Follow your outline to verify it works.

Ben

[Reisbicks]

Thank you to everyone who contributed.  I think through all the resources and suggestions, I now have exactly what I am trying to accomplish.  Now the only thing I am curious about is error handling.  In the attached VI's, if the client is started to late after the server, then

error 63 Serial port receive buffer overflow.The network connection was refused by the server.

Occurs.  I know almost nothing about error handling, so is there a way to have the server remain in a "waiting" state just in case the client is started late to prevent it from crashing?

Thanks!

[crossrulz]

---

@Reisbicks wrote:

Occurs.  I know almost nothing about error handling, so is there a way to have the server remain in a "waiting" state just in case the client is started late to prevent it from crashing?

---

Look up "State Machine".  The idea is to keep track of your state in a shift register.    You can easily merge this concept with a Queued Message Handler (perform "state" when the message queue times out).