LinuxCNC S-Curve Accelerations

More
16 Jun 2020 02:38 #171810 by Todd Zuercher
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.)
The following user(s) said Thank You: Nico2017

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 12:45 #172232 by arvidb

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:
typedef struct simple_tp_t simple_tp_t;
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):
joint->free_tp = simple_tp_fetch(joint_num);

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.

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:10 - 21 Jun 2020 16:11 #172246 by arvidb
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.
Last edit: 21 Jun 2020 16:11 by arvidb.

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:20 #172247 by tommylight
I just know the acceleration while jogging is half of what is set in the ini, also half of when running gcode.

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:33 - 21 Jun 2020 16:36 #172249 by arvidb
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.
Last edit: 21 Jun 2020 16:36 by arvidb.

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:38 #172252 by tommylight
Changing the overall acceleration, yes in the ini file.
Changing the jog acceleration to full value set in the ini, i do not know.
Sorry, i just bumped into that a while back testing some very fast cnc plasma machines i am building here:
forum.linuxcnc.org/show-your-stuff/38547...plasma-build?start=0
RodW also bumped into it at the same time as i did, so we compared some notes and came to the same conclusion you did.

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:41 #172254 by tommylight


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

Well yes and no.
Yes it will change the distance required to stop, but it will stop at the soft limits properly.
No, as it is very easy to repeatedly press a button and cause the machine to jerk badly, especially the bigger machines with a lot of weight to move, if full acceleration is used.

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:46 #172258 by cmorley
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

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 16:59 #172259 by arvidb
So... do you think it's a way to reduce jerk, or does someone actually need lower acceleration when jogging?

Please Log in or Create an account to join the conversation.

More
21 Jun 2020 17:12 #172260 by cmorley
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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.210 seconds
Powered by Kunena Forum