Error 56 occurred at TCP

[LNH02]

Hi,

I have an issue that has been baffling me for days... I have a device which I am trying to communicate with. Using the vendor's supplied software, everything works just fine. For example, I could send commands to :

Start communication:  002000010030\s\s\s\s00\s\s\00

Get data:                     002000100010\s\s\s\s00\s\s\00

Stop communication:   002000030010\s\s\s\s00\s\s\00

(Please see at the bottom for response from device)

Now, if I use my LabVIEW code, sending the exact above commands under the exact same setup, the device could only respond to the Start and Stop commands--the response I get is an identical match to that of the vendor software. When I try to "Get data" (between Start and Stop, of course), the TCP read function would time out, as if it's not getting the correct command. 

In the vi, the first TCP write/read is used to obtain the first 4 bytes, and the second TCP write/read is to obtain the rest of the data. The error on the "Get data"  command occurred on the first TCP read.

2017-6-26:7:3:34:511 Communication Start
To PF 30 30 32 30 30 30 30 31 30 30 33 30 20 20 20 20 00200001 0030
Tö PF 30 30 20 20 00 00 .

2017-6-26:7:3:34:525 Communication Start Acknowledge
From PF 30 31 32 35 30 30 30 32 30 30 33 20 20 20 20 20 01250002 003
Fröm PF 20 20 20 20 30 31 30 30 30 30 30 32 30 30 30 33 0100 00020003
Fröm PF 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
Fröm PF 20 20 20 20 20 20 20 20 20 30 34 41 43 54 30 35 04ACT05
Fröm PF 31 2e 30 2e 33 31 20 20 20 20 20 20 20 20 20 20 1.0.31
Fröm PF 20 20 20 30 36 37 2e 35 20 53 52 32 20 20 20 20 067.5 SR2
Fröm PF 20 20 20 20 20 20 20 20 30 37 37 2e 31 36 2e 33 077.16.3
Fröm PF 39 01 20 20 20 20 20 20 20 20 20 20 20 00 9. .

2017-6-26:7:9:0:597 Parameter Set Number Upload Request
To PF 30 30 32 30 30 30 31 30 30 30 31 30 20 20 20 20 00200010 0010
Tö PF 30 30 20 20 00 00 .

2017-6-26:7:9:0:684 Parameter Set Number Upload Reply
From PF 30 30 38 36 30 30 31 31 20 20 20 20 20 20 20 20 00860011
Fröm PF 20 20 20 20 30 32 31 30 30 31 30 30 33 30 31 30 0210 01003010
Fröm PF 31 30 30 31 30 31 31 30 32 31 30 33 31 30 34 31 10010110 21031041
Fröm PF 30 35 31 30 36 31 30 37 31 30 38 31 30 39 31 31 05106107 10810911
Fröm PF 30 31 31 31 31 31 32 31 31 33 31 31 34 31 31 35 01111121 13114115
Fröm PF 31 31 36 31 31 37 00 116117.

2017-6-26:8:2:6:781 Communication Stop
To PF 30 30 32 30 30 30 30 33 30 30 31 30 20 20 20 20 00200003 0010
Tö PF 30 30 20 20 00 00 .

2017-6-26:8:2:6:788 Command Accepted
From PF 30 30 32 34 30 30 30 35 20 20 20 20 20 20 20 20 00240005
Fröm PF 20 20 20 20 30 30 30 33 00 0003 .

Your help is highly appreciated!

[crossrulz]

---

@LNH02 wrote:
For example, I could send commands to :

Start communication:  002000010030\s\s\s\s00\s\s\00

...

2017-6-26:7:3:34:511 Communication Start

To PF 30 30 32 30 30 30 30 31 30 30 33 30 20 20 20 20 00200001 0030
Tö PF 30 30 20 20 00 00

---

Interpreting your hex data here, something seems wrong with your start command.  It looks like what you are actually sending is:

002000010030\s\s\s\s\\00\s\00\01\00000\s\s\00\00

I have a feeling you are mixing \ codes and hex.  At the very least, you have extra data in there.  I didn't go through the rest.  But that was my immediate observation.

