The A-axis increases for a while, then becomes constant. The issue here is that the machine is stopping a bit between these two sections of code rather than executing it as a smooth motion.
Is the issue related to feed rate? What does feed rate even mean when linear and rotational axes are both involved? I just assumed that this would be the feed rate for z axis and the other two would be proportionally moved, but this doesn't seem to be what is happening, it seems to be slowing down and speeding up.
the NIST website appears to not be working at the moment.
I'm pretty sure the axes aren't reaching anywhere near their maximum feed rate.
$zvm and $zfr are set to 2000.
Rotary axes are set to standard mode, ie. input is in degrees.
All the axes are changing upto some point, and then A is kept at a constant while C and Z still change ( ref. gcode in prev. post ). That's where the break occurs instead of having a smooth motion.
So when I'm giving a command like G1 Z25.00 C53.84 A70.00 F1000.00, which axis feed rate is being referred to here? There's one translational and two rotary axes.
The motion control should aim to get all three axes converging at the same point in time. It uses the feed rate to determine the speed of convergence.
If, for example, your Z has to move 50mm, your A 10mm and your C 5mm, Z will move at the maximum feedrate, with A and C calculated to meet it at the appropriate feed rate to achieve this.
If your C has to move 270 degrees, your A 340 degrees and your Z 0.5mm, all axes will start moving at the same time, but your Z will be moving very slowly in relation to your other two axes.
You also need to factor in the type of motion control planning that TinyG implements, compared to other systems like GRBL. The S-curves of increasing/decreasing acceleration that the TinyG implements is very different from other systems, which makes for very complicated 3-axis movements in accelerate, sustain, decelerate motion.
Like a 3D helix created in real-time to ensure a point is reached in concert.
Unless this is resulting in an incorrect cut, I’m not sure why you should care about the individual rate of movement of each axis.
I must say, I’m a bit confused about what exactly is going wrong.
There is a break after the fourth line, when the A axis becomes a constant. There is a smooth motion for the first four lines, and a smooth motion for the next four, but between the two, the machine comes to a halt. I'm looking to avoid this if possible.
I hope that explains my use case. Otherwise I can upload a video if that is possible on this forum.
After some reading and testing, this is what I found.
G-Code supports 3 path control modes, G61, G1.1, and G64. G64 is for a continuous motion that sacrifices accuracy ( but this is not supported in TinyG, where it reverts back to G61, which is default ). In G61.1, it stops at every line of gcode, which is obviously not what we want. In G61, the default mode, it follows the path exactly, and stops only when there is large non-linear changes in motion.
So if I 'ramp up' the change in axis in my G-code, I am able to get a smooth motion
It can be improved further - I need to generate a true 'S' curve ( accelerating and deaccelerating ) for each of the axis motions, then I think it will work great.
You might want to experiment with jerk settings as well; think of jerk as an 'aggressiveness' setting for both ramp up and ramp down along the S curve.
Higher (larger) jerk --> more aggressive.
This topic is from the original forum (December 2018). Your reply starts a new discussion linked to it.