saurabhsaurc

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

G28
G61
G1 Z2 F2000
G1 Z5 F2000
G1 Z10 A2 F2000
G1 Z20 A5 F2000
G1 Z30 A9 F2000
G1 Z40 A14 F2000
G1 Z50 A18 F2000
G1 Z60 A21 F2000
G1 Z70 A23 F2000
G1 Z80 A24 F2000
G1 Z90 A24 F2000
G1 Z100 A24 F2000
G1 Z110 A24 F2000
G1 Z120 A24 F2000
G1 Z130 A24 F2000

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.

Hi,

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.

Ok it worked!
My B and C axes were disabled ( $bam = 0 )