Posts by El_Mo

UPDATE:

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.

my_nextcloud_link

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]..
             ;..to 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 ;
        ENDIF

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

panic,

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 (if one is new and not familiar within in a new topic)

Quote from Metalikooky

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

thanks for the quick reply g2k

Hi!

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.

possible?

regards

Quote from Fubini

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.

Quote from hermann

...

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

&ACCESS RVP
&REL 127
&COMMENT oritype
&PARAM TEMPLATE = C:\KRC\Roboter\Template\ExpertVorgabe
&PARAM EDITMASK = *
DEF cal_array_v9( )

;----- declaration section -----
EXT BAS (BAS_COMMAND: IN, REAL: IN)
DECL E6AXIS HOME
INT cnt, row, col, Nrow, Ncol, veloRate, accRate, tPulse
DECL E6POS yStep, newLine, yStepE1
 ;SIGNAL RasPi $OUT[19] ;not used yet

;--- initialization section ----
BAS (#INITMOV, 0) ;use BAS.SRC init routine
                  ;so default values to all important system vars
HOME = {E6AXIS: A1 0, A2 -90, A3 90, A4 0, A5 0, A6 0, E1 0, E2 0, E3 0, E4 0, E5 0, E6 0}
 ;to move one grid increment in Y:
yStep = {E6POS: X 0,Y 666,Z 0,A 0,B 0,C 0,E1 0,E2 0,E3 0,E4 0,E5 0,E6 0}
 ;to move back to first row but next column in grid
newLine = {E6POS: X -400,Y -2000,Z 0,A 0,B 0,C 0,E1 1000,E2 0,E3 0,E4 0,E5 0,E6 0}
 ;to pull external axis to get more Y-range
yStepE1 = {E6POS: X 0,Y 666,Z 0,A 0,B 0,C 0,E1 -1000,E2 0,E3 0,E4 0,E5 0,E6 0}

cnt = 1 ;loop counter variable
row = 1 ;row index
col = 1 ;column index
Nrow = 4 ;total row number
Ncol = 3 ;total column number
veloRate = 10 ;max velocity in [%]
accRate = 10 ;max acceleration in [%]
tPulse = 1 ;pulse duration in [s]

 ;RasPi = FALSE ;initialize digital output / not used yet

$BASE = $WORLD ;init. base-CS to world-CS (mandatory if using FRAMES)
 ;$TOOL = tool_data[7] ;it's like $NULLFRAME / not used yet
$TOOL = $NULLFRAME ;lay TCP into robot's flange
 ;$ACT_BASE = 10 ;to show actual values.. / not used yet
$ACT_TOOL = 7 ;..in actual position-view


;-------- main section ---------
PTP $POS_ACT ;BCO run / initial SAK-motion
             ;to make the first move/point unique (= quick fix)

FOR cnt = 1 to 6 ;limit axis kinematics fot PTP(!?)
  $VEL_AXIS[cnt] = veloRate ;[%] max speed
  $ACC_AXIS[cnt] = accRate ;[%] max acceleration
ENDFOR
PTP HOME ;move to HOME 
PTP {A5 25} ;turn flange a little around Y (advoid singularity)
            ;then move to grid-start point

$VEL.CP = 0.3 ;set travel speed/acc of continuous..
$ACC.CP = 0.3 ;..path motions in [m/s] and [m/s^2]
              ;CP-move to actual first grid-position

LIN {E6POS: X 2250,Y 2850,Z 1100,A 174,B 3.7,C 179.6,E1 -3350,E2 0,E3 0,E4 0,E5 0,E6 0}
LIN {E6POS: X 2250,Y 2850,Z 650,A 174,B 3.7,C 179.6,E1 -3350,E2 0,E3 0,E4 0,E5 0,E6 0}

$ORI_TYPE = #CONSTANT ;fixates flange's orientation
                      ;for further movements/trajectories
FOR col = 1 TO Ncol ;actually grid-wise movement from here
  FOR row = 1 TO (Nrow)
    IF (col<>Ncol) AND (row==Nrow) THEN
      LIN_REL newLine
      outputPulse(tPulse)
    ELSE
      IF (col==Ncol)AND (row==Nrow) THEN
        LIN {E6POS: X 1850,Y 3850,Z 1500,A 174,B 3.7,C 179.6,E1 -3850,E2 0,E3 0,E4 0,E5 0,E6 0}
      ELSE
        IF (row==2) THEN
          LIN_REL yStepE1
        ELSE
          LIN_REL yStep
        ENDIF
        outputPulse(tPulse)
      ENDIF
    ENDIF
  ENDFOR
ENDFOR

PTP HOME ;back to HOME

END

DEF outputPulse(tIn:IN)
 ;sub-module to "outsource" the output pulse control
 ;increases readability of main-routine
 ;will be "function called" at every array's grid position

 ;DECL BOOL mySigIn ;not used yet
DECL INT tIn

PULSE($OUT[19],TRUE,tIn) ;generate output pulse
WAIT FOR $OUT[19] == FALSE ;waiting for reset to carry on
WAIT SEC 1 ;debugging

END

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).

src file

even on page 76 of attached expert programing guide, there is a code snippet and there the damn orientation keeps constant ....

... and they are using ori_type OUT of init section and in ILF-code ....

i am frustrated...

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, nice...now 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

and here is the belonging *.dat file

note: such rudiments of former kuka device usage of another persons as tool names "hrc..." i don't really care. so far i'm not really familiar with setting tools and changing TCPs on KR C2. so i left this as before

so here is my KR C2-code which recently successfully ran the 5 x 3 test grid and pulsed an output (this output i will use to trigger an induced voltage measuring on secondary side)

Quote from panic mode

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

Quote from Hes

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

Quote from Fubini

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.

Fubini

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