Posts by Fubini

Just use forum search and you might come up with a few results like program example of a palletizing program KUKA KRC4

Fubini

The logic behind this system variable is coded inside the robot controller VxWorks binary software files. There is nothing you can watch. The timer is running whenever at least one axis is in control/regulation. I think this is explained in system variable documentation. The timer unit is [ms] if I remember correctly. Timer resolution is 2 ms.

Fubini

There we are: version is important 😁. Since we are talking KRC4 and V8.x easiest way to change robot type on a KRC4 is deploying a corresponding WorkVisual Project into Office Lite. Basically the same you do with a real robot.

In KRC2 Robot Type is easily changed by copying machine data files $machine.dat and $robot.dat from the made tree. Alternatively you could restore an archive.

Of course you can use different robots on Office Lite. You only have to exchange the specific data. For the best way to do this details matter. See READ FIRST...

Yes. Tool and Base number 2 will be used by the robot running the program. Lookup bas.src to understand this.

Fubini

READ FIRST...

Connect $EXT_START and $DRIVES_ON to logic in sps.sub

Try a different language. Maybe column width is sufficient then.

6 DEF search()
7 ...
8 BRAKE
9 SET_TORQUE_LIMITS(1,{lower 1000, upper 1000, monitor #off})
10 PTP_REL {A1 10}
11 RESET_TORQ_LIMITS(1)
12 piece_found = $POS_ACT_MES
13 PTP $AXIS_RET
14 END

Above example is part of

KUKA System Software 8.6 - Operating and Programming Instructions for System Integrators

manual and can be found easily by searching for PTP_REL

RE: PTP move to get out of error situation

Or documentation for PTP_REL shows examples

Of course: READ FIRST...

Ah. Ok. But still answer would be no. Most of the deviances of LIN moves is caused by the internal handling of path filtering. This is different for Spline and old motion. If you need high accuracy that is velocity independent use spline.

E.g. a fast Circ looks more like an egg and this gets worse the faster you go. A scirc is always a circle.

But newest KUKA releases will have a feature called Motion Modes which basically bring task specific machine data. One of these modes will be a exact path following mode. I do not know if this is already released but it will definitely not be supported for all robot types. This is caused by the effort to determine new task specific machine data for every robot type. New robot types will definitely support this but older models like 60HA might never be supported.

Hardware stays the same. Pure software. But maybe SafeOperation does not update and you have to check configuration anew. Definitely checksum are different.

Thats a general problem today. Hardware redesign is always considered expensive and software nearly costs nothing in many managers minds. Hence the effort that software has to come up with is never considered in the initial developing process. Even worse if it does not work as intended it is always the software guys fault because hardware is out of the focus by then 😤

Quote

In the case of an AA robot, do you think manually taught points will have status bit 4 set automatically? In an offline generated program which is run on the robot, what happens to bit 4 that has been downloaded with it set to FALSE when one manually performs a touch up? Will it become set to TRUE?

Whenever you teach positions with active absolute accuracy the KUKA software sets bit 4 to TRUE. So in both cases mentioned you will end up with bit 4 set to TRUE.

You can ask KUKA for this documentation but as far as I remember there are only a few internal specifications and memoranda for technical support that describes this behaviour. Maybe something can be found in the full access kuka xpert Portal. As you already mentioned yourself $abs_convert can be tricky to be applied correct and is therefore not documented officially.

Quote

have also asked if there are mada optimizations to improve the accuracy of linear moves in a machining context.

There is not. Usually KLs are very stiff so absolute accuracy is not needed. But you should measure on how exactly the robot is mounted on the KL. There is a measuring wizard on the Kuka Hmi for this. This basically defines the KL direction with respect to the robot base.

Also it is much more difficult to model a linear axis with an absolute accuracy model since the model does not repeat itself every 360 degrees but would be different depending on KL lengths. So basically all you could do is define an individual lookup table for each KL.

Quote

So my question is how does one perform point conversion in KSS 8.x? Is it that S bit 4 is no longer used? Do I have to use $SUPPRESS_ABS_ACCUR somehow to achieve the conversion?

I do not think anything changed here. You still should be able to use $abs_convert. But usually you do not need to convert at all. $abs_convert is only for a very specific use case: A robot is initially without absolute accuracy package installed and users teach their programs without absolute accuracy. Later on the robot is equipped with absolute accuracy and the already teached programs should still realize the same real positions. For this the controller looks at status bit 4 and if it is not(!) set calculates the point coordinates that with consideration of absolute accuracy correction reach exactly the same Cartesian position as before without absolute accuracy. Additionally bit 4 is set to true so this algorithm is not applied multiple times on a teached position. This is the only case inside the controller where status bit 4 actually has some significance.

On the other hand the controller replaces the standard kinematic equations with the individual more exact absolute accuracy kinematics equations whenever absolute accuracy is active. In e.g. KRC4 absolute accuracy is always active as soon as a pid file is added to rdc. You can only manually deactivate absolute accuracy by setting $deactivate_abs_accur to true. This is the opposite to KRC2 where you had to activate absolute accuracy manually using $abs_accur as mentioned by you before. Especially whether the robot uses absolute accuracy kinematics equations does not depend on the status bit.

Quote

A colleague who generates offline programs in KRL tells me that S bit 4 is never used, either in KSS 5.x or KSS 8.x so we wonder how offline generated programs can ever be Absolute Accurate?

Offline generated programs in itself are in a sense always absolute accurate. As mentioned before absolute accuracy reduces the difference between ideal robot and actual robot. This is done by individually tweaking kinematic parameters of the real robot so that he behaves as close as possible as the ideal robot. Offline programs always use the ideal robot.

The difference between ideal robot and actual robot result from multiple influences like manufacturing tolerances, deflections due to robot load, elasticities, ... and absolute accuracy tries to compensates these. Actually if you only teach your programs you should not need absolute accuracy at all because you compensate those influences implicitly yourself by making your process work.

Fubini

Quote

Long story short, despite the fact that these KL1500s are completely kinematically integrated, the SafeRDC is, as far as I can tell, measuring the Cartesian Space from $ERSYSROOT, not from $WORLD.

Yes. Unfortunatly this is true. The first versions of SafeRdw did not support kinematic integration of the KL. The safety devlopers back then refused to listen to more experienced people. They initially even refused to support external axes at all. Luckily you seem to have a version that supports them axisspecific. In the newest SafeOperation this was corrected and you can choose in configuration whether to kinematically integrate the KL or not.

In general the SafeRdw in my opionion suffers from quite a few design faults. For example its main processor is a DSP without FPU and can only perform emulated floating point operations with very low performance. Why do hardware developers design without consideration of the software that later on needs to run on them is something I will never understand. Hence later on a lot of software optimizations had do be done to allow it to run at all and these optimizations had to be reoptimized with nearly every functionality added. This even got worse because the responsible people back then refused to lower safety reaction times from 2 to e.g. 12 ms as it is now in KRC4.

So for me the era of really usable SafeOperation starts with KRC4 which btw was designed and developed by different people.

Sure everything you talk about is possible. Lookup automatic external interface and Cell.src in documentation and forum search.

Fubini

Having time to sleep over this one night I think the $masteringtest_inpro stands for mastering test in progress. I know remember there was a handshake between non safe controller and SafeRdw at the beginning of the hidden krl program I talked about. The program sends a signal to SafeRdw to get into mastering reference mode. If the SafeRdw does not answer fast enough (do not remember the times) by setting $masteringtest_inpro to true you probably get the message. Since it has no message number associated it is probably printed out using a simple printf or MsgLib style message. After this probably masref program is stopped.

How this helps analyse your problem I am not sure. But I know non safe controller sends its start mastering reference command through dse because dse channels all communication with SafeRdw.

Maybe take a look into the TP folder of the robot system. I think this is where the hidden program resides on hard disk.

Quote

The one odd thing about this robot is that is has 9 axes, but only 8 of them show up in the SafeOp config screen

This at least is normal. SafeRdw only supports maximal 8 axes. This is a bit confusing because DSE supports 9.

The signal is a internal communication signal between SafeRdw and the non safe VxWorks kernel. After this long time I do no longer remember the details but I think there was a possibly hidden krl program running the process of the reference process waiting for this system variable to get true after a certain amount of time. The signal itself is a internally defined system variable similar to e.g. $BASE where you will not be able to find definition. I would try to find this possibly hidden program and look at its content.

A common cause for a failed reference is the two contacts of the reference not being activated simultaneously enough. But probably you are already aware of this. And still I do not remember whether this would lead to your message.