Posts by ktmf

Hi all,

I've been keeping track of the mastering of my KuKa robot since I did a mastering in febuary. I think I can be fairly certain that the mastering indeed drifts slightly over time. I'll show why I think that.

I mastered the robot in febuary. I did a mastering check (with a dial gauge) in april. My results then were

Axis 1: +0.01°, +59 increments
Axis 2: -0.01°, -66 increments
Axis 3: +0.00°, +58 increments
Axis 4: +0.01°, +46 increments
Axis 5: +0.00°, +2  increments
Axis 6: -0.01°, -51 increments

These differences were too small to redo the mastering, so I left it at this. However, another 6 months later, last month, I did another check and my results were as follows

Axis 1: +0.02°, +187 increments
Axis 2: -0.01°, -135 increments
Axis 3: +0.01°, +109 increments
Axis 4: +0.02°, +122 increments
Axis 5: +0.01°, +66  increments
Axis 6: -0.03°, -153 increments

While these differences are still quite small, they are significantly larger than they were in april. As I had some problems with accuracy, I decided to remaster the robot.

I decided to post my results for the curious

Quote from SkyeFire

One note: Mastering needs to be done in a fixed direction, to minimize the backlash effects of the axes.

Yes, the manual is quite clear in this part, luckily. I mastered by moving to the pre-mastering position, finding the lowest point in the notch, adjusting my dial gauge so the lowest point would be at zero, moved all the way back to the pre-mastering position, and moved until the needle hit zero. If I was unsure, I would go back to the pre-mastering position and do it again. After pressing 'Master', I checked whether I actually hit the lowest position.

Out of curiosity I did some hunting 'back and forth' just because I wanted to know how small this backlash is, and I was surprised how small the effect was. Anyway, the linearity of the robot has been hugely improved, discrepancies are now in the order of half a millimeter, instead of several millimeters.

Quote from panic mode

...and always from same pose. good idea is to bring all axes to mastering position before doing mastering on any of them.

Which I did, except for A1. The manual states that moving A1 away from the mastering position is not a problem. I did this, as it is very difficult to reach all points with A1 fixed at 0°.

Quote from Leon

but in the only way i know that mastering can drift is when the robot is moved with the kabinet powered down or not communicating.

That is why I think it might have to do with hot days: if the robot is hot (after running at high ambient temperature) and I power down the cabinet, the robot 'shrinks' because of cooling down without it being noticed. Perhaps the axis move that way.

Quote from panic mode

Are you sure it is the robot drifting and not fixtures used by robot...

I will explain: The only 'fixtures'/fixed teach points I use are the tools that the toolchanger needs to pick up. The rest of all my programs are fully parametric, with a laser distance measurement on the robot that determines the root point of every product each time the program is run. This laser distance measurement is calibrated about once a month.

Right after installing the robot, I used basic trigonometry to figure out the root point of each product with four distance measurements. However, over time, I had to add adjustments to account for some 'drift' of the measured root point, not so much for X, Y and Z, but mostly for the measured A. After I mastered the robot last week, I could remove all these adjustments, so everything is exactly as it should be theoretically.

Here's another video I made just this morning, to show this procedure of finding the root point with distance measurements.
0:00 - 0:19 Portal moves
0:19 - 0:45 Robot does panel detection with long-range sensor
0:45 - 0:59 Robot does edge detection and collision avoidance scan for first measurement
1:00 - 1:06 Robot does first measurement
1:07 - 1:30 Robot does edge detection, collision avoidance scan and second measurement
1:30 - 2:10 Robot does edge detection, collision avoidance scan and third measurement

Rest of video: Robot scans panel surface and saves measurements for use during milling and trimming

Yes, I am using a dial gauge. Before mastering, I've done a 'check mastering' by hand. I did this by finding the mastering position with the dial gauge, and simply wrote down the axis position on the teach pendant. Differences were:

A1: + 0,10°
A2: + 0,10°

A3: + 0,07°

A4: + 0,15°
A5: + 0,15°
A6: - 0,19°

However, this was the first time I've mastered this robot myself. I assume the last time is was mastered was at the last overhaul at the company I bought it from (which sells used robots), before shipment.

This is not an issue with parallax nor with hysteresis. The differences mentioned where clearly visible on my dial gauge (as much as half a turn, 0.5mm!), parallax on the dial gauge is at most 0.01mm and hysteresis seemed to be about 0.05mm (I was curious, so I checked)

