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

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..."

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:

[COM3]


BAUD=9600
CHAR_LEN=8   ; 7,8
STOP_BIT=1   ; 1,2  at time not changeable
PARITY=2     ; EVEN=2, ODD=1, NONE=0
PROC=4       ; 3964R=1, SRVT=2, WTC=3, XONXOFF=4


[XONXOFF]
CHAR_TIMEOUT=50      ; msec   Timeout after last received character
                     ;        to recognize the end of telegram
MAX_TX_BUFFER=5      ; 1..5
MAX_RX_BUFFER=20     ; 1..20
SIZE_RX_BUFFER=2048  ; 1..2048 longest expected telegram length + 15 characters
XON_VAL=17           ; 0..255  XON  character (decimal)
XOFF_VAL=19          ; 0..255  XOFF character (decimal)
                     ; if XON_VAL=0 and XOFF_VAL=0 then XON/XOFF protocol
                     ; is disabled (pure serial communication)
DSR_LINE=0           ; 0 = DSR line not connected, 1 = DSR line must be high

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...