Help with Modular Trajectory Execution in KUKA KRL [KUKA KR210 R2700-2 / KRC5 - KSS 8.7]

    • New

    Hello everyone,

    I’m currently working on a KUKA robot control system, and I’m looking for some guidance on managing and executing robot trajectories dynamically. Specifically, I want to modularize the handling of waypoints (1 to 100 waypoints per trajectory) and allow the PLC to execute these trajectories when needed.

    Current Setup:

    • The trajectory planner computes robot movement paths and sends the data to the robot. These paths consist of waypoints (A1 to A6), and each trajectory has a fixed number of waypoints (currently 10 waypoints).
    • The robot stores these trajectories in its memory, and the PLC can later trigger the execution by specifying the program number (progNum), which determines which trajectory to execute.

    Goal:

    • I would like to modularize the number of waypoints in a trajectory so that the number of waypoints can vary dynamically, rather than being fixed at 10 waypoints. Ideally, I want the system to support 1 to 100 waypoints per trajectory.
    • The planner will compute and send the waypoints, and the PLC will simply execute the trajectory by calling the progNum without worrying about the number of waypoints.

    • Receive something like this where wp_list it's a list of joint (A1 to A6), num_of_wp (1 to 100) is the number of wp in the trajectory and traj_number it's the number of the trajectory.

      RET = EKI_GetRealArray("planner", "Robot/wp_list", wp_list[])

      RET = EKI_GetInt("planner", "Robot/num_of_wp", num_of_wp)

      RET = EKI_GetInt("planner", "Robot/traj_number", traj_number)

    Key Challenges:

    1. Dynamic Waypoint Length:
      • Currently, the system is hardcoded for 10 waypoints. I want to change this so that the number of waypoints can vary from 1 to 100, without requiring any changes to the program code for each new trajectory length.
    2. Executing Trajectories by progNum (traj_number) :
      • The PLC should not need to manage the waypoints directly. It should only provide the progNum to the robot to execute the corresponding trajectory stored in memory.
    3. Efficient Access and Execution of Trajectories:
      • I need a clean and flexible way to store trajectories and execute them dynamically based on the progNum.

    Current Approach:

    Here is the current logic for executing the trajectory based on progNum:

    This approach works well for 10 fixed waypoints, but I would like to extend it to handle a variable number of waypoints, from 1 to 100 waypoints.

    What I’ve done:

    I did this outside of my main code. But I am missing the part where the points are linked to a trajectory number.

    In the end it would be to have a trajectory list which have inside the number of the trajectory, the number of wp and the list of wp.

    Example : traj n°1, 24 waypoints, list of wp [A1 … A6]*24


    I might have taken the wrong way to do it, so I am happy to receive any suggestions as it's currently blocking my development ! :smiling_face:

    Thanks!

  • Fubini June 10, 2025 at 9:19 AM

    Approved the thread.
    • New

    If I'm not mistaken, there is no way to set array size dynamically in KRL. That being said, you can set your array dimensions large enough for your needs and not use some of it...

    Have you tried adding another dimension to your array traj_buffer? You could have one dimension for the trajectory number and one for your waypoints and it would not change your current architecture too much. You could have an array like

    Code
    E6Axis traj_buffer[100,100]

    And when the plc calls program 1, then you loop through

    Code
    FOR i=1 TO num_of_points
	PTP traj_buffer[1,i]
ENDFOR

    This is not the solution I would use, but I think it could work even if it's not the most efficient use of memory... I also don't know how the motion planner handles the advance and the spline motions when the points are not hardcoded and read from an array, it might not work the way you want it to depending on your application.

    I have a somehow similar application, where I have to change program on the fly just before executing them. I generate my programs offline and then transfer them to the robot using the option package DirectoryLoader. You could do something in the same vein and add your new program and modify the calling module to link it at the same time.

    Edited once, last by kovaley (June 10, 2025 at 8:00 PM).

    • New

    correct, KRL does not support dynamic arrays so using arrays large enough is a way to go. and since TS is not showing use of any external axes, it would be more efficient to declare it as AXIS instead of E6AXIS type. also less data is easier to monitor.

    in terms of organizing things for EKI transfer, i like to put anything permanent at the begin, and bulk that changes dynamically at the end of the message. i would hate to scroll through pages of data in search of how many points are in the data that one is sifting through.

    also since AXIS has 6 elements and up to 100 way points are used, that means 6*100=600 REALs. so looping through an array with 9999 elements is excessive.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    • New
    Quote from panic mode

    also since AXIS has 6 elements and up to 100 way points are used, that means 6*100=600 REALs. so looping through an array with 9999 elements is excessive.

    In the past, for situations where the DECL'd size of the array had to be excessively large, I got into the habit of "initializing" the array with a specific nonsense value (like, 99999), before filling in just the elements the next run would use. Then, during the run, the program would bail if the next element read from the array was the nonsense value.

    • New
    Quote from SkyeFire

    In the past, for situations where the DECL'd size of the array had to be excessively large, I got into the habit of "initializing" the array with a specific nonsense value (like, 99999), before filling in just the elements the next run would use. Then, during the run, the program would bail if the next element read from the array was the nonsense value.

    A nonsense value like 99999 is really good as you will get a workspace error in case one of those get thru and is trying to be used. Whereas values like 0 are usually reachable and can result in more or less carnage :kissing_face:

    • New

    ✅ First Draft Working — Dynamic Trajectory Execution via EKI

    Thanks, everyone!
    I now have my first draft up and running exactly as intended. The robot is now capable of receiving and executing dynamic-length trajectories over EKI, with the number of waypoints determined at runtime.

    🧠 Main KRL Program

    TrajExecutor.dat

    Code
    DEFDAT TrajExecutor public
   DECL GLOBAL AXIS traj_buffer[100,100]
   DECL GLOBAL INT traj_length[100]
   DECL GLOBAL INT traj_to_execute
ENDDAT

    TrajExecutor.src

    🔄 Subprogram – Data Reception

    TrajHandler.sub

    📄 EKI XML Configuration

    🐍 Python Example – Sending Trajectory

    📝 Each waypoint consists of 6 joint angles (A1–A6), sent as a flat list.
    ➡️ For 23 waypoints → 138 values (23 × 6).

    This setup achieves exactly what I needed:

    • Trajectory length is dynamic (1–100 waypoints)
    • The PLC only references the trajectory number
    • Storage and execution are cleanly separated and modular

    Happy to receive any suggestions for improving my code if you spot any mistakes.

    Thanks again for the support !

Advertising from our partners