Problems with the settings - Program Tab in Option Menu

GarrisonCao · 01-30-2025, 10:01 AM

Hi guys,

In this webpage Options Menu - RoboDK Documentation, I learned that the output of the program can be custimized depending on the settings. However, I am little bit confused with the negatives values in "Maximum step size (deg)" and "Maximum step size (mm)" settings in the program tab. I would like to know the meaning of negative signs here. The screenshot of the options is in the attachment.

Gratitudes with the replies.

**Albert** · 02-03-2025, 01:35 PM

A negative value (or -1) in the settings window usually means that the setting is disabled.

GarrisonCao · 02-06-2025, 09:59 AM

(02-03-2025, 01:35 PM)Albert Wrote: A negative value (or -1) in the settings window usually means that the setting is disabled.

Hi Albert, thanks for the reply. However, I encountered some strange things in generating the NC Code. With the same path and post-processor (GCode NCP), but different settings in the program tab, the generated NC Codes have some differences. In line N00006, one angle A is positive, and one angle A is negative.
This code is generated from the default setting: Minimum step size (mm) 0.005, Maximum step size (mm) -1.00, Maximum step size (deg) -1.00

Code:
; Program P20kg_circle_0

N00001 F15000 ; Set default speed

; Program generated by RoboDK v5.8.0 for autonox articc6-1803-20kg (AT-00014)_md on 06/02/2025 09:30:30

; Using nominal kinematics.

F60000.000

; Using reference frame: X=378.000 Y=1062.000 Z=251.500 A=0.000 B=0.000 C=0.000

; Tool frame set to: Werkzeugwechsler

; X=0.000 Y=0.000 Z=0.000 A=0.000 B=0.000 C=0.000

N00003 M72 T=-1

; N00004 M108 T=...   ; Set Drillbit typenumber (not implemented)

; Anzeigen Werkzeugwechsler

N00005 G00 Q1=53.774200 Q2=27.704000 Q3=82.894400 Q4=0.000000 Q5=69.401600 Q6=53.774200

N00006 G07 X=778.000 Y=1062.000 Z=251.500 A=180.000 B=-0.000 C=180.000

F3000.000

N00007 G07 X=777.272 Y=1037.886 Z=251.500 A=180.000 B=-0.000 C=180.000

N00008 G07 X=774.571 Y=1009.736 Z=251.500 A=180.000 B=-0.000 C=-180.000

N00009 G07 X=769.887 Y=981.846 Z=251.500 A=180.000 B=-0.000 C=180.000

N00010 G07 X=763.244 Y=954.358 Z=251.500 A=180.000 B=-0.000 C=180.000

N00011 G07 X=754.676 Y=927.407 Z=251.500 A=-180.000 B=-0.000 C=180.000

N00012 G07 X=744.225 Y=901.129 Z=251.500 A=180.000 B=-0.000 C=-180.000

N00013 G07 X=731.943 Y=875.656 Z=251.500 A=180.000 B=-0.000 C=180.000

N00014 G07 X=717.892 Y=851.113 Z=251.500 A=-180.000 B=-0.000 C=-180.000

N00015 G07 X=702.143 Y=827.625 Z=251.500 A=180.000 B=-0.000 C=180.000

N00016 G07 X=684.773 Y=805.308 Z=251.500 A=-180.000 B=-0.000 C=180.000

N00017 G07 X=665.869 Y=784.275 Z=251.500 A=180.000 B=-0.000 C=180.000

N00018 G07 X=645.527 Y=764.629 Z=251.500 A=-180.000 B=-0.000 C=180.000

N00019 G07 X=623.847 Y=746.470 Z=251.500 A=180.000 B=-0.000 C=180.000

N00020 G07 X=600.939 Y=729.888 Z=251.500 A=-180.000 B=-0.000 C=180.000

This code is generated from the default setting: Minimum step size (mm) 0.01, Maximum step size (mm) 0.05, Maximum step size (deg) 1.00

Code:
; Program P20kg_circle_0

N00001 F15000 ; Set default speed

; Program generated by RoboDK v5.8.0 for autonox articc6-1803-20kg (AT-00014)_md on 06/02/2025 09:42:18

; Using nominal kinematics.

F60000.000

; Using reference frame: X=378.000 Y=1062.000 Z=251.500 A=0.000 B=0.000 C=0.000

; Tool frame set to: Werkzeugwechsler

; X=0.000 Y=0.000 Z=0.000 A=0.000 B=0.000 C=0.000

N00003 M72 T=-1

; N00004 M108 T=...   ; Set Drillbit typenumber (not implemented)

; Anzeigen Werkzeugwechsler