[LNH02]

Hi crossrulz,

Interpreting your hex data here, something seems wrong with your start command.  It looks like what you are actually sending is:

002000010030\s\s\s\s\\00\s\00\01\00000\s\s\00\00

How did you come up with the "extra data" \s\00\01\00000\s\s\00\00? 

This the actual data from the good software I was comparing mine to:

2017-6-26:7:3:34:511 Communication Start

To PF 30 30 32 30 30 30 30 31 30 30 33 30 20 20 20 20 00200001 0030
Tö PF 30 30 20 20 00 00

The Start and Stop command works just fine. It's my "Get data" command that is not working.

[jamiva]

---

@LNH02 wrote:

Hi crossrulz,

Interpreting your hex data here, something seems wrong with your start command.  It looks like what you are actually sending is:

002000010030\s\s\s\s\\00\s\00\01\00000\s\s\00\00

How did you come up with the "extra data" \s\00\01\00000\s\s\00\00? 

This the actual data from the good software I was comparing mine to:

2017-6-26:7:3:34:511 Communication Start

To PF 30 30 32 30 30 30 30 31 30 30 33 30 20 20 20 20 00200001 0030
Tö PF 30 30 20 20 00 00

The Start and Stop command works just fine. It's my "Get data" command that is not working.

---

First, why are you writing the same "Start Communication" command twice? You are only reading 4 bytes from the first command, and not reading the entire response.

Second, I don't really know what your command protocol is, but is appears that your "working" software is sending 22 bytes in total. However, the command specifies 20 bytes (0020....). Why the final 2 NULL characters? Are all communications terminated by two NULL characters??

[LNH02]

First, why are you writing the same "Start Communication" command twice? You are only reading 4 bytes from the first command, and not reading the entire response.

Please refer to my original statement. If you have better suggestions I gladly welcome it.

In the vi, the first TCP write/read is used to obtain the first 4 bytes, and the second TCP write/read is to obtain the rest of the data. The error on the "Get data"  command occurred on the first TCP read.

The "extra" NULL (I do not believe is an extra NULL); its auto generated by LV when I chose the "Backslash(\) Code option under the string properties. If you open the vi, and delete the "extra" NULL, LV will repopulate it. Not sure why.

[NickelsAndDimes]

Hey, TNH1,

I'd recommend going into the LabVIEW example finder and searching for "TCP" and look at some pre-made working programs.

The thing that stands out to me is the lack of a TCP Listen VI in your block diagram. If the error happens on the first TCP read, it could be that the VI doesn't know *where* to listen for data.

[rolfk]

---

@NickelsAndDimes wrote:

The thing that stands out to me is the lack of a TCP Listen VI in your block diagram. If the error happens on the first TCP read, it could be that the VI doesn't know *where* to listen for data.

---

That's certainly not quite a helpful answer. TCP Listen is only needed if you implement the server side. For the client side a TCP Open is perfectly fine!

One of the things the OP did wrong is to read the 4 byte length part, then resend the command and then read the payload that he determined from the first 4 byte. Thanks to the second  re-sending of the command, the device will AGAIN send a whole message, which the next execution of this VI eventually will read, but then two more messages have been triggered, and in that way the message you actually read will be more and more stale as the superfluous messages queue up in the TCP/IP driver stack.

And as crossrulz already noticed, he somehow is mixing and matching hex displayed characters and actual string data display. Supposedly the first 4 characters are a number that indicates the number of bytes to follow for the messages but when you look at the messages as he shows them in his first post, that simply doesn't add up.

I suppose that the data that is nicely grouped into 2 character numbers actually is in Hex, so each 2 character number is in fact one byte, while the data that is clustered together in larger groups is some other format. 

[LNH02 · Accepted solution]

Thank you all for the responses. I got it to work- it turns out to be my closing of the connection. Because I terminated communications after each execution, the device expects a START command again before a subsequent command is sent BIG DUHHH moment 🙂 I am still early in the development phase and just familiarizing myself with the device.

Rolf, really good stuff there. I will definitely take that into consideration. Thanks again!