Keep getting error 66 tcp read, is it because of bytes to read?

[David99999]

I've got a cRIO as the tcp server, and a little test VI for the tcp client. Whenever my server responds to the client, the client throws an error 66. But I'm still getting the data, and I can just press continue and then I can keep pressing the send button and it does it's thing and then gets another error 66, etc. 

I've been trying to figure out why for a couple days now, and now I'm starting to think it's because I'm telling it to look for too many bytes to read? I thought that was just a max, and it wouldn't care if it's less.

[Kyle97330]

I can't see your VIs on account of I only have LV 2018 installed, but error 66 is that the connection was closed.  Are you closing the TCP connection reference after sending the reply to the client?  If so, that's the cause.

[crossrulz]

---

@Kyle97330 wrote:

Are you closing the TCP connection reference after sending the reply to the client?  If so, that's the cause.

---

Yes he is.

As Kyle stated, you should just leave the connection until the application is done.  Let the client handle the connection (close it when done) and have the server close the connection when error 66 happens.  The server can then go back to looking for a connection.

[David99999]

---

@crossrulz wrote:

---

@Kyle97330 wrote:

Are you closing the TCP connection reference after sending the reply to the client?  If so, that's the cause.

---

Yes he is.

As Kyle stated, you should just leave the connection until the application is done.  Let the client handle the connection (close it when done) and have the server close the connection when error 66 happens.  The server can then go back to looking for a connection.

---

Ok I'll try this again, but I'm like 99% sure that when I simply remove the TCP close connection VI from the server, it stops working. It seems to timeout and eventually throws a different error, but I think after that the requested information does actually come through.

I'll run it again and post what I get. Thanks guys!

[crossrulz]

---

@David99999 wrote:

Ok I'll try this again, but I'm like 99% sure that when I simply remove the TCP close connection VI from the server, it stops working. It seems to timeout and eventually throws a different error, but I think after that the requested information does actually come through.

I'll run it again and post what I get. Thanks guys!

---

What I do is have the server loop have a flag for whether it is connected to a client or not.  If not connected, listen for a connection.  If connected, try to read and react accordingly.  Outside of that case structure, if an error occurs close the connection and set the flag to false.

[David99999]

Ok so what I'm actually seeing is a unflatten from JSON error. 

"LabVIEW: (Hex 0xFFFA4725) The JSON string is invalid. JSON strings must be encoded in UTF-8 and must conform to the JSON grammar."

I'm assuming that the TCP code is working as it should now that I stopped closing the connection in the server loop. 

As far as the JSON unflattening goes, I thought my issue was the \r\n characters that I'm sending over with the JSON object, so I was removing them from the received data before it hit the unflatten from json VI. Otherwise, I don't know why the heck it would be unhappy. 

EDIT: Here is the JSON string object the server is sending out:

{

    "Max Amps":1.1405940000000042113e-06,

    "Discharged Whs":0,

    "Charged Whs":0,

    "Avg Discharge Amps":1.2718751156039192901e-07,

    "Discharged Total Watts":0,

    "Charged Total Watts":0,

    "Battery Voltage":62

        }\r\n

[billko]

Since the original issue was solved, I would suggest starting a new topic.  🙂

[crossrulz]

---

@David99999 wrote:

EDIT: Here is the JSON string object the server is sending out:

{

    "Max Amps":1.1405940000000042113e-06,

    "Discharged Whs":0,

    "Charged Whs":0,

    "Avg Discharge Amps":1.2718751156039192901e-07,

    "Discharged Total Watts":0,

    "Charged Total Watts":0,

    "Battery Voltage":62

        }\r\n

---

Is that a literal "\r\n" at the end or is it an actual Carriage Return and Line Feed?

And how are you creating the JSON string?  The Flatten To JSON does not make it look pretty like that.

[David99999]

---

@crossrulz wrote:

---

@David99999 wrote:

EDIT: Here is the JSON string object the server is sending out:

{

    "Max Amps":1.1405940000000042113e-06,

    "Discharged Whs":0,

    "Charged Whs":0,

    "Avg Discharge Amps":1.2718751156039192901e-07,

    "Discharged Total Watts":0,

    "Charged Total Watts":0,

    "Battery Voltage":62

        }\r\n

---

Is that a literal "\r\n" at the end or is it an actual Carriage Return and Line Feed?

And how are you creating the JSON string?  The Flatten To JSON does not make it look pretty like that.

---

Well, it's supposed to be an actual carriage return and line feed, since I've got the TCP vi's in CRLF mode to detect when the message is complete. But maybe I'm doing it wrong?

And no, I did that manually in my post to make it easier to read. Here is what it looks like when I copy and paste directly from the string indicator:

{"Max Amps":1.1405940000000042113e-06,"Discharged Whs":0,"Charged Whs":0,"Avg Discharge Amps":1.2718751156039192901e-07,"Discharged Total Watts":0,"Charged Total Watts":0,"Battery Voltage":62}\r\n

[David99999]

Wait. Ok. Just realized I'm getting an error 56 right after the JSON unflatten error. Which is the network operation exceeded the user-specified or system time limit. This is the other error I get when I remove the close connection from the server.

Maybe it's still a TCP related issue? And the JSON error right before the error 56 is because there wasn't anything for the unflatten JSON vi to unflatten?

It's so weird. When I have the close connection in the TCP server, my TCP client receives the data just fine, but throws the error 66. But when I remove the close connection from the server, my client never gets the data and times out. But the server is seeing the request, and sends out the data.