Posts by Fubini

    What are you looking for? Whats the problem you want to solve? $IPO_MODE tells the robot that it is holding the workpiece and the tool is fixed in the workspace. Technically this is achieved by flipping the meaning of tool and base and inverting $POS_ACT.

    Or are you looking for moving simple shifting positions in the tool system? This can be done with the colon operator e.g.

    Lin xp:Shift ; shift in tool

    or with

    Lin_rel shift #tool


    Is it really constant on axis side? Nearly constant maybe. Afaik in newer robots its actually a polynom not a scaling factor. Since curr_act is motor sided to get to axis side you need as panic said gear ratio rat_mot_ax and also axis coupling comes to mind because the hand axes share motors to some extent. If I remember correctly the sign directly relates to the direction, so think of it maybe like the difference of push and pull. Probably also friction effects need to be calculated in when going from motor to axis torque.


    Unfortuntly there is no possibility to check this beforehand. For continous path movements (motions that are not ptp) this is difficult in general because the exact axis positions are created more or less on the fly when executing the motion using a shortest path strategy from interpolation cycle to interpolation cycle. Even though compared to old motion types spline actually plans the trajectory based on a axis spline calculated from the Cartesian geometry this axis spline is only a rough approximate of the exact geometry due to performance issues. So when the velocity profile is created you still can not check beforehand conditions like software limits. What maybe can be done is to activate cp_statmon a monitoring function that checks whether the status and turn at the end position after execution of the spline will be the ones programmed with the target position. So if you would not want to execute the spline set status and turn of the last target in the splineblock to the same values of your preceding ptp and activate $cp_statmon. But I an not totally sure if I remembered this totally correct. The robot might still execute and stop at the end of the spline but you could try it out.


    KUKA does not offer support for such a feature directly. You would need to do the adaptions and corrections yourself using e.g. RSI if realtime correction on the path would be necessary.

    So where exactly would you need to apply corrections. Only at programmed positions or arbitrarily in between taught in positions?


    Also shame on all KUKA customers that want to have backward compatibility for way back 8o . That's the only reason why its not removed. Actually removing it would be quite simple for KUKA. but you would not be able to easily port from controller A where dat-file VEL exists in the struct to controller B where its already removed in the structure declarations. In the past when something similar was done the cry out of important customers was so big that KUKA learned to avoid to get himself in such situations.

    Another strong argument to not change stuff like this is the following:
    The structures you are referring to in the dat-file are intended to be used together with inline forms and therefore addresses people who do not care how internally inline forms are working because they use the HMI GUI menues anyway for their programming as intended by KUKA for this type of users. So they do not need to understand whats going on behind the scenes to get their job done. As said before the robot behaves exactly as expected when using inline forms. The confusion only sets in for the small amount of users that want to use inline forms but also want to understand the behind the scenes. So basically "experts" of some kind. If you would remove the VEL structure you would make the "problem" a concern not only for a few "experts" but also for the vast majority of GUI programmers who do not bother about this stuff as well. And then these would also have to deal with the above mentioned compatibility issues.


    B being roughly at +-90 you hit the Euler singularity aka gimbal lock. Try to avoid target positions where this comes into play.

    Just seacrh for gimbal lock to find explantions. Basically A and C are no longer unique and only the sum of both is a fixed value.


    How well is the robot mastered? How well are tools/bases measured in? Is the robot equipped with absolute accuracy: Is load data set correct? Are you running through a singularty: what singularity strategy do you use? ...

    Can you tell us a little bit more on what you did to get you setup precise?


    Can you extend your request with some data please.

    Whats the programmed velocity for the positioner?

    Whats the programmed velocity for the robot?

    How do you blend with what blending modes?

    Whats the programmed point distances between your LINs?

    How is the addtitional kinematic setup in machine data?

    Are your postions close to singularities?


    The number of possibilities is endless with the very limited amount of info in your questions. At least share a little program that shows how you programmed your jobs.