N00005 G00 Q1=53.774200 Q2=27.704000 Q3=82.894400 Q4=0.000000 Q5=69.401600 Q6=53.774200

N00006 G07 X=778.000 Y=1062.000 Z=351.500 A=-180.000 B=-0.000 C=180.000

; Splitting Linear movement in 2000 (instruction 7: MoveL 3)

N00007 G07 X=778.000 Y=1062.000 Z=351.450 A=-180.000 B=-0.000 C=180.000

N00008 G07 X=778.000 Y=1062.000 Z=351.400 A=-180.000 B=-0.000 C=180.000

N00009 G07 X=778.000 Y=1062.000 Z=351.350 A=-180.000 B=-0.000 C=180.000

N00010 G07 X=778.000 Y=1062.000 Z=351.300 A=-180.000 B=-0.000 C=180.000

N00011 G07 X=778.000 Y=1062.000 Z=351.250 A=-180.000 B=-0.000 C=-180.000

N00012 G07 X=778.000 Y=1062.000 Z=351.200 A=-180.000 B=-0.000 C=180.000

N00013 G07 X=778.000 Y=1062.000 Z=351.150 A=-180.000 B=-0.000 C=180.000

N00014 G07 X=778.000 Y=1062.000 Z=351.100 A=-180.000 B=-0.000 C=180.000

N00015 G07 X=778.000 Y=1062.000 Z=351.050 A=-180.000 B=-0.000 C=180.000

N00016 G07 X=778.000 Y=1062.000 Z=351.000 A=-180.000 B=-0.000 C=180.000

N00017 G07 X=778.000 Y=1062.000 Z=350.950 A=-180.000 B=-0.000 C=180.000

N00018 G07 X=778.000 Y=1062.000 Z=350.900 A=-180.000 B=-0.000 C=-180.000

N00019 G07 X=778.000 Y=1062.000 Z=350.850 A=-180.000 B=-0.000 C=-180.000

N00020 G07 X=778.000 Y=1062.000 Z=350.800 A=-180.000 B=-0.000 C=180.000

Do you know what could be the possible solution to it? Thanks again for the reply with deep gratitude.

**Albert** · 02-07-2025, 11:47 AM

When expressing a Cartesian target using Euler angles it is normal to see this behavior (one of the Euler angles swapping between +180 deg and -180 deg) due to numerical tolerances when calculating the Euler angles from a pose. In practice, the target should be exactly the same in both circumstances because you are just adding or subtracting 360 deg to one of the rotations, which should have no effect.

I understand this could pose issues with Siemens Sinumerik robot controllers. Is that correct? If so, to fix this issue, you could customize a filter in your post processor to use the value closest to your previous value by adding or subtracting 360 deg.

GarrisonCao · 02-07-2025, 12:36 PM

(02-07-2025, 11:47 AM)Albert Wrote: When expressing a Cartesian target using Euler angles it is normal to see this behavior (one of the Euler angles swapping between +180 deg and -180 deg) due to numerical tolerances when calculating the Euler angles from a pose. In practice, the target should be exactly the same in both circumstances because you are just adding or subtracting 360 deg to one of the rotations, which should have no effect.

I understand this could pose issues with Siemens Sinumerik robot controllers. Is that correct? If so, to fix this issue, you could customize a filter in your post processor to use the value closest to your previous value by adding or subtracting 360 deg.

Hi Albert, thanks for the explanation. Sadly our controller cannot deal with this problem, our controller is established in Beckhoff. I have already integrated a filter in our customized post-processor to fix this issue. However, when we generate the NC Code, values in the very first line matter a lot. Because it will influence how I manipulate every value by adding 180 deg or subtracting 180 deg. Do you know how to verify the correctness of the first line without trying on the robot?... Really really appreciate your reply.

**Albert** · 02-07-2025, 12:39 PM

What do you mean by verifying the correctness of the first line?

Adding or subtracting 360 deg to any of the Euler angles should have no effect. Because the resulting pose is the same. However, you could try to prevent the -180 deg output by forcing to add 360 deg.

GarrisonCao · 02-07-2025, 12:58 PM

(02-07-2025, 12:39 PM)Albert Wrote: What do you mean by verifying the correctness of the first line?

Adding or subtracting 360 deg to any of the Euler angles should have no effect. Because the resulting pose is the same. However, you could try to prevent the -180 deg output by forcing to add 360 deg.

In our test, in RoboDK the simulation shows that the first posture of the vector of the sixth axis should be perpendicular and pointing to the ground. But when we are trying it out on the robot, the vector of the sixth axis is perpendicular however pointing to the sky, in an opposite direction.
We found out the possible reason is that there is a minus symbol before 180, just like the code I pasted in my first reply.

Thanks for the solution, I will try it in our post-processor.