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?
KSS 8.x: C_DIS vs C_PTP

SkyeFire 
June 3, 2014 at 6:05 PM 
Thread is marked as Resolved.


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.

Hi Skyefire,
C_PTP and C_DIS should not behave totally different apart from
[list type=decimal]
 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 pointspecific:
$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.
[/list]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

interesting...
what about approximation when consecutive motions are mixed (PTP, LIN for example)? 
Hi,
Quotewhat about approximation when consecutive motions are mixed (PTP, LIN for example)?
maybe this post helps at a startup:
https://www.robotforum.com/robotforum/kuk…42809/#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 
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 CPCP approximation and PTPPTP 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 CPCP approximation and PTPPTP approximation the approximation radius is now always evaluated pointspecific. 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 PTPPTP approximation is symmetrisized in axisspace and CPCP approximation in cartesian space.  In CPPTP approximation and PTPCP approximation the approximation radius is now always evaluated pointspecific. 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
 In CPCP approximation and PTPPTP approximation the second programmed approximation type (C_PTP, C_DIS, C_ORI, C_VEL) is always ignored. E.g.

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. 
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 validQuoteIf PTP motion is cartesian base like PTP_REL {Z 50} you can use C_DIS or C_VEL.
C_VEL is only for CPmotion:PTP XP1 C_DIS C_VEL
LIN XP2is ok. But not
PTP XP1 C_VEL
PTP XP2 
C_VEL is only for CPmotion:PTP XP1 C_DIS C_VEL
LIN XP2Fubini, did you mean:
PTP XP1 C_DIS
LIN XP2 C_VEL
? 
Hi Skyfire,
For mixed blending PTPCP or CPPTP 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 PTPside of the approximation and $APO.CVEL is used on the LINside. 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 CPmotionsand 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 XP2Furthermore on the PTPside of approximation only C_DIS or C_PTP is possible. On the LINside you can use C_DIS, C_VEL or C_ORI.
FUbini

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 XP2Or would it have to be
PTP XP1 C_PTP C_VEL
LIN XP2 
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 LINside 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 PTPside.

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.
Well, that explains a few things. We're actually in the process of modifying our existing simulationtoKRL 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....)

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

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

I am sorry to revive an old thread, but it seems Fubini might be able to explain to me what is happening and it is relative to this discussion. While blending PTPCP motion I observed a strange for me behavior around the approximated POS, I have been using the C_PTP parameter and the approximation behavior did not seem to be affected by $APO.CPTP. What I didn't realize was that the blending with the LIN motion to the next point was affected by the C_DIS that was added internally and it was the culprit for the motion. So after playing with OL and Sim Pro I came to the upper mentioned conclusion.
The way I understand it it should have the smaller one used for approximation only, but having a very small CPTP and CDIS larger resulted in the approximation towards the end and the LIN motion to follow the larger CDIS parameter in this case. Can some one explain what is going on? I have seen it on a physical KR210 R2700 robot running 8.3.38 and a OL one running 8.5.7.
For my current understanding it uses different parameter for the beginning and for the end of the approximation  CPTP and CDIS respectively. Is it so and if so is there a mistake in the SI manual or I am reading it wrong  it does say so that the smaller radius is the beginning limit but it doesn't state that the other might be used for the end.

Since I left KUKA a while ago I can not look it up anymore. But if I remember correctly in mixed blending (ptp  Lin or Lin  ptp) no symmetrization of the blending radius is done. So you always get what is specified in the corresponding $Apo.* value for your programmed blending type on each side.
Fubini

So what you are saying is on the PTP side you use CPTP and on the LIN you use the CDIS/CVEL/CORI (but if you haven't specified it it will use CDIS it seems).This seems to support what I have observed but I cannot find where it says so in the manuals.

If by any chance you speak German you can lookup some more details here
https://www.roboterforum.de/roboterforum/…22018#post22018
I do not know if this is described in such detail somewhere in documentation.
Fubini

So what you are saying is on the PTP side you use CPTP and on the LIN you use the CDIS/CVEL/CORI (but if you haven't specified it it will use CDIS it seems).This seems to support what I have observed but I cannot find where it says so in the manuals.
PTP type motions support CDIS and CPTP
CP type motions support CDIS,CVEL,CORI
motion instructions support up to two such parameters and will respond to whichever happens to be the first one encountered along the path.
