Export in KRL language

[MaylisUhart]

Prerequisites

• [X] Put an X between the brackets on this line if you have done all of the following:
  • Reproduced the problem in a minimal file that you can share if needed.
  • Checked that your issue isn't already filed: https://github.com/HALRobotics/Beta/issues?utf8=%E2%9C%93&q=is%3Aissue

Description

Hi, I am using HAL6 since 1 week only... (before HAL5). I am encountering some problems to generate the KRL program in the correct format for my robot.

First, the program generated contains the following line : $VEL={CP 0.25,ORI1 572.9578,ORI2 572.9578} but I would like to write : $VEL.CP=0.25

Secondly, I would like that at the end of each mouvement, the command C_VEL or C_DIS or C_PTP be written. For example : LIN {X -148.704,Y 1.481,Z 0,A -90,B 0,C 180} C_VEL

How should I do it ? Thanks in advance for your help. Maylis

EXTENSIONS

• HAL.McNeel.V5 1.2.18-beta
• HAL.KUKA 1.2.11-beta

[sebandraos]

Hi @uhart,

I see two distinct issues here:

1. Setting $VEL.CP without changing the orientation speeds.
2. Adding in the approximation calls to motion commands.

1

We have taken the stance that it is safer to set all of the velocity parameters simultaneously. It is impossible for us to know whether the Orientation Speed we see when exporting is explicitly specified by the user or our default. At this stage my suggestion would be to set the Orientation Speed in the Speed Settings explicitly to have a control over the ORI values. That said, I have less experience programming KUKA robots than other brands so if there is a difference between $VEL={CP 0.25} and $VEL.CP=0.25 then I would be very interested to know.

2

This is an oversight on our part. We are setting the approximation values but never actually calling them. I will add this back in as an automatic switch when your Blend Settings dictate that an approximation should be performed. There are a couple of caveats to this:

1. We have no concept of velocity blends so for LIN or CIRC these will always be C_DIS or C_ORI (whichever gives the largest blend).
2. We have not exposed per joint blends in current releases so PTP motions will also use C_DIS or C_ORI (whichever gives the largest blend).

I would be very much interested in your feedback on point 1. Point 2 will be included in an upcoming release.

[sebandraos]

We have just released an update that should covers the first issue, all settings are now set via the $VEL.XX=XX syntax rather than $VEL={}. _CDIS should also be set on any moves that require blending. This will be improved to switch between _CDIS or _CORI in a future update.

[MaylisUhart]

Hi @sebandraos, thank you for the update, I installed it.

Issue 1 : I will test a new program generated with the update on the robot and I come back to you.

Issue 2 : To define the approximation at the beginning of the program, there are 4 variables : $APO.CDIS (in mm) - $APO.CORI (in degree) - $APO.CVEL (in %) - $APO.CPTP (in %). To call the type of approximation, there are also 4 keywords : C_DIS or C_ORI or C_VEL for LIN or LIN_REL movements and C_PTP for PTP movements. So, it would be better to have the possibility to switch between C_DIS or C_ORI or C_VEL or C_PTP in a future update.

You could find more information with the following link : https://thegeekgroup.org/documents/kuka/PROGHBEXPERTE_R41_EN.PDF

I could provide a KRL program with comments if you want ?

[MaylisUhart]

Hi,

I generated the program "patch_v0" with the update and I tested it on the robot with some modifications "patch_v1". So, you can compare the both files.

Here, my explanations...

• At the beginning, it is necessary to have a fold DECLARATION and a possibility to define the variables thanks to a block in HAL6. In HAL5, it was possible with the block "QuickTask".

;FOLD DECLARATION INT i ;ENDFOLD

• Then, the fold INITIALIZATION must be closed with the word ENDFOLD

;FOLD INITIALIZATION ... ;ENDFOLD

• The velocity and acceleration of each axis are set before the "motion settings" but the values are not taking account in the KRL program :

FOR i=1 TO 6 $VEL_AXIS[i]=20 $ACC_AXIS[i]=20 $ACC_EXTAX[i]=20 ENDFOR

• Then, it is necessary to make the approximation settings for distance, orientation, speed and PTP mouvement :

$APO.CDIS=1 $APO.CORI=0.1 $APO.CVEL=100 $APO.CPTP=50

• The approximation is selected at the end of each line of the PTP or LIN mouvement :

PTP {A1 -148.5945, A2 -103.9916, A3 104.339, A4 90.21172, A5 58.59507, A6 89.59329} C_PTP LIN {X -345.5034, Y -412.3989, Z -1380.263, A 90, B 0, C 180} C_VEL

