RTCP setup for 5axis A/B table/table horizontal mill

[TomKerekes]

Hi dd,

It seems Break Angle/corner rounding is totally broken in this Version 4.35d! I assume that is why you have Break Angle set to zero? That would cause slow jerky motion in segmented corner curves.

It seems besides that there is a bug where on the line N88 there is a microscopic xyz motion with small but significant angle change of ~1 degree total. Because the xyz motion is so small (less than the collinear tolerance) it is treating the feedrate as pure angular instead of linear. The F500 converts to 0.32 inches/sec but erroneously is used as 0.32 degrees/sec so the 1 degree move takes about 3 seconds.

We will need some time to figure out what is going on.

Thanks for all the clear information, but could you also post/re-post your latest kinematics with the constants you are using. The GCode selects H2 could you specify the tool length for Tool #2. That way we should be able to be trajectory planning exactly the same as your system.

[daredevil]

Hi Tom
thanks for your support,

please find attached my kinematics files including txt with constants (I have 2 possible horizontal mill configurations depending of the A axis home position: AC or AB "selfmade"), in both cases my 0 Machine is the center of rotation axis (AB or AC) so the constants are all 0.

You are right, I had to disable the Break Angle because it produces dangerous gcode modifications during the mill operation, please find below the example of this (simple lateral cylinder mill in RTCP mode):

Coming back to my feedrate issues the H2 tool length for the squared profile used is 41.6294 mm.

I appreciate your help very much,
thanks
dd

[TomKerekes]

Hi dd,

Sorry for the delay. Nothing in Trajectory Planning or 5 axes Kinematics is ever easy

The Break Angle issue should be fixed. I normally set Break Angle to 179 degrees so everything is rounded where possible.

Running the GCode with the Kinematics is fairly smooth. But there are still some slowdowns in the corners but not for seconds like before where feed rate were comletely wrong. This is because of some quirks in the GCode. Here is a zoom in. Notice the zig-zags

ZigZag.png (9.92 KiB) Viewed 2020 times

Here is a GCode fragment as an example

N10 G17 G21 G94 G90 G49 G40
N16 G54
N224 X14.743 Z14.298 B227.79
N226 X15.102 Y-1.075 Z13.799 B232.7 A-125.16
N228 X15.363 Y-1.056 Z13.287 B236.85 A-125.41
N230 X15.366 Y-1.167 Z13.265 B234.37 A-122.38
N232 X15.554 Y-1.075 Z12.728 B238.25 A-124.45
m30

Normally Collinear Tolerance might be able to smooth/filter such a thing. But in this case there is a significant Angular change (~ 2 degrees) over that small segment so it can't be removed or combined. The 3 GCode blocks change B by approximately +4, -2, then +4 degrees. So it isn't clear how that pause could be removed without altering the GCode.


Another issue is the segmenting in the corners. Here is an example:

Corner Rounded raw GCode.png (8.87 KiB) Viewed 2020 times

Normally Corner Rounding would smooth that out to avoid rough motion and some slow down. However there are significant AB angle changes (~5 degrees) for each segment. It is sort of complicated to explain but Kinematics is computed at segment endpoints and then the axes positions are linearly interpolated in between. Small segments along a curve will follow the curve with small errors and larger segments will have larger errors. For example imagine a point on your Table 10 inches away from the center of rotation. Then imagine the Table rotates 1 degree. The point will actually move through a arc. If instead we assume a straight line motion between the points there will be some error deviation. The amount of error depends on the angular change and the radius. The deviation is roughly proportional to the square of the angle and proportional to the radius. Here is a diagram showing moving from A to B through angle t:

There is a parameter in the Kinematics to control the maximum angular change that is allowed without sub dividing the motion.

m_MotionParams.MaxAngularChange = 0.5; // limit the segment angle change for nonlinear systems

Your code set 0.5 degrees. This limits errors at 10 inch radius to 0.1 Thousands of an inch (4um). That seems excessive. I changed this to 2 degrees which limits errors to 1.5 Thou (60um). The resulting longer segments allow some corner rounding as shown below. Changing CAD setting to output shorter segments would also help.

Corner Rounded 2 degree max kinematics.png (9.35 KiB) Viewed 2020 times

