Next movement position lookup

    Hello fellow wicked people,
    I need a way to look up an upcoming position(s) in the program while the program is being executed. E.g. a program part that looks like this:


    $advance=3
    ptp {x 1000, y -980, z 1360, a -15, b 3, c 43, s 6, t 50} ; p1
    lin {x 1300, y -980, z 1360, a -15, b 3, c 43} ;p2
    lin {x 1300, y -380, z 1360, a -15, b 3, c 43} ;p3
    lin {x 1300, y -380, z 1060, a -15, b 3, c 43} ;p4


    Is there a way to read from some system variable or to write to a variable pos of p2 while the robot is moving to (p1)? How about if it's already at p1 and moving to p2? In other words, where the robot is planning to go, BEFORE it gets there. I am hoping for something simple like $pos_act (which gives the current pos of #tcp).
    Some other ideas for tackling this:
    1. Advance pointer outputs (if that's even a thing).
    2. Parse the current running program with sread and krl_fgets and try and interpret that. Very roundabout and complicated when functions appear in the code or there is a tool or base change or commented lines. So, I would rather not go this way.
    3. Put all the positions into struct (movetype, pos) arrays and execute them in a cycle. A bit backwards, but would work. Looking for something easier and/or not changing current code structure.
    4. Some other option I haven't even considered yet. Open to suggestions! :icon_neutral:


    Edit: Using KRC 4 and KSS 8.3.37

    Edited once, last by Mentat ().

    What is your reason for wanting this. the way i see it is you have the data (it is on the next line) but where or what for do you want it for.
    if you can give a specific reason some people here might have better or different idea's on how to do what you want.
    Also it would be nice if you specify your system as is stated in the "read first" topic. programming vary's a lot between different versions of kuka software

    Every problem has a solution, that isn't the problem. The problem is the solution.

    I want to use the data for avoiding (wrist) singularities: there is an option to angle the tool(s) by up to 7 degrees and usually that would be enough to avoid singularities before the robot gets to them. If the movement is linear, I would chop the line into 20mm blocks and check for near singularities (with INVERSE()) in each one. Then, if robot sees that the movement it's going to make will result in a singularity, it could angle the tool a little by allowed angles (say, it can angle the tool only by the tool's b angle, but not others).


    I am unaware of other methods for doing this, except for simulating (or calculating inverse kinematics of) the program before it is uploaded (not always an option). Simulating and the like would also work for one specific robot in specific base with specific tools- a lot more crud for what could be done simpler.

    The link to the post you gave me is maybe useful, but from what I understood, it discusses ways of dealing when the robot goes into the singularity. Slowing down with $CP_VEL_TYPE=#VAR_ALL could be used in some applications, but it others I need a constant and preset velocity while still requiring the tcp to stay on the specific trajectory.
    What I would like to make is some function running in Sub() that would let the robot avoid the wrist singularity all together (by changing the tool attack angle a bit for the movements that would otherwise cause a singularity).


    Is there really nothing like $pos_next, $pos_fin(nish) $target or the like? (I tried these of course).

    $POS_FOR, but IIRC it only contains valid data during PTP motions.


    You can use the INVERSE system function to convert a Cartesian position into an equivalent set of axis angles, and perform pre-checking on the axes that way.


    Part of the issue here is that, since you're using LIN motions, you could easily have a motion whose end point is singularity-free by a healthy margin, but which crosses through a singularity partway through. That is not going to be solved predictably.

    Quote from SkyeFire


    $POS_FOR, but IIRC it only contains valid data during PTP motions.


    You can use the INVERSE system function to convert a Cartesian position into an equivalent set of axis angles, and perform pre-checking on the axes that way.


    Part of the issue here is that, since you're using LIN motions, you could easily have a motion whose end point is singularity-free by a healthy margin, but which crosses through a singularity partway through. That is not going to be solved predictably.


    Indeed $pos_for is for ptp motions and approximation end point.


    The plan for LIN motions was to chop it up into 20mm or so lines and check their endpoints for near singularity with INVERSE() (if A5 at that point is near +-0.5 degrees, angle the tool for the whole lin movement).


    For now I will put the movement positions into array(s) and use those. It's ugly, but should work.


    Unless anyone could suggest a more elegant solution?

    I rather like using arrays of E6POS. But I'm widely regarded as being a bit strange. :stupid:


    Part of the issue here is the look-ahead. You can't move smoothly through multiple points without it, but it means that your checking function would have to stay ahead of the main run pointer by at least $ADVANCE+1. Otherwise, changes to $TOOL won't take effect in time.


    If you have a simple alternative Tool, your best approach might be to pre-check an array section, then dynamically change tools beforehand (also making the advance run work for you). Something like:


    With the Advance Run, the entire "checking" FOR loop could be complete well before the Main Run catches up.

    Quote from SkyeFire


    I rather like using arrays of E6POS. But I'm widely regarded as being a bit strange. :stupid:


    Part of the issue here is the look-ahead. You can't move smoothly through multiple points without it, but it means that your checking function would have to stay ahead of the main run pointer by at least $ADVANCE+1. Otherwise, changes to $TOOL won't take effect in time.


    Heh, I meant "ugly" as in limited to only movement commands for those parts of the code and unintuitive and more difficult to read/debug later if/when something goes wrong. I haven't yet considered approximate positioning when doing things this way, but it should still work.

Advertising from our partners