Weird serial problem

  • I'm trying to communicate with our KRC2 via serial, sending position commands and sending back acknowledgement upon receiving them, but have been having a weird issue which I can't figure out. For the strings I send from MATLAB from another PC, there are 2 integers at the beginning of the string telling the KUKA what sort of move is required (PTP, LIN, CIRC), followed by (x,y,z,a,b,c), and (s,t) if it's a PTP, e.g. "0 0 x y z...", or "1 1 x y z ...". The problem is sometimes, the "0 0 " or "1 1 " (the type of moves) do not get received properly on the KUKA side. Looking at telnet on the KUKA (photo attached), sometimes this is received as " 00", " 0", "0 " etc (note the white spaces in the string).

    I have checked the MATLAB side, it seems to be sending the strings fine, I don't think the KUKA program is the issue, because the issue is with the incoming string and not the actual processing of it. It's also strange that this only happens in the first few characters of the string, so I doubt it's to do with the serial cable, but we are checking on that now.

    Any insights would be much appreciated :icon_smile:

    EDIT: in the image attached, the first received string is the correct format, the second one is messed up - it should read "0 0 -197..." instead of " 00-197..."

  • Hm. That doesn't ring any bells. My first thought is to try using a non-whitespace delimeter, like commas, between each value. See what affect that has. It shouldn't matter, since the ASCII value for a "space" is not zero, but it's the only thing that comes to mind right off.

  • Yea I'm not sure if comma instead of whitespace is going to make any difference, like you said whitespace is just another ASCII character, plus sometimes it's the 0, 1 or 2 that we use to represent the different states that are missing.

    We tried using a serial splitter to listen on the data coming out from the PC, and when the KRC2 is not receiving the proper string, the second laptop we use to check the data is receiving it fine...

    Not sure if this is of any help, but the setting in serial.ini is below:

  • Hm. You could try different parity settings. And I don't recall ever using any XON/OFF_VAL values other than zero.

    That is deuced odd, though. It doesn't look like a buffer issue. But the Telnet diagnostics read out the raw UART buffer, which makes it really look like the character is getting dropped before it gets to the robot. I have a hard time believing it's a UART bug...

  • Did some more tests, it looks like the problem might be with MATLAB. Currently my MATLAB program sends a position when required, and polls for incoming data using a timer. When I removed the timer and hence polling for incoming data, the problem seems to go away. This leads me to think that maybe the incoming/outgoing parts of the code are clashing with each other (not something I expected from MATLAB).

    EDIT: tested with a serial splitter, data shows up fine on a 2nd PC when characters are dropped in the packet received by the KUKA...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now