June 18, 2019, 03:18:17 PM
Robotforum | Industrial Robots Community

 KSS 8.x: C_DIS vs C_PTP

normal_post Author Topic:  KSS 8.x: C_DIS vs C_PTP  (Read 10986 times)

0 Members and 1 Guest are viewing this topic.

June 03, 2014, 04:05:39 PM
Read 10986 times
Offline

SkyeFire

Global Moderator
Something weird I just recently noticed on my KRC4s -- when creating a PTP motion using Inline Forms, if the CONT tag is set, the motion is suffixed with C_DIS, rather than C_PTP.  I checked back with one of my old KRC2s, and setting the CONT tag on them generated a C_PTP suffix on the motion command.  So far, I haven't observed any negative effects on how the robots move, but I wonder if anyone else has?  For example, if an OLP were generated using a KRC2 template, would the actual motions of the robot look different with C_PTP instead of C_DIS?

Today at 03:18:17 PM
Reply #1

Advertisement

Guest

June 03, 2014, 08:56:31 PM
Reply #1
Offline

DannyDJ


Hi, I also noticed that KRC4 from 8.2. version is using C_DIS aproximation for PTP commands and for LIN motion it uses LIN C_DIS C_DIS aproximation. You have in UTIL reg file CdisCriterionPTP.reg or CPTPCriterionPTP.reg but i never tried this. I also encountered in some motions that didn't aproximate if the positions where to close if i used the same point using C_PTP it did.

June 04, 2014, 04:16:55 AM
Reply #2
Offline

Fubini


Hi Skyefire,

C_PTP and C_DIS should not behave totally different apart from

  • the obvious $APO.CDIS  = 100 does not equal $APO.CPTP = 100. That is the same programmed approximation radius value does not lead to the same results according to where approximation starts and stops.
  • The approximation criteria is evaluated point-specific:
        $APO.CPTP = 100
        PTP XP1 C_PTP
        $APO.CPTP = 50
        PTP XP2
    uses $APO.CPTP = 100 to define where the approximation starts and $APO.CPTP = 50 to define where approximation ends.

        $APO.CDIS = 100
        PTP XP1 C_DIS
        $APO.CDIS = 50
        PTP XP2
    uses $APO.CDIS = 100 to define where the approximation starts and $APO.CDIS = 100 to define where approximation ends. $APO.CDIS = 50 does not matter as long as there is  an additional approximation programmed behind XP2.

If you have OLP generated old KRC2 Inlineforms these programs would still use C_PTP if used on a KRC4. But if you open the Inline Form inside your KRC4 they will be automatically transformed to the new C_DIS. That is $APO.CPTP = 45 becomes $APO.CDIS =45. To avoid this your only chance would be generally using the old behaviour using the already mentioned CdisCriterionPTP.reg or CPTPCriterionPTP.reg.

Fubini
« Last Edit: June 04, 2014, 04:19:13 AM by Fubini »

June 04, 2014, 12:45:43 PM
Reply #3
Offline

panic mode

Global Moderator
interesting...
what about approximation when consecutive motions are mixed (PTP, LIN for example)?
1) http://www.robot-forum.com/robotforum/kuka-robot-forum/read-first/
2) if you want reply about robot, post it in forum
3) read 1 and 2

June 06, 2014, 05:49:15 AM
Reply #4
Offline

Fubini


Hi,

Quote
what about approximation when consecutive motions are mixed (PTP, LIN for example)?

maybe this post helps at a startup:

http://www.robot-forum.com/robotforum/kuka-robot-forum/motion-replay/msg42809/#msg42809

I did some time ago a table, where all transistions are described (unfortunatly only in german). If I have time maybe I translate it to English. Or maybe someone else in this forum helps out with translation.
Fubini

June 13, 2014, 03:55:32 AM
Reply #5
Offline

Fubini


Hi,

