Homing, travel maximum and limits

Home › Forums › TinyG › TinyG Support › Homing, travel maximum and limits

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • November 27, 2013 at 11:35 am #4979
    kajuk
    Member

    Hi,

    I received my v8 board recently, thank you!

    I’m coming from LinuxCNC and a few things confuses me.
    Yesterday I did the first test. I configured everything as per documentation using tgFX and everything moves almost as I expected. I did homing using limit switches and it responds to G0/G1 commands fine. But here comes a difference with LinuxCNC. When I give G0/1 commands in LinuxCNC which will cause it to go beyond physical axises dimensions, LinuxCNC aborts the commands with an error about exceeding limits. In contrast, TinyG accepts such commands and tries to go beyond limits and either trips home/limit switches or bumps into physical limits.
    Is this expected behavior or am I missing something?

    Second thing. Do I understand it right that the maximum acceleration is calculated from ‘Jerk maximum? and there is no way to set maximum acceleration and ‘S Curve’ curvature separately? If so, how do I calculate maximum acceleration from ‘Jerk maximum’?

    • This topic was modified 11 years ago by kajuk.
    November 27, 2013 at 1:08 pm #4983
    alden
    Member

    Soft limits are not in the TinyG master branch yet. They are in test in development and should be available in the next month or so. This will make TinyG react more like LinuxCNC in that regard.

    You are correct. Maximum acceleration is not independently settable as it’s derived from the jerk setting. I’m not sure how you would separate them in the way you would separate max acceleration and max velocity (for example). I have not gone through the exercise of deriving the acceleration from the jerk. Here’s a useful article I worked from when developing the acceleration management:

    http://www.et.byu.edu/~ered/ME537/Notes/Ch5.pdf

    November 27, 2013 at 1:50 pm #4984
    kajuk
    Member

    Thank you for clarification! A few more question.

    1. With the current firmware version, what is right way to make sure that it won’t go beyond physical limits when sending a gcode job to TinyG?

    2. Regarding S-Curve. Isn’t “5.5 S-Curve with Linear Period” from http://www.et.byu.edu/~ered/ME537/Notes/Ch5.pdf, that is S-Curve with limited maximum acceleration, exactly what needs to be implemented? The reason is that a machine may be happy with high ‘Jerk maximum’ but stalls if it reaches too high acceleration. It is kind of mixing pure S-Curve and pure Trapezoidal profiles.

    November 27, 2013 at 9:44 pm #4989
    alden
    Member

    I don’t have a good answer for what the best way to test Gcode for excess excursion with the current firmware. This is one reason we are adding soft limits. In the mean time you can use a Gcode viewer to draw the Gcode before sending it to the machine and seeing if it exceeds maximums.

    We have not implemented the S curve with linear segment (limited max acceleration, aka “7 segment moves” versus “5 segment moves”) for a variety of reasons. First, it appears that the additional math is beyond the ability of the Xmega to handle; at least handle and maintain the current top speeds that it can achieve. It’s pushing it to handle the simpler case. Second, given the amount of time spent just getting simple S curves running I’d rather not dive into the more complex cases for the incremental performance improvement afforded by going to 7 segment moves. What people have been doing is tuning the machine to the jerk with the maximum acceleration implicit in this tuning. Granted there is a bit more performance that can be eeked out of the machine if linear segments are implemented, but it’s a fairly complex bit of code to bite off for what should be a marginal improvement in performance.

    If you are interested in diving an and contributing please let us know.

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