Posts by rvsh

I thought until today that ADVANCE was only merging robot moves, and the "standard instructions" are executed between these moves and ofcourse advance pointer stops at instructions mentioned in KUKA expert manual as advance pointer stoppers. It was big misunderstunding on my side. Thank you for clarifying this.

From your post I assume that instructions that do not stop ADVANCE pointer are executed in sequence until reaching the move that ADVANCE pointer point at, even that the moves are not executed yet.

CONT is needed to get smooth movement. I will try TRIGGER tommorow. It looks promising. Thank you.

Hi,

I've got a problem. Tested on krc2 5.5.8 and 5.6.10 the same behaviour.

The interrupt 23 in the program below is activated even when robot is on move to XP1. Is this normal behaviour of kuka robots?

I turn interrupt ON AFTER the robot should reach XP1 and still the XP1 is interrupted when the robot is in move to XP1.

I simplified the program to show how I use this interrupt. I added halt to check that the program really going into the ir sub and it confirmed that it goes there even when INTERRUPT is OFF.

Where is the problem? Thank you for any input.

DEF search()
  INI
  $CYCFLAG[1] = $IN[1] AND $IN[2]
  INTERRUPT DECL 23 WHEN $CYCFLAG[1] == FALSE DO irStopRobot()

  PTP $POS_ACT
  $ADVANCE = 3

  $BWDSTART=FALSE
  PDAT_ACT=PDATmax
  FDAT_ACT=FB1
  BAS(#PTP_PARAMS,100)
  PTP XP1 C_PTP

  INTERRUPT ON 23
  MoveP2()
  $ADVANCE = 3
  INTERRUPT OFF 23
END


DEF MoveP2()
  $BWDSTART=FALSE
  LDAT_ACT=Lcpdatmax
  FDAT_ACT=FB1
  BAS(#CP_PARAMS,0.08)
  LIN XP2
  $ADVANCE = 0
END


DEF irStopRobot()
  INTERRUPT OFF 23
  BRAKE
  rPickPosSavedZ = $POS_INT.Z
  halt
  RESUME
END

Hello,

I've got maybe a noobie question but I'm stuck on this. It is also not so easy to explain so please don't be rough.

I need to change TOOL_DATA[2] on the fly regarding which object is gripped on the robot.

The problem is that gripper TCP is not in object middle point. I would like to achieve this gripper TCP = object middle point in X,Y BASE coordinates. Z is not changed.

The data that is known is on the picture attached:

-object length (can change) according to base1 origin taught with robot flange as TCP

-object width (can change)

- var1pos (position of the robot flange TCP in base 1 X) which also can change

- var2pos as above but in Y

My question is what to put into TOOL_DATA[2] to set TCP as middle of the object.

I've added some example dimmension to simplify understanding what algorithm I need.

I would be very grateful for any advice or help.

Robot is on KRC2 v5.5 (KR360).

I checked after reinstallation of krc and the problem is still there so It looks like a software bug or some feature that I don't know about.

I've attached full archive.

Here is the photo of the panel.

As you can see inputs named I_EL_DLU are maped $IN[1] TO $IN[9] (9 bits)

As you can see on the Digital Inputs Monitor the number represented is '111101000' which is 488 decimal.

As you can see on the variable moniutr I_EL_DLU is '10 111101000' which is 1512 decimal.

On the high side is '10' added...

It is added regardless the number of bits I used (tested with 8,9,16 bits)

So when I try to set outputs with the same values as inputs there is OVERFLOW error.

I know I could use AND to get only bits I want but this is not the ideal solution for the problem.

I would like to know the root cause.

Any advice?

Here is the source code - I simplified it to show the case only.

Tested it and still the same results.

Also There at no other programs on the hdd so there is no possible that there is other variable declared as I_el_dlu.

This signal is declared in the selected program dat file.

Skyefire:

Yes it should never be more than 16383 but is is! ('Overflow' error.)

But bit 15 and 16 is not important because If I change range to for eg. 1-8 it is still 10 bits instead of 8.

Why there are always added two bits in the beginning '10'?

Am I missing something?

Btw. All external system inputs are not in range 1-16.

The problem of mapping is that I found this problem when I tried to map I_el_dlu to o_el_dlu where o_el_dlu is $out[1] to $out[16]

Just:

O_el_dlu = i_el_dlu

I get error of 'overflow'.

That's why it is very strange, why there are added some bit in input that give so strange results.

Normally range $in[1] to $in[16] should be equal to $out[1] to $out[16] but the input has additional two bits before MSB `10`.

Yes I tried other ranges from 1-8 to 1-16 and always there are added two bits before MSB '10'.

This is very strange because the same code worked normally on some other robot.

The difference are that this robot had other kss and is safety (which is disabled) and accurate (which I think is not important).

Maybe it is something with unsigned/signed integer but how it is correlated with signal?

Hi,

I have a strange problem.

I try to read 14 bits:

SIGNAL I_EL_DLU $IN[1] TO $IN[14]

I send decimal "1000" to $IN[1-14] by PLC which is '11 1110 1000' binary.

You can see on the picture attached that it is sent ok.

But when I try to read variable I_EL_DLU I received decimal number 33768 which is '1000 0011 1110 1000'

As you can see there is '1' added in the beginning.

I tried other ranges and this '1' is always added.

Why is that? How to solve this? I just want to read the bits I select as variable.

Robot KR C v5.5.13

GUI version: 2.0.6.7 B75

Kernel: KS V5.5.75 RTAcc

#KR2150 2 S C3 FLR ZH150

Please help.

I use it just like this

MSG("example text to show")

1. KSS4.1.7 SP08

DEF MSG(TOSHOW[]:IN)
  INT ANSWER
  INT OFSET
  INT II
  DECL STATE_T STATE
  DECL MSG_T EMPTY_MSG
  CHAR TOSHOW[]

  EMPTY_MSG={MSG_T: VALID FALSE, RELEASE FALSE, TYP #NOTIFY, MODUL[] " ", KEY[] " ", PARAM_TYP #VALUE, PARAM[] " ", DLG_FORMAT[] " ", ANSWER 0}

  $MSG_T=EMPTY_MSG
  $MSG_T.MODUL[]=" "
  FOR II=1 TO STRLEN(TOSHOW[])
  $MSG_T.KEY[II] = TOSHOW[II]
  ENDFOR
  $MSG_T.PARAM[]="PARAM"
  $MSG_T.PARAM_TYP=#VALUE
  $MSG_T.TYP=#NOTIFY
  $MSG_T.VALID=TRUE
END

If I do for example "for II=1 to 4" then it works fine if toshow length is 4 or more.

"Name not declared as function"

StrLen not declared as function

Any Ideas why?

If I just change line 12 to

$MSG_T.KEY[]="my message"

It works ok.

But I want to add it from array/variable.

Could you help?

Hi,

I would like to assign an array (string) to another array but I got error information that " right side: array invalid"

I tried many combinations and I can't find the right syntax.

Could you help?

Here is the sample code:

DEF MSG(TOSHOW[]:IN)
  INT ANSWER
  INT OFSET
  DECL STATE_T STATE
  DECL MSG_T EMPTY_MSG
  CHAR TOSHOW[]

  EMPTY_MSG={MSG_T: VALID FALSE, RELEASE FALSE, TYP #NOTIFY, MODUL[] " ", KEY[] " ", PARAM_TYP #VALUE, PARAM[] " ", DLG_FORMAT[] " ", ANSWER 0}

  $MSG_T=EMPTY_MSG
  $MSG_T.MODUL[]=" "
>>>  $MSG_T.KEY[] = TOSHOW[] ; HERE IS THE ERROR (I CANT ASSIGN TOSHOW[] TO KEY[]) <<<
  $MSG_T.PARAM[]="PARAM"
  $MSG_T.PARAM_TYP=#VALUE
  $MSG_T.TYP=#NOTIFY
  $MSG_T.VALID=TRUE
END

Hi,

Last code works ok. Just C_PTP and moves are blended and interrupts are on. Thank you Panic Mode.

TRIGGER doesn't work - there is an error that INTERRUPT ON must be placed on new line.

Thanks for help

I will try if the code works with blended moves. If not I will try to use TRIGGER - that looks like very good idea - Hadn't thought about it this way. Thanks DannyDJ!

Panic Mode - I know how advance run works and I need to use interrupts. I don't know any other more effective solution to stop at search path. Still I learned something - thank you. I read a lot of your answers on forum and you helped me many many times even that you didn't know it

$stopnoaprox isn't a solution - message is not important - not blended moves are.

I will publish results tommorow.

So you are saying that adding simple C_PTP (line 22) like below will do the job and all moves will be with approximation (no "approximation not possible error")?

INTERRUPT DECL 21 WHEN $CYCFLAG[1] == FALSE DO IR_MOVESTOP()
INTERRUPT DECL 22 WHEN I_HSENS == FALSE DO IR_MOVESTOP()

go to pick pos but dont change z
;FOLD PTP F_MOVE2 Tool[1] Base[1]
$BWDSTART = FALSE
PDAT_ACT=PPDATMAX
BAS(#PTP_DAT)
FDAT_ACT=FB1
BAS(#FRAMES)
BAS(#VEL_PTP,100)
PTP F_MOVE2 C_PTP
;ENDFOLD

;FOLD PTP F_PICK Tool[1] Base[1]
$BWDSTART = FALSE
PDAT_ACT=PPDATMAX
BAS(#PTP_DAT)
FDAT_ACT=FB1
BAS(#FRAMES)
BAS(#VEL_PTP,100)
PTP F_PICK C_PTP
;ENDFOLD

;**********************************************
;******** LIN F_MOVEDOWN **********************
;**********************************************

F_TEMP.Z = 0
INTERRUPT ON 21; $CYCFLAG[1]
INTERRUPT ON 22; $I_HSENS
MOVEDOWN()
INTERRUPT OFF 22
INTERRUPT OFF 21
$ADVANCE = 3

DEF MOVEDOWN()
;FOLD LIN F_MOVEDOWN
$BWDSTART = FALSE
LDAT_ACT=LCPDATMAX
BAS(#CP_DAT)
FDAT_ACT=FB1
BAS(#FRAMES)
BAS(#VEL_CP,0.3)
ENDIF
LIN F_MOVEDOWN
;ENDFOLD
  $ADVANCE = 0
END

;********* INTERRUPT FROM SENSORS**************
DEF IR_MOVESTOP()
  INTERRUPT OFF 21
  INTERRUPT OFF 22
  BRAKE
  F_TEMP = $POS_INT
  RESUME
END