I still had no time to translate the table into English, but I narrowd down its content to three simple rules rfor KRC4:

  • In CP-CP approximation and PTP-PTP approximation the second programmed approximation type (C_PTP, C_DIS, C_ORI, C_VEL) is always ignored. E.g.
         PTP XP1 C_PTP C_PTP       is always the same as    PTP XP1  C_PTP
         PTP XP2                                                              PTP XP2
  • In CP-CP approximation and PTP-PTP approximation the approximation radius is now always evaluated point-specific. E.g.
        $APO.CDIS = 100
        PTP XP1 C_DIS
        $APO.CDIS = 50
        PTP XP2
    uses $APO.CDIS = 100 to define where the approximation starts and $APO.CDIS = 100 to define where approximation ends. $APO.CDIS = 50 does not matter as long as there is  an additional approximation programmed behind XP2. Additionally the approximation radius in PTP-PTP approximation is symmetrisized in axis-space and CP-CP approximation in cartesian space.
  • In CP-PTP approximation and PTP-CP approximation the approximation radius is now always evaluated point-specific. E.g.
        $APO.CDIS = 100
        $APO.CPTP = 75
        LIN XP1 C_DIS C_PTP
        $APO.CDIS = 50
        $APO.CPTP = 25
        LIN XP2
    uses $APO.CDIS = 100 to define where the approximation starts and $APO.CPTP = 75 to define where approximation ends. $APO.CDIS = 50 and $APO.CPTP = 25 do not matter as long as there is  an additional approximation programmed behind XP2. No symmetrisation is done.

Fubini
« Last Edit: June 13, 2014, 04:02:31 AM by Fubini »

June 13, 2014, 05:44:56 AM
Reply #6
Offline

Greedy



If PTP motion is axis base like PTP {A6 -90} you should use C_PTP.
If PTP motion is cartesian base like PTP_REL {Z -50} you can use C_DIS or C_VEL.

Today at 03:18:17 PM
Reply #7

Advertisement

Guest

June 13, 2014, 06:46:11 AM
Reply #7
Offline

Fubini


Quote
If PTP motion is axis base like PTP {A6 -90} you should use C_PTP.
You can also use C_DIS as long as $TOOL and $BASE are valid

Quote
If PTP motion is cartesian base like PTP_REL {Z -50} you can use C_DIS or C_VEL.
C_VEL is only for CP-motion:

PTP XP1 C_DIS C_VEL
LIN XP2

is ok. But not

PTP XP1 C_VEL
PTP XP2

June 13, 2014, 12:29:26 PM
Reply #8
Offline

SkyeFire

Global Moderator

  Fubini, did you mean:
PTP XP1 C_DIS
LIN XP2 C_VEL
?

June 13, 2014, 01:04:35 PM
Reply #9
Offline

Fubini


Hi Skyfire,

For mixed blending PTP-CP or CP-PTP you can always use two approximation types. E.g.
$APO.CDIS = 300
$APO.CVEL = 100
PTP XP1 C_DIS C_VEL
LIN XP2
is valid. $APO.CDIS is evaluated on the PTP-side of the approximation and $APO.CVEL is used on the LIN-side. Hence the approximation path can be asymmetric.

If no second type is specified in mixed blending the default value for the motion type is used (C_DIS for CP-motionsand C_PTP for PTP motions):

LIN XP1 C_DIS equals LIN XP1 C_DIS C_PTP       and            PTP XP1 C_PTP equals PTP XP1 C_PTP C_DIS
PTP XP2                     PTP XP2                                            LIN XP2                      LIN XP2

Furthermore on the PTP-side of approximation only C_DIS or C_PTP is possible. On the LIN-side you can use C_DIS, C_VEL or C_ORI.

FUbini
« Last Edit: June 13, 2014, 01:13:29 PM by Fubini »

June 13, 2014, 02:58:03 PM
Reply #10
Offline

SkyeFire

Global Moderator
Ah.  I've never seen that technique used before.

Hm.  Is the order important?  That is, would this be valid?
PTP XP1 C_VEL C_PTP
LIN XP2