I plan to check mastering (by hand, as I don't have an EMT device) end of March, end of April, and when we've had a few hot days.

Over the past two years it has been necessary to reteach the tools that have to be picked up by the toolchanger. This drift was about 2 to 3 mm in total.

After mastering the robot, I could remove certain adjustments in my program that built up to 6mm in total.

I assume the mastering drifts, but I will keep a close watch on it (by checking the mastering once a month the next few months) as I would assume a drifting mount would mean loose bolts, and loose bolts would certainly be noticed.

Personally, I hypothesized that last summer, shutting down the robot at the hottest point of the day (5:00 pm, 40°C ambient, with all gears and motors hot) and starting it at the coldest point of the day (7:00 am, 25° ambient, with all gears and motors cold) on several hot days might have been the biggest problem. But keeping the robot powered on seems like a waste of electricity. Perhaps I should stop shutting it down at hot summer days?

Hi all,

For 3 years now I've been using a second-hand KuKa KR 100-2 P 2000 shelf robot, with a KRC2 control system. I use it to do various milling and trimming jobs on rather large panels. You can see a video here:

However, until recently, I never mastered this robot, not even after installation. In hindsight, this is probably a rather large mistake. However, I managed to get quite decent results with this setup. Throughout the years, the calibration asjustments I needed to make in the program grew larger and larger. In pursuit of more accurate milling results, I recently bought a dial gauge and an adapter to master the robot by hand, and was surprised by the results. I really should have done this much earlier.

Now to my question: As i've said I noticed that the robot mastering slightly drifts. I had to readjust several points in my program about every 3 months. Is this normal? I'd like to remaster the robot instead of figuring out what adjustments have to be made in the future. How often do you remaster a KuKa robot?

Could it be that this drift away from the mastered position is because I shut down the robot after each work day, and start it up in the morning? I've had the idea that the drift got way worse during the unusual hot summer we've had here last year.

Thanks in advance for your replies.

Okay, I'm posting this for future reference, for anyone having this same problem.

DECL INT NEW_MESS
DECL STOPMESS MESS2CONF


[...]


IF $STOPMESS AND $EXT THEN
	NEW_MESS = MBX_REC($STOPMB_ID,MESS2CONF)
	IF NEW_MESS == 0 THEN
		IF (((MESS2CONF.MESSNO == 1200) OR (MESS2CONF.MESSNO == 1210) OR (MESS2CONF.MESSNO == 1212) OR (MESS2CONF.MESSNO == 1223) OR (MESS2CONF.MESSNO == 3024)) AND (MESS2CONF.STATE == 1)) THEN
			CONFIRM MESS2CONF.CONFNO
		ENDIF
	ENDIF
ENDIF

This only confirms the following messages with the error codes mentioned, but only when with the mode key at 'Automatic External'
1200: Acknowledge Emergency Stop
1210: Acknowledge General Motion Enable
1212: Acknowledge Operator Safety
1223: Acknwledge Undervoltage
3024: Quit Local Protective Stop

What about lowering the limit on acceleration? That should be easy to find in the manual

I just found something on the german robotforum: https://www.roboterforum.de/ro…trukturtyp-stopmess/1182/

Quote

STRUC STOPMESS INT CONFNO,GRO,MESSNO,STATE,CAUSE_T CAUSE;CONFNO = QUITTUNGSNUMMER, GRO = MELDUNGSGRUPPE, MESSNO = MELDUNGSNUMMER, STATE = STATUS,CAUSE = VERURSACHER

This already sheds more light on the example, but still I have some questions. What would be the difference between CONFNO and MESSNO? Does the latter correspond to the message numbers in the KCP message overview? What kind of message groups are there? What states can the messages have?

Anyone any clue?

Thanks a lot in advance!

Hi all,

My Expert programming manual for KSS 5.2 says in section 4.5 (confirming messages) quite some things about a STOPMESS structure that can be filled with the MBX_REC function. However, it is not explained how the code works. The STOPMESS structure apparently has a GRO, STATE and CONFNO part. What are they?

The thing is, I would like to autoconfirm certain messages (for example, acknowledge operator safety), but not others. As I don't understand the example, I can't modify it accordingly.

Many thanks for your help!

Hi all,

Sadly, I still haven't been able to solve this issue. Today, I was rereading the KR C2 5.2 Operator Control manual, and on page 97 it says the following:

"Before using the function "Path-maintaining braking in event of operator safety violation", the user must carry out a danger analysis and a risk assessment for every eventuality."

Does anybody know where this function is used or set? Maybe it might be a lead to fix the problem I'm having.

Thanks in advance!

Quote from SkyeFire

As documented, the order of operators matters. Transform:Pos will transform with the active Base as the frame of reference. Pos:Transform will transform using the position as the frame of reference.

I knew the order matters, I didn't realize using pos:transform gave a meaningful result. In fact, it does exactly what I wanted. Thanks!

I know how the geometric operator works, and I know it's is documented.

I just don't know how to use it to rotate an arbitrary POS around a TCP axis. Just using transform:POS gives me a rotation around WORLD coordinate system, but I want to transform around TCP coordinate system.

Hi all,

Using the TCP coordinate system to move is easy in jogging: one chooses the TCP mode and jogs for example +A or -A.
Doing this in relative motion is possible, but not documented, I think I read something about using #TOOL for the LIN_REL command somewhere?

I'm trying to do this with a transform (the : operator), but I can't figure out the way. If I have a POS-variable, how do I transform it so that I rotate it 45 degrees around the Z for example? I can't get my head around this.

Thanks a lot in advance!

Okay, thanks for confirming that this is indeed a viable option.

I was wondering whether it can be made easier. Would it for example be possible to attach a network share with all 'recipe-files' (DAT files with the same format and variable names, but different values)? I haven't seen any file opening, reading, copying and deletion functions in the manual, so I guess not? I would imagine first a loading program is run, copying the right file from the network share to the working directory, and then running the files that depend on it/use those values?

Thanks for your replies.

I want to transfer to an array of 200 POS, 1000 REAL, 200 INT and 200 BOOL variables at a time. This has to happen about once every 10 minutes. The controller has a PROFIBUS connection and a PROFIBUS-PROFINET bridge build in, so the PLC sees PROFINET.

As it is not possible to present this many values over the PROFIBUS connection at once (it is capped at 244 byte if I recall correctly) I was thinking of sending it in packets of 2 POS, 10 REAL, 2 INT and 2 BOOL at a time. If the round-trip (PLC setting, KRC reading, KRC marking read, PLC setting next) takes 100ms, than loading this would take about 10 seconds.

But perhaps there is a better way?

Hi all,

Currently I have a KR C2 robot with a set of programs that read coordinates from a DAT-file. I would like to be able to change those coordinates (one could call this a 'recipe' for example) from either the PLC (over industrial ethernet) or a PC (regular ethernet). Is such a thing possible?

I imagined I could make this work by having the PLC present the first set of coordinates, with a loading program saving it in a global variable and marking as read, the PLC presenting the next set of coordinates and so on. If necessary, I could do this from a Raspberry Pi, fetching the data from a network and feeding it one coordinate at a time over the PLC to the robot. However, I was wondering whether there is an easier way to do this.

Thanks a lot!

Quote from Leon

vibrations during milling with a robot is best compensated by using right Mill and RPM's.

Yes, I will optimize RPMs of course. Using a higher RPM mostly solves this issue indeed.

I was just wondering whether setting more accurate loaddata would help in this case. I could imagine the loaddata being used internally in the controller to tune the servos (higher stiffness and damping) However, I did just enter more accurate data (mostly inertia's Jxx, Jyy, Jzz of 10kgm² instead of the default 130kgm³) and it does not seem to change anything in the robot behaviour. At least, not to my eyes.

Hi all,

A few months back I bought a second-hand KUKA KR100-2 P (KR C2), which I'm using for milling wood and fibre-reinforced plastic. This has been working great for the past few weeks, but at certain (heavy) cutting, the robot starts to vibrate/resonate. When I start cutting, the tool starts vibrating more and more (in the feed-direction mostly), a swell for about half a second, then stops (presumably because the period of the vibration gets too long and the robot compensates or something?),vibration swells again for half a second etc.

Is there a way to reduce this? I haven't set loaddata (the load varies with the cutting force) so it is at maximum robot capacity. The actual weight of the milling motor is about 35kg. Would setting load data help? If so, how should I account for the cutting forces? Or is there another way to make the robot arm behave stiffer?

Ah, I feared as much. I will do it that way. Thanks!