Help me with some g-code for smooth motion

Home Forums TinyG TinyG Support Help me with some g-code for smooth motion

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #11264
    saurabhsaurc
    Member

    Hi,

    This is more of a gcode question than a tinyG question.

    I am programming a machine to move along a certain trajectory. The g-codes are coming like this:

    G1 Z24.38 C53.49 A69.00 F1000.00
    G1 Z25.00 C53.84 A70.00 F1000.00
    G1 Z25.63 C54.17 A71.00 F1000.00
    G1 Z26.26 C54.49 A72.00 F1000.00
    G1 Z27.26 C54.98 A72.00 F1000.00
    G1 Z28.26 C55.47 A72.00 F1000.00

    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.

    Thanks for the help.

    #11265
    Zootalaws
    Member

    What are your $aam and $cam settings?

    You can move rotational axes in two modes: standard (degrees) and radius (linear).

    In standard mode, you tell it how many degrees, in radial mode, how far to move.

    Are all axes changing rate or just Z? What’s your feed rate maximum set to? What’s your travel minimum, travel maximum set to for your rotating axes?

    “Velocity max and feed rate are in degrees per minute and behave as per RS274 NGC v3 feed rate definitions”

    NIST doc RS274: https://ws680.nist.gov/publication/get_pdf.cfm?pub_id=823374

    A feed rate of 1000 would give you 16.66 degrees/second or ~21 seconds for a full rotation.

    #11266
    saurabhsaurc
    Member

    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.

    #11267
    Zootalaws
    Member

    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.

    #11268
    saurabhsaurc
    Member

    Okay! Here is some more testing I just did

    For this code

    G1 Z10 A20 F2000
    G1 Z20 A40 F2000
    G1 Z30 A60 F2000
    G1 Z40 A80 F2000
    G1 Z50 A100 F2000
    G1 Z60 A120 F2000
    G1 Z70 A140 F2000
    G1 Z80 A160 F2000

    The machine makes a smooth motion executing all eight commands. There isn’t any halting.

    For this

    G1 Z10 A20 F2000
    G1 Z20 A40 F2000
    G1 Z30 A60 F2000
    G1 Z40 A80 F2000
    G1 Z50 A80 F2000
    G1 Z60 A80 F2000
    G1 Z70 A80 F2000
    G1 Z80 A80 F2000

    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.

    #11269
    saurabhsaurc
    Member

    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.

    #11270
    cmcgrath5035
    Moderator

    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.

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.