grblHAL
grblHAL copied to clipboard
terjeio
Jerk Control
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.
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.
S曲线会更好吗？
想把step generator转成插件很久了，但是目前优先级很低。例如，能够将 grbl 的这一部分卸载到 FPGA 会很好......
我的计划是让 grblHAL 进入锁定阶段并专注于发件人开发。而且我有很多私人项目被搁置，所以我还需要一段时间才能花时间在这上面。如果其他人可以尝试一下，那就太好了。
Take your time buddy
https://user-images.githubusercontent.com/69781416/135942293-11ed7812-ffa7-47c3-88fc-513c248f595a.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
我的计划是让 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
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
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 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.
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?
The violent shaking point is located here
Can you provide the gcode file?
剧烈震动点在此
你能提供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
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. If you could send an order in real time, it would be even more wonderful.
Those are helix moves in the gcode. Seems like that should be smooth motion.
@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
