Question about TCP/IP best practices

[atokad]

Hello, 

I am currently using a TCP/IP connection to connect my cRIO-9035 to a Python script on my host computer. Currently I am sending a large JSON string every iteration of my Real-Time loop similar to this users original loop. I'm not sure if this is good practice considering that the string being sent over isn't changing every loop. 

The string being sent over changes only when the users presses a button on the Tkinter GUI via the Python side. It looks something like this:

Where the Python command and bytes to read are using a subVI created from this example and I parse the JSON script in another SubVI here:

Where "Numeric Parsing" is a simple vi that parses out a double from the JSON String object:

Is the way I'm doing it good practice? Or is there a better way?

[crossrulz]

What I do is have a loop specifically dedicated to maintaining and reading messages from the Ethernet connection.  This loop receives a message when something changes and updates the appropriate values by RT Global, RT FIFO, Queue, Global Variable, etc.  You will also likely want to have a watchdog of some sort to send a "ping" back and forth just to keep the connection alive without affecting the control loop.  If you have a timeout, close the connection and wait for a new connection.  Again, this does not affect the control loop since it just runs happily along using whatever values were set last.

Also, I prefer using the Flatten To String and Unflatten From String functions instead of forming and parsing a JSON string.  The flattened data will be smaller and a lot easier to parse.  You can even flatten and unflatten clusters, making life really easy for you.

Finally, you might want to have a good look at the STM library.

[atokad]

Thanks for the reply! Let's take this step by step so I can get a clearer understanding

---

@crossrulz 

What I do is have a loop specifically dedicated to maintaining and reading messages from the Ethernet connection.  This loop receives a message when something changes and updates the appropriate values by RT Global, RT FIFO, Queue, Global Variable, etc.  

---

So, you're saying to run to a loop parallel to the operation to read the TCP values okay I understand that. How should that loop be written? Should that loop be constantly opening, reading, writing, closing? Write now I am storing the data directly into a queue and the unbundling the queue into the operation when necessary.

You will also likely want to have a watchdog of some sort to send a "ping" back and forth just to keep the connection alive without affecting the control loop.  If you have a timeout, close the connection and wait for a new connection.  Again, this does not affect the control loop since it just runs happily along using whatever values were set last.

---

Stupid question time, what's a watchdog and how do I implement it?

Also, I prefer using the Flatten To String and Unflatten From String functions instead of forming and parsing a JSON string.  The flattened data will be smaller and a lot easier to parse.  You can even flatten and unflatten clusters, making life really easy for you.

---

The Python script sends a JSON formatted string over I attached the file data.json below. I wasn't able to get unflatten from string to work with that type of data, but you may know something I don't !

Finally, you might want to have a good look at the STM library.

---

What do you mean?

[billko]

I'm curious, is that sequence structure just for documentation?  (It is actually influencing dataflow in a subtle way - the JSON string control is forced to be read from before the constants a few frames to the right, instead of letting LabVIEW decide what is most efficient at the time of execution.)  If so, I usually just use a flat frame decoration with free labels:

Admittedly, they're a little more tedious to use than a sequence structure - the wires want to avoid the frames - but it doesn't influence dataflow.

Oh, and that icon-o-sized cluster should probably be a typedef.  That way you don't have to recreate it everywhere you use it, and if you add or subtract a control, all the copies get updated.

[atokad]

---

@billko wrote:

I'm curious, is that sequence structure just for documentation?  (I don't see it influencing dataflow in any way.)  If so, I usually just use a flat frame decoration with free labels:

Admittedly, they're a little more tedious to use than a sequence structure - the wires want to avoid the frames - but it doesn't influence dataflow.

---

I used it for documenting purposes only.  I tend to frequently and accidentally move around the free labels around so the sequence adds a bit of structure to it

I don't usually use sequences, but it was easier for me to ask questions this way

[paul.r]

Open the connection once outside the loop, and just read from it in one loop. Use a queue or some other method to transfer the data out of that loop to another loop for processing. 

I would have a separate loop that does the writing - use a queue or some other method to get data into this loop that then gets sent across the network. If you use a queue, set the timeout to something like 1000ms - if you get a timeout, send a 'ping' message - Windows will sometimes close TCP sockets if they aren't being used - so this will keep the connection active even when it isnt used. 

You won't be able to use the unflatten functions, unless you are writing the python side as well - you would need to flatten the data in the python code the same way LabVIEW flattens data. 

[billko]

---

@atokad wrote:

---

@billko wrote:

I'm curious, is that sequence structure just for documentation?  (I don't see it influencing dataflow in any way.)  If so, I usually just use a flat frame decoration with free labels:

Admittedly, they're a little more tedious to use than a sequence structure - the wires want to avoid the frames - but it doesn't influence dataflow.

---

I used it for documenting purposes only.  I tend to frequently and accidentally move around the free labels around so the sequence adds a bit of structure to it

I don't usually use sequences, but it was easier for me to ask questions this way

---

Nice - see why now.  It was pretty simple to break it up for us to see when you are asking questions.

[crossrulz · Accepted solution]

---

@atokad wrote:

---

So, you're saying to run to a loop parallel to the operation to read the TCP values okay I understand that. How should that loop be written? Should that loop be constantly opening, reading, writing, closing?

---

State Machine.  You will want a states for Connect, Read, Close Connection, and Stop.  So you start in the Connect state, where you wait for a connection from some client.  If the connection times out, you just go right back into the Connect state.  Once a connection is made, you can go to the Read state and repeat that state until you get a timeout.  If you get a timeout (ie, the client stopped sending you stuff and therefore the "watchdog" expired), assume the client crashed and move to the Close Connection state.  You could also have a message from the client to tell you when they are done so that you can go to the Close Connection state without an error being thrown.  Once you close the connection, go right back to the Connect state.

In your original post, you did not specify what the other side of the connection was, so I was left to assume it was another LabVIEW application.  But since it is a Python script, you can disregard the rest of my previous post.

---