• The following lines written on the KRL program do not work. Could you delete them ?

$VEL.ORI1=572.9578 $VEL.ORI2=572.9578

• Finally, the tool is set but not the base frame :

$TOOL={X 305, Y 0, Z 131, A 0, B 90, C 0} $BASE={X 0, Y 0, Z 0, A 0, B 0, C 0}

Thanks in advance for your help and the update of the post processor. Best regards, Maylis

programs.zip

[sebandraos]

@uhart This is really useful, thank you. We will take a thorough look at our KUKA export code in the coming weeks and try and get some hands-on time with a robot to test some of these changes. I will update here if we have any questions.

[sebandraos]

@uhart I have made a few changes to the KRL export now and it's looking better. I have separated the 7 points that you made and endeavoured to resolve each one:

1. Being able to add variables is something that I would really like to enable along with other export modifications but the export system wasn't designed to be modified from the outside (unwisely) so it requires a few more fundamental changes. Hopefully this isn't too big an issue with the solution in 3.
2. Typo has been corrected. Will be included in the next update.
3. These are now included but without a loop. This enables partial updates as in the attached demo file (will only work with the update). External axes will be added when external axis support is added to the rest of the Framework.
4. C_PTP should be working fine now (as a % of motion distance) but C_VEL is still not something we have an equivalent for so not something we can export directly. I have implemented a bit of a hack (that should unblock you for now but we'll replace at some point), if the position blend is >= 1,000,000 m (one million metres) then the orientation blend (in radians) is used as the velocity. e.g. BlendSettings(Position = 1000000m, Orientation = 12 rad) => $APO.CVEL=12 and LIN ... C_VEL. The vague logic behind this is that a velocity blend could create a massive distance blend (bigger the distance, higher the speed stays) and therefore it's our best guess at what the robot will do. Again, this is a temporary workaround until we add something equivalent into the software.
5. As 4.
6. Before I release the update, would you mind clarifying why these lines "don't work"? Do they do nothing or have a tangible negative impact on the running of the code?
7. I'm not sure how that slipped through, that's back in the next update. Thanks for all you assistance.

KUKADemo_JointSpeeds.zip

[MaylisUhart]

Hi, Sorry for my late response... Thank you for the modifications. Here, my comments on the 7 points :

2. OK

3. I think that all the parameters are not taken into account: even if the speed and acceleration joints are set to 30, in the KRL program generated, $ACC_AXIS[1…6] have different values at the beginning and then they are set to 100, $VEL_AXIS[1…6] are set to 100.

4. C_PTP : The parameter appears at the end of the command line but where can I set the value (50 for example) of $APO.CPTP ? I did not find this parameter in HAL6. C_VEL : The hack works :-)

5. OK

6. When I execute the program, an error message appears because of these lines. I have to delete them and then the program runs. $VEL.ORI1 represents swivel velocity and $VEL.ORI2 represents rotational velocity. The both parameters are in °/s and the maximal value is 400.

7. OK

[sebandraos]

Hi @uhart ,

3. The values you are putting in are in rad/s (assuming a KUKA robot with revolute joints). The values that go out to the robot are in % of joint maximums. We do the conversion internally which is why the values look bizarre. The $VEL... are always 100 because none of those joints can go at 30 rad/s (thankfully). If you would rather specify speeds and accelerations as percentages the we can look at a component to do that.
4. $APO.CPTP should be defined for you like the other approximations are. It is in our test code but please let us know if that's not the case on your end.
5. That's great to know. I couldn't find that anywhere in the documentation. I will add a clamp in the export to max out at 400.

[sebandraos]

@uhart Everything here should be fixed. Please reopen if that's not the case.

[MaylisUhart]

Hi Sebastian, I start working on the subject again... sorry for the delay. In fact, i am agree with you, for PTP motion, the parameters $ACC_AXIS[joint] and $VEL_AXIS[joint] are in pourcentage. Could you add a component to set these parameters directly in % please ? Best regards, maylis

[sebandraos]

Superseded - Please see comment below. New version of the SpeedSettings and AccelerationSettings component coming in an update very soon (possibly before the end of today). You can use the boolean Ratio to switch between giving the percentages as 0-1 or 0-100. Currently defaulting to 0-100 because that's how it's exported so it's WYSIWYG but the option is there.

[sebandraos]

@uhart These components are now live with a few names changed since the image above. You can use the boolean IsPercent to switch between giving the percentages as 0-100 or 0-1. Currently defaulting to 0-100 because that's how it's exported so it's WYSIWYG but the option is there.