Trajectory Planner with Jerk limits

[TFrenken]

Hi Tom,
I currently use the KLP factor to reduce jerk during coordinated motion. But as this introduces a geometric error in some circumstances I am hoping for the implementation of a jerk limiter to the trajectory planner. Of course this is only needed for dynamic machines but as I am using KMotionCNC on a DMG DMU50 with 8 m/s2 and 22m/min it becomes quite important when using milling toolpaths with high feed rates and some rapids as feeds in between.
I do understand that this will add a lot of complexity to the trajectory planner but maybe it could be implemented in the future to get the KMotionCNC even closer to high grade industrial controls.

Regards,
Thomas

[TomKerekes]

Hi Thomas,

Yes we are always looking into this but it is very complex. For example following a U shaped "smooth" path will still require infinite jerk unless the path is reshaped. Doing this with potentially hundreds of 3D points/segments through multi dimensional paths is extremely difficult. Many systems that claim to do jerk limiting do not do it properly or optimally.

If you have suggestions or examples on how this could be achieved we'd be open for discussion.

Are you aware that Rapid moves are normally performed as 3rd order Jerk limited moves? See here. One caveat is that with non-linear systems (using non-linear Kinematics or geo Correction) a point to point move in actuator space will not be a straight line in CAD space. In systems that are nearly linear the non-linearity might not matter for the rapid move.

Another option might be to change the KLP factor with a custom MCode for when accuracy is or isn't as critical.

[TFrenken]

Hi Tom,

thanks for the reply. As a mechanical engineer I am only as much into software and programing as needed. I would try to get in touch with people from heidenhain or siemens.
Rapid moves work fine with jerk limitation but with trochoidal milling or high feed milling the paths with high feedrate (sometimes the same speed as rapids) have to use G02 or G03. But I will look into my CAM Software if some paths could be converted into linear G00 segments.

As for M Codes to change the KLP and maybe acceleration settings this might be a good idea to get the needed accuracy. Is it possible to change the acceleration setting of the trajectory planner with a custom C program?

Regards,
Thomas

[TomKerekes]

Hi Thomas,

Rapid moves work fine with jerk limitation but with trochoidal milling or high feed milling the paths with high feedrate (sometimes the same speed as rapids) have to use G02 or G03. But I will look into my CAM Software if some paths could be converted into linear G00 segments.

Well that wouldn't really help or work well. G0 Rapids are always performed point to point starting from a stop and then ending in a stop in one linear motion. There is no blending/smoothing between blocks. That is why it is relatively easy to perform 3rd order jerk limited motion for those cases.

As for M Codes to change the KLP and maybe acceleration settings this might be a good idea to get the needed accuracy. Is it possible to change the acceleration setting of the trajectory planner with a custom C program?

Not currently (other than the rapid parameters that the trajectory planner extracts from KFLOP/Kogna). We could add that if you would like to test.

You might also post some GCode fragment (with all your parameters) that you think is not executing smoothly or optimally for us to look at.

[TFrenken]

Hi Tom,
of course using G00 segments was a bad idea.

I think being able to change trajectory planner settings using a C code program would enable changing between high dynamic roughing and precise finishing parameters. This is something I know from industry grade controls, if it would be possible to implement I would be glad to test it.

At the moment there is always the compromise between high acceleration (8m/s2) and high KLP factor (Config_Tau_KLP = 0.04) or lower acceleration and KLP. It works fine if I am using lower speeds for finishing at the moment but it would be great if I could change the parameters and run the finishing much quicker with optimised parameters using M Codes to change them.

Regards,
Thomas

[TomKerekes]

Hi Thomas,

Here is a patch for 5.4.1 that should allow you to change TP Accelerations and Velocities.

These are now defined in KflopToKMotionCNCFunctions.c

Code: Select all

// Axis indices
#define AXIS_X 0
#define AXIS_Y 1
#define AXIS_Z 2
#define AXIS_A 3
#define AXIS_B 4
#define AXIS_C 5
#define AXIS_U 6
#define AXIS_V 7
#define NUM_AXES 8

// Parameter type indices
#define PT_VEL              0
#define PT_ACCEL            1
#define PT_COUNTS_PER_INCH  2
#define NUM_PARAM_TYPES     3


// Set a Trajectory Planner Parameter given Type and Axis
int SetTPParameter(int Type, int Axis, double value)
{
	SetUserDataDouble(TMP, value);
	persist.UserData[PC_COMM_PERSIST + 3] = TMP;       	// persist offset (doubles)
	persist.UserData[PC_COMM_PERSIST + 2] = Axis;       // Axis
	return DoPCInt(PC_COMM_SET_TP_PARAM, Type); // Parameter Type and Cmd
}


// Get a Trajectory Planner Parameter given Type and Axis
int GetTPParameter(int Type, int Axis, double *value)
{
	persist.UserData[PC_COMM_PERSIST+3] = TMP;       	// persist offset (doubles)
	persist.UserData[PC_COMM_PERSIST + 2] = Axis;       // Axis
	if (DoPCInt(PC_COMM_GET_TP_PARAM, Type)) return 1; // Parameter Type and Cmd
	*value =GetUserDataDouble(TMP);
	return 0;
}

KMotionCNC.exe Copy to the \KMotion\Release folder
PC_DSP.h Copy to the DSP_KFLOP or DSP_KOGNA folder or both.
KflopToKMotionCNCFunctions.c Copy to the C Programs Folder


Here is an example usage:

Code: Select all

#include "KMotionDef.h"
#define TMP 10 // which spare persist to use to transfer data
#include "KflopToKMotionCNCFunctions.c"

int main()
{
	double Accel;
	
    GetTPParameter(PT_ACCEL, AXIS_Z, &Accel);
    
    printf("Accel = %f inch/sec^2\n",Accel);

    SetTPParameter(PT_ACCEL, AXIS_Y, 111.1);
    
    GetTPParameter(PT_ACCEL, AXIS_Y, &Accel);
    
    printf("Accel = %f inch/sec^2\n",Accel);


    return 0;
}

One issue might be that any changes persist in the same way as if the operator changed them. That is they do not revert back to the original values on program exit/restart. So any parameters that you change should be set before use. e.g. by the Initialize C Program.

Please let us know of any issues.