Posts by robotecnik

If you've got a HA accuracy robot you should have smaller than 1 mm errors in all the working range. (Not a constant error but at max 1 mm).

That will be possible if the bases and tcp's are correctly done.

You can always do the mastering, some times transportation ends with small errors that a mastering solve.

You could try to make the tcp by calculus. When your robot is precise sometimes is even better doing it that way.

If everything fails, you can always call kuka tech support (if you have the robot under warranty) or try to contact metrology companies who could recalibrate the robot for you.

Regarding this last point, the HA robot is calibrated to himself, therefore any external adjustment in the base, tcp, artificial vision, sensors... Can decrease this precision.

With a HA robot you can be sure the precision will be under 1mm.

If yoiu recalibrate it you can achieve 0.3 (which is the best I've ever seen with a robot).

Hope this helps!

Sent from my BlackBerry 9300 using Tapatalk

What 0lda says is correct. ABB robots have a battery set in their base to remember the robot arm position during shut downs. Typically this battery can last around two normal usage years.

What "kills" faster that battery is having the robot without electrical power (holidays and so).

It's really easy to change, but you will need to remaster the robot.

Good luck!

Sent from my BlackBerry 9300 using Tapatalk

Eureka answer is perfect, As always, I just wanted to add that you could use them also for testing purposes.

Sent from my BlackBerry 9300 using Tapatalk

I'm far away from the computer and I don't have any code now to check it... But I would use connect (I think it was the way to start an interruption) to check the state of one of those digital inputs. You should use that interrupt (which at the end is a function that gets executed as if it was multitask) to check the states of those inputs and activate the outputs accordingly...

Sorry not to be able to give you a better answer but from the phone and without manuals or old code to check...

Sent from my BlackBerry 9300 using Tapatalk

Probably your best options are:

1. Use interrupts to detect any input value change. Once you are inside the interrupt handler check both signals and react in consequence.

2. Use your plc (if any) to do this output logic.

Hope this helps!

Sent from my BlackBerry 9300 using Tapatalk

Can't you simply choose *.* in the file pattern and then write the .mod by yourself?

I'm using ultraedit and never used notepad++ so I can't be sure of that, but at the worst, you should be able to store it as any mime type and then rename it.

Sent from my BlackBerry 9300 using Tapatalk

I can think of two solutions:
You can use the submit program (sps.pro) to do that for you (which is not the best in terms of speed but it is the best in terms of flexibility).

You could also put an extra software layer there by using a beckhoff controller and do that inside the PLC logics.

Both options are very similars, but the first one is free.

Good luck!

Sent from my BlackBerry 9300 using Tapatalk

In theory it is not possible to decrypt those files. At least this is what ABB explains and the only reason why somebody would spend money on that encryption software.

Sent from my BlackBerry 9300 using Tapatalk

Any links or advices on how to avoid problems related to the Gimbal lock?

I've been calculating the orientations using quaternions, and given that I'm getting much better results than with Euler angles, but anyway I'm getting strange behaviours when facing a singularity (A4,5 and 6 aligned).

Any examples, manuals, interesting tips... to handle that?

Thank you in advance!

The rumors you've heard are true: robots are repetitive, but not precise.

In any Brand you can get more precise robots by paying a little bit more (high accuracy, absolute accuracy...) those “ultra-precise” robots can get typically precisions of 0.3mm (this is the best you can get and the bigger the robot is the worst precision you’ll get).

Due to the specific construction shape of the robot which all the axis are rotary, the robot can't be more precise than that.

There are external companies that calibrate robots. They are expensive and keep in mind that you won’t get better results than 0.3mm.

When you teach the points, you are "solving" the precision issue automatically as the robot don't mind if the real position versus the software position are correct/equal.

Anyway, I must tell you that with KUKA I've got very good results with normal robots. i.e. it's quite normal to program a robot in our factory and send it to our customer and need to retouch a lot of points to adjust the part program. With KUKA this has been minimized a lot.

Don't think on a constant formula to solve the error issue, the amount of error is not constant in the space as it depends completely on the robot gearboxes and arm torsions, which change depending on their position.

If you need a lot of precision teach is the best, in the other hand, you can always use a correction array in which you can allow the user to apply a correction in a specific array position and before making any movement add the user correction to the calculated point:

calcpoint [x] = calpoint[x] + userarray[x]

If userarray is 0 then no addition will be performed and so…

Anyway, test it and take measurements, probably you won't need this amount of precision.

Good luck!

I don't remember it now, but probably you will need to perform a cold start to activate the value modification.

Good luck.

Try to edit the /KRC/ROBOTER/INIT/MEMCONFIG.INI file.

Modify the variable "miniumal physical page".

Initially that variable value is 10.

I don't know why, but KUKA tech support once told me to update it in steps of 10 units.

So the next step should be 20, the next 30...

Try it and come back with the result

You can always use a CIRC_REL, just this afternoon I've been having problems with the very same thing until I've found this:

http://webcache.googleusercont…l+kuka&cd=3&hl=en&ct=clnk

check it, it is in the roboterforum (which is almost the same than this one but in german and only available for germans I think). That is why it is from google cache... because I've not been able to reach it...

All In all this should help you to calculate easily the circle.

Good luck!

Thank you for your answer Skyefire, I've started again to check the program.

Note: believe it or not in the KUKA tech support told me that each IF clause stops the flow and that therefore I needed to put a continue just after each one.

Apart of that I've found some logic on the problem:

The second function can be called in two different situations: with the robot in movement or with the robot stopped. This made me to design the logics in the following way:

IF ($PRO_MOVE) THEN
  TRIGGER / DISTANCE...
ELSE
  PULSE
ENDIF

I've put a halt just after the TRIGGER/DISTANCE (to check if the program was going there or not).

The external code (the one who calls the second function) is something like:

LOOP
PTP 1
Function2
PTP 2
PTP 3
ENDLOOP

My surprise has been big when I've seen that some times the robot got stopped at the halt and that sometimes it was not getting stopped (therefore the normal PULSE was being called).

That's really strange, I've finished solving the issue putting a simple CONTINUE before the normal PULSE, but that is (at last) strange.

Pointing me to the manual has been great, I've noticed that asking for internal/system variables stops the movements, therefore I've also put the continue before the first IF clause (where the $PRO_MOVE var is being checked).

At last everything will work as expected.

Thank you all for your help and comments.

I've found a way to make it work as expected:

Writting CONTINUE before and after ANY program line inside the first and second functions... This is probably the ugliest thing I've seen for a long time...

CONTINUE
code
CONTINUE
code
CONTINUE
code
CONTINUE
code
CONTINUE
code
CONTINUE
code
CONTINUE
...

Do you know if I can activate some kind of global continue? I mean, I'd like to activate it before executing those functions and deactivate it again just after the functions have finished their job...

It should be something like:

GLOBAL_CONT_ACT
code
code
code
code
code
GLOBAL_CONT_DEACT

Thank you in advance

Thank you for your answer Eusty, but I'm afraid it reacts exactly in the same way. I've just made the test now (I've copied the content of the function inside the second SRC and pasted it directly where that function was called) and no change...

Hello all,

I'm trying to get an output ON without stopping the robot.

Of course I'm using

TRIGGER WHEN DISTANCE=0 DELAY=0 DO PULSE(ADO_bU21LiquidPApply,TRUE,0.5)

to get it done, but there are some conditions before that must be observed, therefore, I have some IF clauses and a couple of function calls prior to activating the output itself...

In pseudocode the logic flow is the following one:

; IN THE SAME SRC FILE THAN THE USER POINTS/PROGRAM
DEF UserFunction(iP1,iP2)
 INT iP1
 INT iP2


 IF (iP1==0) THEN
    HALT
 ELSE
   SWITCH iP1
    CASE 2
      IF(Global_bool_var)THEN
       IF(MOD(Global_int_var,iP2)==(iP2-1))THEN
         fxThatMakesThePulse(100)
       ENDIF
      ENDIF


    DEFAULT
      HALT
   ENDSWITCH
 ENDIF
END


;IN ANOTHER AND GLOBAL SRC FILE
GLOBAL DEF fxThatMakesThePulse(iT)
	INT iT


	  IF (iT == 0)THEN
	    TRIGGER WHEN DISTANCE=0 DELAY=0 DO PULSE(ADO_bU21LiquidPApply,TRUE,0.5)
	  ELSE
	    TRIGGER WHEN DISTANCE=0 DELAY=0 DO PULSE(ADO_bU21LiquidPApply,TRUE,m_iT/1000)
	  ENDIF


; Something will be handled in the SPS after a while...
  $TIMER[3]=0
  $TIMER_STOP[3]=FALSE
END

Of course, if in the main program I'm using the TRIGGER... call directly the robot is not stopping.

I would like to be able to keep the different functions and so in my logics in order to separate the physical inputs and outputs from the logics.

I've tried placing a continue just before any of the IF clauses present in the code with the same result...

Any idea or hint?

as always thank you in advance.

I've found a solution (not the best one but it seems to work):

I've filtered the question using $PERI_RDY, now the touchup question will only appear when the operator will have the deadman switch pressed therefore, during a copy operation which normally happens without that, no question will pop up.

Thank you all for your time and answers.

Good morning Skyefire,

It fails in both states, but in different ways:

PREVIOUS NOTES ABOUT THE FOLD
In that "super" fold I'm making an automatic touch up, which means that I'm getting the POS_ACT and assign it to some fields of that fold. I'm creating a fold that's similar to a LIN, PTP movement with speed, base, XYZABC and some other fields.

If I'm opening the fold for first time I'm getting the POS_ACT and assigning it directly to the fold (like when you make a LIN in which all the XYZABC get updated automatically at the creation moment).

If I'm modifying the fold, then a question appears asking if I want to touch up or not, which is wonderful as it helps the user to avoid touching up (one extra step).

That fold is used to automate some robot path movements.

Then, going back to the problem and behaviour:

A) IF I'VE OPENEND THE FILE (NOT SELECTED IT)
The inline form is not working as the robot is not aware of POS_ACT.
In the notification area reads "invalid inline form".
The PASTE operation fails.

B) IF I'VE SELECTED THE FILE
When the inline form is about to get pasted then the question appears and fails.
The problem that I'm trying to avoid here is that when the fold is being pasted that question appears and therefore nothing is being pasted beyond that point.
Of course this is a big issue as the customer gets fooled by the system and can make the robot to collide.

Can you imagine some way to arrange this?

Thank you very much in advance.

Hello Mookie,

KRC2 5.x.

Do you have any manual or link that I could follow to get more information regarding those DLL's and about the procedure you are suggesting?

I would not like to install a system wide hook and then having to capture events inside the robot programming system.

Thank you.