Posts by El_Mo


    Many thanks again Fubini and Panic for your patience and explanations about calibration.

    So the actual calibration process seemed to work enough.
    I grabbed the idea of clock gauge and created an adapter (see figure).


    While gently pressing the rod a mate performed slowly movements. While doing so i was looking for the bottom of the "V". After this, my orientation is kept well now and I can live with that. So indeed the assumption in post #31 was right. My KUKA was everything, but not calibrated.

    I recorded a short video clip for further documentations here (company), where you can see the current array-like movement. My belonging code file is also attached. This code exactly leads to trajectories shown in the inked video file.


    In this run, I span a workspace area of 1400 mm in X by 2000 mm in Y and tested this with a 8 by 3 grid.

    So my "interface" in *.src file is this..

      ;IMPORTANT user's input here:
    gridWidth = 1400.0 ;geometrically width of workspace area in [mm]
    gridHeight = 2000.0 ;geometrically "height" of workspace area in [mm]
    tPulse = 0.5 ;output pulse duration in [s]..
                 ; measure inductive voltages (used in function call)
    nRow = 8 ;grid's height (number of rows)
    nCol = 3 ;grid's width (number of columns)
      ;IMPORTANT user's input end

    Here i define my area and the number of rows and cols. The rest will be done automatically with state ments as:

            IF (row == idxDragE) THEN ;"drag E1 to enlarge Y-workspace" functionality
              nextP.Y = nextP.Y + yStep ;
              nextP.E1 = nextP.E1 - yStepE1 ; 
              LIN nextP ;
            ELSE ;regular Y-step functionality
              nextP.Y = nextP.Y + yStep ;
              LIN nextP ;

    Critically grid elements for singularity are those, where the KUKA's wrist is near the external linear axis.

    in this shown combination of rows and columns there was no singularity issue, even if it looks like (in video).

    Next i will successive increase the number of rows and cols and when singularity occurs, I can try those approaches you guys gave here.
    I am optimistic.

    - First I would try to place $CP_VEL_TYPE to #VAR_ALL at appropriate position in code.

    - Second I would try to avoid CP motions in this critically spots (maybe i can hold flange's orientation anyway).

    - Third I would try to keep external axis far away of momentary row, so the robot would always have to lean over more to reach momentary grid point

    So the first part/issue of array-wise movements is solved (orientation).

    The second part/issue (singularity) is not done so far.

    UPDATE ends


    I totally agree to you :)
    I also also got frustrated about this many times, thus reading this above was my personally "lifesaver" and i got a lot of endorphins yesterday =D

    Technically I am with the point "reading manuals", but those manuals I read before (hint/glance to "our" other thread, where you helped me) should make those essential information "jumping in your eye".

    So far, i didn't found such a well commented/explained hint like i now got here from you guys.

    ... probably because one doesn't know what phrases to look for until one found it :P (if one is new and not familiar within in a new topic)

    That's most likely because you're trying to edit the code while the program is SELECTED rather than OPENED. IF statements cannot be edited while the program is running in the robot interpreter. Cancel the program. Open the file, rather than selecting it, and you should be able to edit as you wish.

    Jeeeeeesus, i was looking for so long for the reason of that behavior.

    i really thank you very much !!!

    you saved all my future/upcoming progression :)


    I have another short question.

    I'm using a 2nd-hand KUKA with KR C2 cabinet and the robot is mounted on an external linear axis.

    Is it possible to actively enlarge KUKA "oh i move to my destination point automatically"-workspace?

    What does that mean?

    Assumed the robot (without external axis) can reach every point within a sphere (technically a "donut") about 2 m around it's center.

    If one is saying "move to 1,1,1,2,2,2", the robot automatically use his 6 axes and move to this point.

    If one would say "move to 4,2.5,1,2,2,2", the robot would say "x is out of scope"

    Now with external linear axis in Y, the possible workspace is enlarged to a "bean".

    Is it possible to say "move to 1,7,1,2,2,2" so the robot will automatically using external axis to reach that point.

    So far i always have to drag external axis by hand with E6Pos. I would like to get the KUKA using it automatically.



    You are aware that the marks are not in mastering position. They only show where a mastering movement should start. You could reach better results even without mastering tool from KUKA by using a pen or a measurement clock/dial gauge. This has been explained many times in this forum.

    okkkkaaayyy =-)

    "of course" this is new to me. i kinda think, it's difficult to know/search something, that you/one don't ever minded to look for.. so far ^^

    but yeah, i will check it out. until now, i just thought, one only can adjust the robot properly, if one has got certain tools

    thank you very much for your hint

    Now the "slightly misalignment" means,..

    - when i move the robot to grid points, which are "right hand-side" of centered position (A1 = 0), the level gauge is on end (a)

    - when i move the robot to grid points, which are "left hand-side" of centered position (A1=0) , the level gauge is on the other end (b)

    Am i right / could i be right, when i now assume, that is because of not using EMT or another reference to adjust the robot's world frame.

    I assume that this remaining symmetrically misalignment of flange's orientation probably is, because i cannot adjust robot via tools.

    Hi there,

    since weeks of doing another things, i finally could get back to my kuka work. Sorry for not answering anymore.


    But anyway, also with this small bugs, the orientation should be constant in your program.

    Does the robot tcp stay still when you move the robots external axis when world coordinates are active?

    Technically this is good to hear, since I'm also convinced, that it should work.

    Q: Does the TCP stay still while E1-moving?

    A: Yes, it stay where it is (visual inspection and "actual position view/window).

    Now, i gave another try to mimic expert programming codes of expert programming guide (..and i guess thus some earlier comments of you guys aka "that's not expert programming so far" occurred).

    I'm referring to attached *.pdf and it's page 76.
    One can see example code of a constant-orientation-movement.

    Now i created a new file via NEW - FILE - EXPERT not via NEW - FILE - MODULE and typed

    And now i think, this is theoretically working.

    The flange's misalignment seems to be way lower as before (visual inspection).

    Indeed, when I'm putting a (bubble) level on flange, i can see, that flange is not staying horizontal, but i think, this is because we don't have a calibration tool to set the correct adjustment.

    We only can adjust the robot with "keeping it's white marks aligned in HOME position" (thus visual).

    grml .. it is still not working

    strongly simplified:

    1. hint:

    use .dat to declare and set globals

    -> since it's just a basic run and a massively flat program hierarchy, i technically don't need to do anything with .dat

    2. hint:

    use init area to set and declare

    -> since this is crucial, i placed vel_axis and acc_axis and ori_type in init area.

    -> since in this test scenario i dont care about the path between grid points of interest, S and T are untouched and ptp_rel was used

    -> result: movements and velocity are proper. trajectories with ptp_rel commands lose flange's orientation not only in the path even at the grid points

    3. hint

    use ori_type in combination with cp-commands, so e. g. lin_rel

    -> since i still dont't care about the flange's orientation while moving to a grid point, S and T are still untouched

    -> result orientation i grid positions is still broken

    i don't get it...

    with a super simplified code example, where i don't care anything but flange's orientation on start and end point and using x-y-movement command, one have to be able to get this fu... flange in correct position. what the hell.

    i don't care, what is between the grid points. even, if robot would jump off external axis and would start to dance, when the "tcp" reaches target grid position and the flange is horizontal again, i would say "ok, i can improve the in between"

    ggggrrrrr, jesus.. i just want to reach this.. even without keeping in between orientation

    can it be so hard ....

    yep, yep, yep, ... you are right again. now when you are saying / describing this, i remember some lines in expert programming guide..

    Also that ori_type correspond with cp-motion i can read out (see page 70 in expert programming guide krc2). Not really bi-unique but in any case present.

    So again, i really thank you for your hints and i will try to change it now.

    hey panic,

    first of all, i wanna really thank you for your patience and engagement.

    although you said that you don't have time in this regard, but then you kindly took the time to give detailed tips.

    recently i was a week off this kuka-project-issue, so i unfortunately can't working full time on it.

    further, you are right ... i did not enjoy any kuka krl lesson or stuff like that. the task is, that we wanna use te kuka to help us calibrate our system but do not have any human or financial resources to do this thing "right"

    so technically i won't getting really better in coding krl without especially tips like those from you guys here

    so yeah, obviously i misinterpreted the initializing thing of krl and the deeper links and meanings of inline coding and expert coding. but at this point, unfortunately i actual can't do anything like read my gathered pdf's and try to adapt those code examples..

    edit: jesus, text below the pic was dropped >.>:

    ...but honestly i think, those are not super documents at all or maybe i cannot get my wanted information between the lines.

    well anyway.

    yesterday i gave the kuka another 15 min and tried to fix those parameter placement. i put velocity limitation loop and $ori_type - parameter, technically to keep the orientation of the flange, right in the default init section.

    so far the velocities immediately started to work. the ori_type-thing did not. the plain x-y-trajectories near the linear axis are still massively changing flange's orientation. i hope, that today i can experiment with placing setup commands in xxx.dat-file, as you mentioned. maybe there is another ori-type-command, which overwrite mine from init section. i don't know.

    so i wanna thank you again and will keep you guys updated. so far my issue is not gone. kr c2 is still not behaving as in my simulation video (posted on top)

    have a nice day/night :)

    space has nothing to do with it. inserting spaces before or after equal sign makes no difference unless you exceed maximum line length (2047 char).

    ok panic,

    i cannot discuss this at the same level as yours,... i'm lagging that skills, but after i changed this "space-thing", i was able to keep $ORI_TYPE = #CONSTANT in my program.

    the negative part of this is, that this advice by kuka didn't changed the orientation problem at all.

    i set up another simplified array-like movement as shown in my video file published on top. this time i successfully could T1-run it without sticking in a singularity and without getting the 208 % velocity error, but i guess only because i didn't stopped at such critically point/location
    ( so: postponed is not canceled, i quess ).

    i tried to visualize the orientation issue in the attached figure

    You need to change it in custom.dat. Not in the robot program.

    this is a quit good hint, especially because i cannot find such advice in a manual ^^

    i just got a call-back by the helpful kuka support employee:

    he also said,..

    - some variables/parameter you can change on the fly in expert or inline code

    - some of them, it's better to set in init-area

    - some of them better get changed in storage's file

    Another really good hint of him is:

    because those parameter work with ENUM variables, i should advoid writing like..

    " $ORI_TYPE = #CONSTANT ; nice comment here "

    , because the space can/could brake the ENUM detection and this could be the reason, why i got "expected another name" failure

    so i will further give all hints a try now and notify you here :)

    thanks in advance

    good morning @all,

    i found a CP_VEL_TYPE = #CONSTANT line only in custom.dat only.

    i recently edited my kr c2 program and tried to run those PTP-series.

    when i hit the CP_VEL...-line, i'm always get an error, that this parameter is write protected =-(

    if that wont work as well, i will sit down and think about a geometrical flange adapter to carry my secondary coil side device.

    i will test, how much angle between "tool" and wrist i get, when i move the flange to most, center and least displacement. technically then i just need to realize, that the adapter's angle is bigger, so i will never get A4, A5, and A6 in a line. i hope this will work and it will still has enough clearance / travel, to reach all of my grid points i the same run

    You can not change cp_vel_type in program. Its treated as machine data. If i remember correctly its in $ custom.dat.

    With ori_type it should be #constant not #const probably.


    Yah, thanks for that hint.

    it was a typho. i remember, that i tried both on Friday evening and both didn't work :(

    i will give hes' advice an attempt and will place "$CP_VEL_TYPE = #VAR_ALL" in my init section in my kr c2 code on tomorrow morning