LinuxCNC S-Curve Accelerations

The planner need needs to use the allowed path deviation to calculate a path with minimum jerk (up to the jerk limit allowed) that lies within the allowed deviation of the programmed path, then control feed rate to make up the difference. (The same way acceleration is compensated for with any change of direction.) As it is now infinite jerk is allowed and the difference between what is calculated and what is reality simply results in an un-calculated following error that the servo loops have to try to compensate for. (The same as the deviation that results while you turn the steering wheel in the car analogy.)

cmorley wrote:

I was thinking that using s curve in our jogging planner would probably be a good project too.
rapid acceleration is really the name of the game when jogging slowly.
It would surely be easier to to do then the full motion controller.

Chris M

The complete lack of data encapsulation in the source makes this much more difficult than it should be. The simple_tp_t struct is public and is allocated globally(!) as part of emcmot_joint_t and emcmot_axis_t (in motion.h), and code is touching the internal fields everywhere - e.g. handle_jjogwheels() in control.c sets free_tp.max_acc! I think this needs a major overhaul/cleanup before a sane implementation of a more advanced simple_tp can be made.

Is this something that the active developers would approve, or are people fond of their global state?

Another thing that complicates things compared to the full motion planner is that the simple_tp must be able to re-plan motion on the fly: it often receives a new pos_cmd while moving. The planner needs to be able to handle non-zero acceleration and velocity initial state, as well as changing velocity limits while moving. So while a jerk-limited jogging planner might be easier than a full planner, it's still no small task. But yeah, the data encapsulation issue is the real hurdle, I think.

The way to do data encapsulation would be to do a forward declaration of simple_tp_t in simple_tp.h:Then change emcmot_joint_t and emcmot_axis_t to contain a pointer to simple_tp_t rather than the actual struct, and initialize the fields by calling a constructor function ("simple_tp_create()" or similar), probably in init_comm_buffers() in motion.c.

If people are very much against memory allocation like this, the required number of structs could be statically pre-allocated by the simple_tp implementation, and a pointer to the pre-allocated fields could be returned by simple_tp_create() (let's call it simple_tp_fetch() instead):
Then to clean up all the places that directly modifies the internal fields of the planner...

One thing that worries me is this: STRUCTS_IN_SHMEM. It seems these structs are allocated differently depending on this define. If someone could explain the mechanism & reason behind this, I would be grateful.

Why is a different acceleration limit used when jogging ((*(joint_data->jjog_accel_fraction)) * joint->acc_limit)? The physical machine limits should be the same regardless of control mode?

Edit: see get_pos_cmds() in emc/motion/control.c.

So it's a way to tame down the machine when jogging? Is there a user-accessible setting for this anywhere?

Edit: Seems like a bad idea in that case since it also greatly increases stopping distance.

IIRC separate jogging acceleration was added after the fact - I assume because someone required lower acceleration for jogging then machining.

If you want to experiment there is also a HAL component called simple_tp.
It is used by PnCcnf to simulate jogging control. it was a direct copy of motion's jogging planner (at one time anyways)

Chris

So... do you think it's a way to reduce jerk, or does someone actually need lower acceleration when jogging?

My guess is acceleration was lowered to compensate for a problem and that jerk control would help a lot.

Jogging on a powerful machine is a difficult process - as you said it is constantly resets it's end point and must be able to stop by the end of the last planned move.
Add in that turning a jog handle constantly is not a consistent speed, means the axis speed is constantly accelerating, so constantly jerking.

The part that makes it easier to code would be that only one axis must be calculated at a time.