Posts by Fubini

    Of course. As long as no advance run stopping statement is programmed. Hint: the INI fold has advance run stopping statements. This is the most common reason why this question was asked in the past way to many times because no one likes to use the search function of the forum before posting questions 😁.



    Ive been told (never tested it myself) that if _REL motion is interrupted (say, by an E-Stop) partway, when the robot resumes motion, it will begin the _REL motion over again from the robot's current physical position.

    Being quite familiar with the controller internals I seriously doubt this. Of course this behaviour would be the case if doing a line selection but not if you simply stop the robot using e.g. the stop button or when repositioning after an emergency stop.

    But of course only working with absolute coordinates is also line selection safe.

    Lin_rel xp #Tool

    Ptp_rel xp #Tool

    Lin_rel xp #Base


    Alternatively you can easily calculate the position using the : operator aka geometric operator. This has been explained many many times in the forum. Just use the search function for details:

    Lin xp:shift

    Lin shift:xp

    Can you check the value of $APO when the actual error happens under Display > Variable > Single. Also it would be interesting not to see your program header but also the actual faulty program code segment. Maybe posting the two KRCdiags you took earlier might also be helpful with a short description in which program at what program line of code the error happens.

    So far all information we have does not allow any conclusions and we probably talked a lot about stuff that does not relate to the faulty behavior.

    So read the ArcTech documentation. ArcTech provides this functionality. Afterwards decide on buying this technology package. If you decide not to buy it you could always develop your own technology package using function generator to realise weaving. In that case good luck with your level of experience.

    In any case taking basic KUKA training is the least you need to do.

    Here is the address to KUKA Turkey found by typing KUKA and Turkey into Google search:

    Şerifali, Bayraktar Bulv. Beyit Sok. KUKA Roboter CEE GmbH Merkezi, Avusturya Türkiye Istanbul Şubesi Şerifali Mah No:9-11, 34775 Ümraniye/İstanbul, +90 216 508 14 04

    So much about no support available in Turkey


    But when run on new robot it will sometimes (not all the time) approximate a sharp programmed corner with a 50mm radius.

    And this only happens when you execute for the first time and on the second run through your program behaves as expected or after transferring to a new robot the problem is persistent?

    Sorry I still do not totally understand your problem description. Does the robot not approximate or the robot still approximates but run a different blending path. Any messages in case of the bad behaviour like blending not possible? Did you check logbook what's happening.

    Ok. First of all you should use the : operator to shift positions. Simply adding them might be correct for xyz but certainly not for ABC angles in general. Also status and turn are bits so that I would not hard code them to certain integer values but always swap only certain bits.

    Moreover your problem code only shows problem with turn which always comes from limit switch errors. Is this correct? Btw this then is another case why details like exact messages matter. You only stated unreachable points before but not what exact messages. So for future reference if it is a software limit switch message it is always a turn issue. Status problems would lead to other messages and would need other methods to resolve them.

    To sum up: you only have ptp target positions that drive the robot behind limit switches. This is easy to test beforehand using the inverse function. You provide your target position and the return value tells you if the resulting position in axis coordinates lies behind limit switches. Lookup the documentation of inverse on details. Documentation is included in kuka xpert now. But you probably will also find the necessary documentation using the forum search. At least I remember to have posted it quite a while ago.

    Lookup the Inverse function. It allows testing your recalculated points. For an example on handling it you could checkout kue_weg.src in the UTILS folder of every controller. Also details matter: are we talking ptp or lin/circ movement commands. They handle status and turn differently.

    First thing usually people try to use frames instead e6pos for target position variable type, because it contains no status and turn and the internal krc strategies of choosing them somewhat optimal can be applied.

    In your case I would create a KRCDiag for each robot, unzip them than compare using e.g. Windiff or kdiff3. If you could tell us these differences we probably are able to give better advice. So far we only know you have two robots that might be the same. No info on KRC versions, software versions, messages in case of the different behaviour, ...

    Otherwise there could be hundreds of reasons (different tool and base, different load, different settings, ...). Usually KUKA does not change stuff incompatible.

    1) I do not know. Maybe Fanuc uses safe absolute encoders?

    2) no because these monitoring function are not safety rated

    3) no. Because this would not be safe for Kuka. Only if you do not need safe Cartesian workspaces you could use SafeRangeMonitoring instead of safe operation. It's a bit cheaper if it is still sold by Kuka but I think reference switch is still needed to get safe axis positions.

    Probably. Open bas.src and look for yourself. It is only plain KRL in there so it should be readable for you. If you set bas.src visible and use incremental step you can step through it and look up what's happening.

    Might also be you reach maximal orientation velocities or accelerations. It is totally analog to my previous comment.

    What happens when you directly set $vel.cp and $acc.cp? That is not using bas.src.

    Sorry my fault. In English:

    This functionality is used for redundancy resolution for Cartesian targets. The EO functionality is not relevant for axis-specific target points. The target position must therefore be E3POS or E6POS. Axis-specific target points are therefore always approached as if there were no offset, i.e. absolutely with reference to the mastering position of 0.