LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 62 in TCP Write

Solved!
Go to solution

I am a very new user of LabVIEW and coding in general. I am attempting to write a code that communicates with a robot, activates it, and then controls it using a controller. I am on the activation step as of now. I used an example code from the manufacturers website to get started and have this code that I have modified to fix previous errors. The code is in two parts. The first being the main VI that puts each requested command, in order, inside of the sequence structure. The Sub VI being used is the second part of the code and where the error lies. The Sub VI can successfully identify which command is being inputted into the TCP Write function on the first iteration of the while loop, however, upon the second iteration, I receive Error 62. I suspect this has something to do with the fact that it can't receive the next command from the main VI unless I stop the while loop in the Sub VI manually which carries over the error. The command to "activate" the robot also hasn't been successful with the robot being on and connected. Any help on getting this to work properly would be greatly appreciated along with any pointers on faulty wiring in order to improve efficiency in the future.

Download All
0 Kudos
Message 1 of 11
(597 Views)

There's a lot to unpack here!

 

  • Please attach actual VIs, not images. They are easier to troubleshoot and debug
  • I'm not sure I understand why your sub-VI has a while loop. You are basically writing the exact same command over and over until you click 'Stop' on the front panel. Generally write operations happen once.
  • You don't need your flat sequence structure. Data flow takes care of the sequencing. Your "wait" operations are asynchronous with your write. You'd be better off using stall data flow.



 

0 Kudos
Message 2 of 11
(572 Views)

Made those changes and attached proper VI files, sorry about that. Thanks for the help!

Download All
0 Kudos
Message 3 of 11
(556 Views)

I'm in agreement that the subVI is not even needed because you should not have the write inside of a While Loop.  Just completely replace the subVI with TCP Write and be done with it.

 

Beyond that, I need more information on the communication protocol.  Is there are manual that you can point us to?  I suspect you are formatting your messages wrong.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 11
(519 Views)

I changed the Sub VI's used in the Main to TCP Write and still getting Error 62. The robot communicates using null-terminated ASCII strings transmitted over TCP. The only null character I could find in the programming manual is "/0" so I changed to use that.

0 Kudos
Message 5 of 11
(504 Views)

I can't view your VIs as I am still using LabVIEW 2021, but I think you are not actually sending a null character at the end of your commands.

 

The commands in your screenshots end in "\x00".

 

LabVIEW does not use a slash to indicate the use of control characters, so "\x00" is not sending a single null character, it's sending 4 characters, "\", "x", "0", and "0".

 

To use "slash codes", activate it with the right-click menu on a constant:

Kyle97330_0-1718839507263.png

Once you do that, you can put in "\00" to actually put in a null character.  The "x" is not valid in LabVIEW, but may have been in your manual to distinguish that it's a hex code and not another numeric type (you might see "d" for decimal, "b" for binary, etc....)

 

Message 6 of 11
(493 Views)

@Zsmathers0211 wrote:

The robot communicates using null-terminated ASCII strings transmitted over TCP.


This was one of the key pieces of information I was looking for.  I just asked for more just to make sure everything else you were sending was correct (I've been through this way too many times).

 

As Kyle pointed out, you need to change your display style on your string constants to "\ Codes".  The Null character is the "\00".  If you want to change the display style in mass, here is a nice plugin: Quick Format (QuickDrop Plugin).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 11
(474 Views)

Thank you both for the continued support. I changed the string constants to "\ Codes" and they do seem to like the "\00" because it defaults to that. After I made the change to the string constants, I am still getting "Error 62: Serial port overrun error" on every TCP Write except for the first one. If there's anything else you could think of, any help is appreciated. If not, I could just mark Kyle's response as the solution and check hardware to see if something is wrong with how it's set up IP Address-wise. I've attached the VI and a screenshot.

Download All
0 Kudos
Message 8 of 11
(466 Views)

Make sure your instrument isn't expecting you to do a TCP Read before sending the next command.

 

Often times there is a command/response pair in communications. You send a command to the instrument, it responds "Ok yeah I got the command and completed it buddy". If you don't read the response before the next command it assumes there is a communication problem and shuts down the connection.

Message 9 of 11
(446 Views)

@Zsmathers0211 wrote:

I am still getting "Error 62: Serial port overrun error" on every TCP Write except for the first one.


Keep reading the error explanation.  The second description is what you are running into: "The system caused the network connection to be aborted."

 

You are doing something to cause the robot to kill the connection.  As already mentioned, maybe you need to do a TCP read to get a response.  Or maybe you need a longer wait before sending the next command.  There are many possible things.  Again, a manual would be helpful in debugging this.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 11
(429 Views)