Or would it have to be
PTP XP1 C_PTP C_VEL
LIN XP2


June 13, 2014, 03:23:48 PM
Reply #11
Offline

Fubini


PTP XP1 C_VEL C_PTP
LIN XP2
is not valid, because C_PTP would have to be used to define where the LIN is entered but on the LIN-side only C_DIS, C_VEL and C_ORI are allowed.

PTP XP1 C_PTP C_VEL
LIN XP2
is valid. $APO.CPTP defines where the PTP is left and $APO.CVEL is to define where the LIN is entered.

By the way if on a KRC4 you open the LIN Inlineformular FOLD with the "CONT" option you shoul see LIN XP1 C_DIS C_DIS. Hence on KRC4 this technique is used all the time. This is done because if after the LIN a PTP follows you would not get C_DIS on the PTP-side.

June 13, 2014, 11:08:03 PM
Reply #12
Offline

SkyeFire

Global Moderator
 :uglyhammer2:  Ahg!  I hadn't noticed on my robots, but I had noticed it happening in OrangeEdit, and just assumed it was some kind of bug.   :party1:

Well, that explains a few things.  We're actually in the process of modifying our existing simulation-to-KRL translators, but the baseline they're starting from is the classical KSS 5.6 translator.  I'll have to mention this to the guys responsible for writing the translator.

Still, it would appear that KUKA has maintained backwards compatibility, yes?  Probably for just this reason, among others (all that legacy code....)


June 14, 2014, 11:34:46 AM
Reply #13
Offline

Fubini


Quote
Still, it would appear that KUKA has maintained backwards compatibility, yes?
Unfortunatly not. Take for example the above 3 rules for approximation on KRC4. The same list on a KRC2 say V5.6 would be much larger. Hence with KRC4 we tried to straighten it out a bit because it has been the first chance given to us to break compatibility issues for a long time.

E.g. in KRC2 the spproximation radius was not always evaluated point specific. Citing my own examples from above 
    $APO.CPTP = 100
    PTP XP1 C_PTP
    $APO.CPTP = 50
    PTP XP2
uses on a KRC2 $APO.CPTP = 100 to define where the approximation starts and $APO.CPTP = 50 to define where approximation ends (still symmetrisation is don afterwards). In KRC4 we changed this to $APO.CPTP = 100 is used to determine where approximation starts and ends (see my second rule given before). In our opinion probably most users assumed anyhow it was a point specific evaluation(even though its inconsistent to the method e.g. $BASE and $TOOL are applied).

As far as I remember there was a incompatibilty documentation issued in the beginning of KRC4 which should have listed these items. When I am back at office on Monday I'll see if I can dig it out.

Fubini
« Last Edit: June 14, 2014, 11:37:18 AM by Fubini »

Today at 03:18:17 PM
Reply #14

Advertisement

Guest

June 17, 2014, 04:17:19 AM
Reply #14
Offline

Fubini


Fubini,

so finally I found the compatibility documentation, but unfortunatly nothing of this discussion here is mentioned. We noted this stuff in our internal specifications but documentation did not update the end users documents on approximation. Hence I talked to our documentation staff and they told me they are currently working on a better decription of approximation. They sent me an early draft of their updated approximation description, which know contains most of the stuff we talked about. Unfortunatly since this is not yet an official paper I am not allowed to post it here. I'am sorry for this inconvinience.

Fubini


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter

xx
PTP motion C_PTP C_DIS

Started by Plc_User on KUKA Robot Forum

3 Replies
709 Views
Last post August 13, 2018, 03:58:41 PM
by SkyeFire
xx
KRC 4 c_ptp not working

Started by Davidko on KUKA Robot Forum

9 Replies
3480 Views
Last post October 07, 2015, 05:59:59 PM
by panic mode
xx
KSS 8.3.11 -- causing System Error 14 with LIN_REL C_DIS?

Started by SkyeFire on KUKA Robot Forum

4 Replies
4273 Views
Last post November 30, 2014, 09:25:29 PM
by SkyeFire