Here is a patch for V4.35d. The changes are all within the GCodeInterpreter.dll. You should just be able to copy that to your Version 4.35d \KMotion\Release Folder. The binary and sources if you need them are located here.

Please let me know if this makes sense and what improvement or issues you encounter.

[daredevil]

Thank you very much Tom!
I will test everything in the we and let you know,
all my best
dd

[daredevil]

Hi Tom,
I have tested your new GCodeInterpreter.dll and it works great!

Also break angle works with previous cylinder gcode, and according to your advice I put 179 degrees value to optimise the path.

I agree with your modifications in kinematics tolerance, also because I normally mill wood materials, and I do not need extreme path precision, it is better smoothness and speedness during the operations.

Related to this, which is your suggestion for the collinear/corner tolerance and facet angle degrees values (arcs to segment flagged) in the Trajectory Planner Tool Setup Screen in KMCNC? (before testing the new GCodeInterpreter.dll I had to lower the collinear/corner tolerance to a very small value such as 1e-5 to avoid feedrate change issue).

THANK YOU AGAIN VERY MUCH FOR YOUR GREAT SUPPORT!
Kflop card is now unbeatable value for 5 axis continuous RTCP operations!

Have a nice day
dd

[TomKerekes]

Hi dd,

That's great.

Regarding Trajectory Planner settings: You should be able to set Collinear Tolerance and Corner Tolerance to around 0.002 inches with Facet angle of 2 degrees to get some additional smoothing. Although as I tried to explain before there are certain cases where there will be limited benefit.

Thanks for your patience.

[daredevil]

Hi Tom,
continuing testing the new SW trajectory planner, I have found the following issues, playing the attached 5 axis path:
- rapid moves (with all 5 axis involved) sometimes exceeds the maximum linear axis setup (both in init.c and kmotioncnc trajectory planner axis parameters): for example if you play with single step the gcode line N18 the maximum linear FR is ok, if you play with "gcod START" it doubles in my case.
I can solve the above issue limiting G0 lines with G1 FXXX but I would like to avoid that motors mill exceed their limits (avoiding lost steps), please indicate me how can I limit GO moves.
- the second and most important issue is in the gcode line N20 when calling the G43.4 command: once again if I run the line with "single step" everything is ok, but if I play during gcode (due to new mill point space position) the Kflop tries to command the mill stepper motors to make this "quantum leap" in a fraction of second and the steppers linear axis loose immediately steps/red driver alarm light switches on (I need to connect this alarm to the kflop in order to stop the gcode but this is another story...).
I underline the fact that if I run the lines till N24 with SINGLE STEP eveything plays OK: the mill does not move when calling the g43.4 command (only DROS change) and then in the lines N22 and N24 the mill reaches the above called "quantum leap". Please take a look to these pictures:

just before G43.4

the "quantum leap"

the mill reaches the new coordinates of G43.3 traslation with N22/24 lines

Starting playing the gcode in normal mode from N26 line the trajectory planner is perfect!

Please give me a solution for the initial gcode part (G43.4 quantum leap issue) and the rapid moves in order not to loose steps/block the axis.
(attached also my tool setup where I tried to reduce rotary axis speeds with no results limiting the rapid moves)

Thanks in advance,
tonight we will stay awake in order to know who will be your new President!

dd

[TomKerekes]

Hi dd,

Regarding Rapids I believe turning on Rapids as Feeds option is required for nonlinear kinematics.

Regarding "quantum leap": That appears to be an issue with turning on and off TCP on the fly so that the GCode Coordinates become out of sync. Here is a patch for KMotion4.34d that should flush/sync whenever the TCP mode is changed. It also includes the previous patch for the Break Angle and your Kinematics changes. Copy this GCodeInterpreter.dll to your \KMotion\Release folder. If you need the changed sources they are here.

Please let us know if this resolves the issues.

[daredevil]

Thank you very much Tom!
I will try the new gcodeinterpreter.dll and let you know asap,
so if I turn on "Rapids as Feeds", the G0 FR is determined by the axis parameters (vel/acc/jerk) inside the init.c file, correct?
thanks again
dd

[TomKerekes]

Hi dd,

so if I turn on "Rapids as Feeds", the G0 FR is determined by the axis parameters (vel/acc/jerk) inside the init.c file, correct?

No. The G0 is then determined by the Velocity and Acceleration in the Trajectory planner settings.