1. Home
    1. Dashboard
    2. Search
  2. Forum
    1. Unresolved Threads
    2. Members
      1. Recent Activities
      2. Users Online
      3. Team Members
      4. Search Members
      5. Trophys
  3. Articles
  4. Blog
  5. Videos
  6. Jobs
  7. Shop
    1. Orders
  • Login or register
  • Search
This Thread
  • Everywhere
  • This Thread
  • This Forum
  • Articles
  • Pages
  • Forum
  • Blog Articles
  • Products
  • More Options
  1. Robotforum - Support and discussion community for industrial robots and cobots
  2. Forum
  3. Industrial Robot Support and Discussion Center
  4. KUKA Robot Forum
Your browser does not support videos RoboDK Software for simulation and programming
Visit our Mainsponsor
IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Sponsored Ads

Kuka KRC1 Serial communication not receiving on laptop

  • Rikkoman
  • July 21, 2024 at 9:33 PM
  • Thread is Unresolved
  • Rikkoman
    Trophies
    1
    Posts
    14
    • July 21, 2024 at 9:33 PM
    • #1

    Good evening.

    Trying to use serial communication between my laptop and the krc1, to control my robot.

    Firstly I tested communication with hyperterminal, this is as I understand on the windows enviroment which I chose by editing the HW_F.INI file setting COM2 to enable. This worked well after some trial and error(realised I needed to force cold startup in order to let changes in .INI file take effect). Sending and receiving worked, I used a terminal on ubuntu laptop, configured the terminal with stty to work with serial com via commandline. cat /dev/ttyUSB0 for reading, this worked.

    After this I wanted to control the robot, so I changed the HW_F.INI again for the COM to be visable to VxWorks OS. It worked in that I can receive data with CREAD on the KRC1 pc and move the robot with this data. Writing with CWRITE didn't result in seeing the text on my laptop however.

    By using my telnet(firstly setting TESTPRINT=1 in Serial.INI) to see the traffic on the RX and TX pins I could see the correct data on both pins.

    Also I dont know if the Xon/Xoff settings matter in SERIAL.INI, is default ok?


    Below are the files and results I described.

    If anyone has any suggestions on what to try next that would be very helpful :smiling_face:

    Thanks in advance

    Kind regards,

    Rik


    Serial.INI:


    telnet on krc1:


    This is the stty setting i used in the terminal;

    Code
    sudo stty -F /dev/ttyUSB0 9600 cs8 -cstopb parenb -parodd ixon ixoff

    Sending msg manually and reading(robot reveives msg but no returning msg on laptop)

    Code
    rik@rik-N56VM:~/Documents/custom_scripts$ echo 1100 -20 1500 180 9 -175 2 10 2922 > /dev/ttyUSB0
    Code
    rikverhoeven@rikverhoeven-N56VM:~/Documents/custom_scripts$ cat /dev/ttyUSB0 
    ^C


    Also I tested a python script for controlling it, same result; sending worked, receiving from krc1 not.;

    Python
    import serial
    import time
    import sys
    from enum import Enum
    
    def calculate_checksum(values):
        return sum(values)
    
    def open_serial_port():
        ser = serial.Serial(
            port,
            baudrate,
            bytesize=serial.EIGHTBITS,
            parity=serial.PARITY_EVEN,
            stopbits=serial.STOPBITS_ONE,
            xonxoff=True,
            timeout=0.5
        )
        return ser
    
    def send_position_data(port, baudrate, positions):
        ser = open_serial_port()
        for position in positions:
    
            read_str = ser.read(30)
            print(f"read: {read_str.strip()}\n")
    
            x, y, z, a, b, c, s, t, delay = position
            checksum = calculate_checksum([x, y, z, a, b, c, s, t])
            data_str = f"{x} {y} {z} {a} {b} {c} {s} {t} {checksum}\n"
    
            input("Press Enter to send the next position...")
            ser.write(data_str.encode('utf-8'))
            
            print(f"Sent: {data_str.strip()}", file=sys.stdout)
            read_str = ser.read(30)
            print(f"read: {read_str.strip()}\n")
            # time.sleep(delay)
        ser.close()
    
    if __name__ == "__main__":
        port = '/dev/ttyUSB0'  # Serial port to send data
        baudrate = 9600  # Baud rate
        delay = 2  # Time delay in seconds between sending data points
        
        # Example positions (x, y, z, a, b, c)
        positions = [
            (721, -216, 1413, 180, 9, -176, 2, 10, 5),
            (805, -216, 1326, 180, 9, -176, 2, 10, 5),
            (805, 79, 1335, 180, 9, -176, 2, 35, 5),
            (805, 79, 1413, 180, 9, -176, 2, 35, 5),
    
            # Add more positions as needed
        ]
            # "error msg from kuka received\n")
        send_position_data(port, baudrate, positions)
    Display More

    output from script;

    don't understand why received string is : b' '

    Code
    rik@rik-N56VM:~/Documents/KukaRobot$ python3 control_robot.py
    read: b''
    
    Press Enter to send the next position...^[[A
    Sent: 721 -216 1413 180 9 -176 2 10 1943
    read: b''
    
    read: b''
    
    Press Enter to send the next position...
    Sent: 805 -216 1326 180 9 -176 2 10 1940
    read: b''
    
    read: b''
    Display More


    program on the KRC1:

    Code
     ;This program waits for a valid position being received at the COM2 interface and then moves the robot to that position.
    
    ;--------- Declaration ---------
    DECL INT HANDLE, I, J, CREAD_OFFSET, NUMBER
    DECL CHAR NOTIFY_TEXT[5], READ_STRING[20]
    DECL REAL TIMEOUT, CHECKSUM, SUMCOORD
    DECL STATE_T CWRITE_STATE, CREAD_STATE
    DECL MODUS_T MODUS
    DECL POS PositionRobot
    Code
    ;---------- Initialization ---------
    CHECKSUM=0
    SUMCOORD=0
    I=1
    
    FOR J = 1 to 6
     $VEL_AXIS[J]=15  ;x% max. speed
     $ACC_AXIS[J]=40 ;x% max. acceleration
    ENDFOR
    Code
    ;---------------------------------------
    ;              Main program 
    ;---------------------------------------
    
    ;------------- Open channel to COM2 -----------
    COPEN(:SER_2,HANDLE) ;Open a channel to COM2 according to config in serial.ini. If XON/XOFF is used, then a XON symbol is sent by COPEN.
    
    IF HANDLE==0 THEN ;If an error occured during opening the channel, then stop the program.
     HALT
    ENDIF
    
    MODUS=#SYNC 
    
    LOOP ;endless loop
    
     ;------------- Write to COM2 -----------
     CWRITE(HANDLE,CWRITE_STATE,MODUS,"hi")
     CWRITE(HANDLE,CWRITE_STATE,MODUS,"start of loop %d",I)  ;Send counter value to track the loop.
    
     ;------------ Read from COM2 -----------
     TIMEOUT=15.0
     CREAD_OFFSET=0
     MODUS=#ABS
    
     CREAD(HANDLE,CREAD_STATE,MODUS,TIMEOUT,CREAD_OFFSET,"%f %f %f %f %f %f %d %d %f",PositionRobot.X,PositionRobot.Y,PositionRobot.Z,PositionRobot.A,PositionRobot.B,PositionRobot.C,PositionRobot.S,PositionRobot.T,CHECKSUM)
     ;Send for example the string "2000 -800 1800 -90 90 -90 2 10 2922" to COM2. THe last value is the sum of all previous values.
    
     IF CREAD_STATE.RET1==#CMD_TIMEOUT THEN ;If the timeout time has been exceeded, then exit the loop. 
      EXIT
     ENDIF
     
     PTP PositionRobot
     CWRITE(HANDLE,CWRITE_STATE,MODUS,"%d", CHECKSUM)
     I=I+1
     CWRITE(HANDLE,CWRITE_STATE,MODUS,"end of loop") ;mark the end of the loop.
    
    ENDLOOP
    
    CCLOSE(HANDLE,CWRITE_STATE) ;info: a XOFF is sent after closing
    
    END
    Display More
  • hermann
    Reactions Received
    403
    Trophies
    9
    Posts
    2,593
    • July 22, 2024 at 7:59 AM
    • #2

    I am astonished that you say sending is working. IIRC KRC1 only can 'speak' 3964R protocol. May be this b'' is a representation of the not printable character NAK.

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,369
    • July 22, 2024 at 5:45 PM
    • #3
    Quote from hermann

    I am astonished that you say sending is working. IIRC KRC1 only can 'speak' 3964R protocol. May be this b'' is a representation of the not printable character NAK.

    No, KRC1 can speak several, including raw text. XON/XOFF is required for that, though, IIRC.

    Quote from Rikkoman

    don't understand why received string is : b' '

    I think that might be Python's way to showing that it's trying to print binary values, probably ones that aren't directly printable ASCII.

    A lot of the RS232 protocols rely on deliberately adding a deliberate Newline and/or Line Feed ASCII character to the end of the string being sent. Your test data from the Telnet session shows this on the RX data, those 0xD and 0xA values are the hex values of CR and LF. When I was using RS232 on KRC2s, I usually had to add that explicitly, and adding non-printable characters took a bit of extra work:

    Code
    CR=13       ; INT ASCII value of "Carriage Return"
    Comma = 44  ; INT ASCII value of a comma ","
    Offset=0 ; SWRITE will work from first position of string
    SWRITE(Send_Command[], CH_State, Offset, "%s", VisionRequest[]) ; write command string to tx string
    IF CH_State.RET1 <> #CMD_OK THEN ; check success of SWRITE
     HALT  ; halt if error
    ENDIF
    Offset = (( StrLen (Send_Command[])) +1 ) ; find end of string
    Send_command[Offset]=CR ; add [CR] to end of string
    HALT
    COPEN (:SER_3, Handle) ; open serial port COM3
    CWRITE (Handle, TX_State, Mode, "%s", Send_Command[]) ; send TX string
    Display More
  • MOM
    Reactions Received
    175
    Trophies
    7
    Posts
    1,414
    • July 23, 2024 at 3:21 PM
    • #4

    How does your serial cable looks like?

    I used a jumper (krc side) between pin 4 (DTR) and pin 6 (DSR) as well.

    (DSUB9)

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,369
    • July 23, 2024 at 3:44 PM
    • #5
    Quote from MOM

    How does your serial cable looks like?

    I used a jumper (krc side) between pin 4 (DTR) and pin 6 (DSR) as well.

    Ah, yes... it's been a long time, but IIRC the XON/XOFF protocol needed more than just TX/RX/Gnd to be wired. I think I was able to make a simple 3-wire null-modem cable work by changing the XON/XOFF mode to 0s in SERIAL.INI:

    Code
    [XONXOFF]
    CHAR_TIMEOUT=50      ; msec   Timeout after last received character
                        ;        to recognize the end of telegram
    MAX_TX_BUFFER=2      ; 1..5
    MAX_RX_BUFFER=2      ; 1..20
    SIZE_RX_BUFFER=100   ; 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 communication)

    ASCII 17 and 19 are the dedicated XON/XOFF characters.

    The attached manual is something you probably already have, but has the best description of KRC RS-232 I have lying around.

    Files

    creadcwrite_r41_en.pdf 528.77 kB – 9 Downloads
  • MOM
    Reactions Received
    175
    Trophies
    7
    Posts
    1,414
    • July 23, 2024 at 3:54 PM
    • #6

    OK, check page 40 for the max. wiring.

    Setting XON/XOFF to 0 (= XON/XOFF is disabled) is just allowing to send data in binary format

  • MOM
    Reactions Received
    175
    Trophies
    7
    Posts
    1,414
    • July 23, 2024 at 4:01 PM
    • #7

    Also check page 38 for

    DSR_LINE=0 ; 0 = DSR line not connected, 1 = DSR line must be high

  • Rikkoman
    Trophies
    1
    Posts
    14
    • July 24, 2024 at 7:20 PM
    • #8

    Thanks very much all for the suggestions .

    My null modem cable only crosses tx and rx.

    I haven't tried with 3964r protocol yet, this seems more complicated.


    I tried writing extra CR or LF after string but this didn't fix it.

    I added the DSR_LINE=0, this was missing in my serial.ini.

    Also I tried with no protocol, Xon and Xoff value set to 0. This had no change in outcome.


    But as am reading now Xon and Xoff relate to a receiving device telling the sending device that its allowed to send data?

    Perhaps Xon and Xoff still needed to be sent from laptop to KRC pc by pressing crtl-s(Xon) and crtl-q(Xoff)... I forgot this.

    Because on krc1 pc side it is done by COPEN and CCLOSE??? According to this article it is: http://www.loullingen.lu/projekte/kuka/…php?language=EN

    It it peculiar ofcourse that in hyperterminal it worked fine.. I am curious how this worked in hyperterminal, without manual Xon and Xoff.

  • MOM
    Reactions Received
    175
    Trophies
    7
    Posts
    1,414
    • July 24, 2024 at 8:57 PM
    • #9

    The XON/XOFF protocol was formerly used for communication between computer and printer (like EPSON FX80).

    The data transfer was faster than printing a set of characters (which would have caused an overrun)

    With this protocol the printer tells the pc to stop transferring data until most of the charachters were printed (and the buffer almost empty and able to receive new data).

    I would have a closer look to your python script (do you really receive a string or a float or double)?


    The telnet output shows what happens within the driver and not was actually is going over the serial line! Can you check what you are actually receiving?

    LindePaul actually told me the hint I mentioned in post #4 long time ago.

  • Rikkoman
    Trophies
    1
    Posts
    14
    • July 25, 2024 at 10:30 AM
    • #10

    you mean am not seeing anything printed to my terminal because incoming data is too fast to be printed? This relates to baud rate right if I understand correctly right? I have it set to 9600 which shouldn't be too much

    I also tried redirecting cat /dev/ttyUSB0 in to new file but nothing

    I will check again but I didn't think I received anything. Next week also with an oscilliscope to see if I can see any signals.

  • Online
    SkyeFire
    Reactions Received
    1,038
    Trophies
    12
    Posts
    9,369
    • July 25, 2024 at 3:39 PM
    • #11
    Quote from Rikkoman

    you mean am not seeing anything printed to my terminal because incoming data is too fast to be printed? This relates to baud rate right if I understand correctly right? I have it set to 9600 which shouldn't be too much

    No, it's a matter of buffering. XON/XOFF were used to prevent buffer overflows on the receiving device.

    For RS-232, the baud rates must match on both ends, or else a good transmission will be received as garbage. The baud rate control is "open loop" -- RS-232 works on the assumption that the UARTs on both ends will be operating at a clock frequency that is close to the same, and the sampling rate is adjusted accordingly. There's generally no baud rate detection or handshake (unlike when using modems, which auto-negotiate the baud rate during their connection establishment).

    The RS-232 standard has a large amount of tolerance, since it originates from a time when getting reliable timing on different computers was difficult. But not enough to allow one terminal to send at 9600 while the other is listening at 4800. In the event of such a mismatch, the receiver would decode the waveform at sample rate X, while the sender would be sending at 2X, and neither side would know about the mismatch. This would result in the receiver picking up data that looks valid, but bear no resemblance to what the sender was sending.

Advertising from our partners

IRBCAM
Robotics Channel
Robotics Training
Advertise in robotics
Advertise in Robotics
Advertise in Robotics

Job Postings

  • Anyware Robotics is hiring!

    yzhou377 February 23, 2025 at 4:54 AM
  • How to see your Job Posting (search or recruit) here in Robot-Forum.com

    Werner Hampel November 18, 2021 at 3:44 PM
Your browser does not support videos RoboDK Software for simulation and programming

Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Thread Tag Cloud

  • abb
  • Backup
  • calibration
  • Communication
  • CRX
  • DCS
  • dx100
  • dx200
  • error
  • Ethernet
  • Ethernet IP
  • external axis
  • Fanuc
  • help
  • hmi
  • I/O
  • irc5
  • IRVIsion
  • karel
  • kawasaki
  • KRC2
  • KRC4
  • KRC 4
  • KRL
  • KUKA
  • motoman
  • Offset
  • PLC
  • PROFINET
  • Program
  • Programming
  • RAPID
  • robodk
  • roboguide
  • robot
  • robotstudio
  • RSI
  • safety
  • Siemens
  • simulation
  • SPEED
  • staubli
  • tcp
  • TCP/IP
  • teach pendant
  • vision
  • Welding
  • workvisual
  • yaskawa
  • YRC1000

Tags

  • KUKA
  • krc1
  • serial port
  • serial
  • communicaton

Users Viewing This Thread

  • 1 Guest
  1. Privacy Policy
  2. Legal Notice
Powered by WoltLab Suite™
As a registered Member:
* You will see no Google advertising
* You can translate posts into your local language
* You can ask questions or help the community with your knowledge
* You can thank the authors for their help
* You can receive notifications of replies or new topics on request
* We do not sell your data - we promise

JOIN OUR GREAT ROBOTICS COMMUNITY.
Don’t have an account yet? Register yourself now and be a part of our community!
Register Yourself Lost Password
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on Google Play
Robotforum - Support and discussion community for industrial robots and cobots in the WSC-Connect App on the App Store
Download