-
Notifications
You must be signed in to change notification settings - Fork 90
Jerk Control #83
Comments
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. |
Lots of interesting stuff in this LinuxCNC thread. |
|
Take your time buddy video_20211005_081730.mp4I 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? |
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 |
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. |
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) |
@hankecnc |
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? |
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 |
|
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 |
M204 (modify acceleration) is useful to me. |
Those are helix moves in the gcode. Seems like that should be smooth motion. |
Trapezoidal is 2nd order |
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.
The text was updated successfully, but these errors were encountered: