Skip to content
This repository has been archived by the owner on Jan 14, 2024. It is now read-only.

Jerk Control #83

Open
MARIOBASZ opened this issue Aug 30, 2020 · 16 comments
Open

Jerk Control #83

MARIOBASZ opened this issue Aug 30, 2020 · 16 comments

Comments

@MARIOBASZ
Copy link

MARIOBASZ commented Aug 30, 2020

Could you implement jerk control or some jerk relief by adding some intermediate point (or more) in the trapezoidal profile of acceleration?
I think something like acceleration is a part (example 1/3) of the established to reach a certain speed and between this speed and zero.
For trochoidal cutting mode it would be good to increase the acceleration with fewer jerks.

image

@terjeio
Copy link
Owner

terjeio commented Aug 31, 2020

S-curve would be better?

I have been pondering about converting the step generator into a plugin for a long time, but it is currently low priority. E.g. it would be nice to be able to offload this part of grbl to a FPGA...

My plan is to let grblHAL go into a lockdown phase and focus on sender development. And I have many private projects on hold so it will be a while before I am able to spend any time on this. It would be nice if someone else could give it a try.

@terjeio
Copy link
Owner

terjeio commented Sep 4, 2020

Lots of interesting stuff in this LinuxCNC thread.

@Harvie
Copy link
Contributor

Harvie commented Nov 22, 2020

S-curve would be better?

Indeed https://www.youtube.com/watch?v=qYJpl7SNoww

@hankecnc
Copy link

hankecnc commented Oct 5, 2021

S曲线会更好吗?

想把step generator转成插件很久了,但是目前优先级很低。例如,能够将 grbl 的这一部分卸载到 FPGA 会很好......

我的计划是让 grblHAL 进入锁定阶段并专注于发件人开发。而且我有很多私人项目被搁置,所以我还需要一段时间才能花时间在这上面。如果其他人可以尝试一下,那就太好了。

Take your time buddy

video_20211005_081730.mp4

I don't understand programming. The shaking of the machine is due to the T-shaped acceleration and deceleration. The short line segment and the long line segment are treated the same? Should the percentage acceleration and deceleration be based on the length of the line segment?

The violent shaking point is located here
aa

@hankecnc
Copy link

hankecnc commented Oct 5, 2021

我的计划是让 grblHAL 进入锁定阶段并专注于发件人开发。而且我有很多私人项目被搁置,所以我还需要一段时间才能花时间在这上面。如果其他人可以尝试一下,那就太好了。

Have you considered making grbl closed-source charging? Use grbl as a motion controller, and the user will make the PC software, so you will have a lot of energy and time to improve it

@karoria
Copy link

karoria commented Oct 5, 2021

g2core project uses jerk control motion since long. The dark side of that is they could not still achieve feedrate overrides in g2core as per my knowledge. Consider when you configured x, y and z max speed different and you are running a 3d movement which involves motion of all 3 axis. That time it is difficult to model it mathematically for s curve acceleration with feedrate overrides.

@hankecnc
Copy link

hankecnc commented Oct 5, 2021

g2core

g2core? I just went to understand, they advertised as 6-order jerk control motion planning,

Sir, have you experimented with a CNC machine? How does he perform? (I am testing grblhal now, there is no time for now)

@karoria
Copy link

karoria commented Oct 5, 2021

@hankecnc
I dont actually understand what they are saying about 6th order acceleration. I guess it should be S curve motion. I may be wrong on this. S curve itself is a wonderful acceleration planning. Let me tell you orders (derivatives respect to time) in terms of mathematics as under:
1st order: Distance (s)
2nd order: Velocity (v=ds/dt)
3rd order: Linear Acceleration (a=dv/dt)
4th order: S curve Acceleration (sa=da/dt)
After that, I dont think a normal human brain can be able to grasp its real nature. S curve is already best acceleration as per me. Good quality elevators use s curve so that we cannot even feel how fast they are.
Coming to its application in machine. It is best if we can implement it. Industrial controllers like siemens, fanuc, mitsubishi have s curve implemented in their controllers. But at the same time, it should not be at the cost of deprecated features or unstable system. As I already said, motion planning becomes lot more difficult for developers in that case.
I was following g2core before 3 years and made one machine also from it. But then left it because of inactivity, especially I was in need of overrides, which was never implemented. At this time, most robust opensource firmware is undoubtedly grbl.

@terjeio
Copy link
Owner

terjeio commented Oct 5, 2021

I am not sure this is relevant: grbl (and grblHAL) plans to a full stop. If there are a lot of short moves (e.g. arcs since they are split into many small line segments) then high feed rates cannot be sustained unless the planner buffer size is increased. Also, how the sender submits data may affect this, if not using the character counting protocol to keep the input buffer filled then that may also affect motion (since the planner buffer might be emptied before new motion commands arrive).

I find this LinuxCNC page informative. Full G61/G64 support should be added to grblHAL?

@JasonTitcomb
Copy link

The violent shaking point is located here aa

Can you provide the gcode file?

@hankecnc
Copy link

hankecnc commented Oct 5, 2021

剧烈震动点在此 aa

你能提供gcode文件吗?

For GRBL's T-shaped acceleration and deceleration, as long as the acceleration is set too high, the feed is too high, and many continuous small line segments (especially wood reliefs) are encountered, the machine will vibrate violently.

I set the acceleration of my grblhal to 150
aa.txt

@hankecnc
Copy link

hankecnc commented Oct 5, 2021

gcode
gcode.txt

@MARIOBASZ
Copy link
Author

As long as there is no jerk control, the openpnp plugin has been useful to modify the acceleration with an M command in that job

@MARIOBASZ
Copy link
Author

M204 (modify acceleration) is useful to me.
If you could send an order in real time, it would be even more wonderful.

@JasonTitcomb
Copy link

Those are helix moves in the gcode. Seems like that should be smooth motion.

@atlesg
Copy link

atlesg commented Nov 3, 2021

@hankecnc I dont actually understand what they are saying about 6th order acceleration. I guess it should be S curve motion. I may be wrong on this. S curve itself is a wonderful acceleration planning. Let me tell you orders (derivatives respect to time) in terms of mathematics as under: 1st order: Distance (s) 2nd order: Velocity (v=ds/dt) 3rd order: Linear Acceleration (a=dv/dt) 4th order: S curve Acceleration (sa=da/dt) After that, I dont think a normal human brain can be able to grasp its real nature. S curve is already best acceleration as per me. Good quality elevators use s curve so that we cannot even feel how fast they are. Coming to its application in machine. It is best if we can implement it. Industrial controllers like siemens, fanuc, mitsubishi have s curve implemented in their controllers. But at the same time, it should not be at the cost of deprecated features or unstable system. As I already said, motion planning becomes lot more difficult for developers in that case. I was following g2core before 3 years and made one machine also from it. But then left it because of inactivity, especially I was in need of overrides, which was never implemented. At this time, most robust opensource firmware is undoubtedly grbl.

Trapezoidal is 2nd order
S-Curve is 3rd order, and S-Curve has different variations as well

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants