Occasional unrealistically high velocities causing position errors.

Home › Forums › TinyG › TinyG Support › Occasional unrealistically high velocities causing position errors.

Tagged: , ,

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • December 29, 2020 at 10:25 am #11927
    JTW
    Member

    Hello All,

    I am using a tinyG v8 in an internally developed 3D printer application. It is set up to drive NEMA23s in X and Y via T8-8 leadscrews, and a pair of NEMA17s in the Z via T6-1 leadscrews. It is supplied with 350w 24vdc power and driven via my own software that feeds gcode to the tinyG via a queue keeping the buffer about 2/3rds full (about 9 out of 32 buffers free).

    For the most part the implementation has been very successful. We have been using several of our systems for over a year with great results. Recently however we are getting a rash of position errors (shifts) where you can hear one of the X or Y stepper motors “spin out” resulting in a positional shift.

    When investigating, I find that the tinyG reports back an absurdly high velocity when the error occurs as compared to other moves of similar length and the same velocity request. For example, a typical 2mm move in the X might have a velocity request of 6500, but report back that it achieved 750… which is perfectly reasonable for a short move. When the error occurs, that same 2mm move has a reported velocity of 6058 which appears to make the motor “spin out” (i.e. make noise but not move).

    Here are bullets outlining the situation:
    – The errors are exactly repeatable at the same place in my gcode files on multiple systems when they do occur.
    – We have not changed hardware (motors, leadscrews, power, etc.) and the hardware still feels smooth when moving it by hand. In other words, things do not feel worn out.
    – We have not changed any parameters (i.e. jerk accel, max vel, etc.) for over a year now, and did not experience these errors until recently on multiple units and multiple files.
    – No tinyG updates have been done over the past year.
    – The error is rare, but frequent enough to be concerning. It happens once out of maybe 100k moves, but when it happens it is catastrophic.
    – The gcode generating software is dynamic and evolving. It and the model files it operates on are the only two things changing. However, there does not seem to be a clear connection between their evolution and the error.

    Has anyone experienced anything similar? Any suggestions?

    Thanks in advance,
    John

    December 30, 2020 at 10:25 am #11928
    cmcgrath5035
    Moderator

    Give this a read. I am thinking you are experiencing a variant of the arc specification error issue, assuming you are generating G2 and G3 moves in your custom generator.
    Give this item a read https://synthetos.comtopics/arc-specification-errors-and-decimal-accuracy.

    With so much of your setup custom, hard to get really specific.

    Working in mm, rather than inch frequently solves it.
    Using only G1 moves virtually always works.

    In the early days, this was often referred to as the “huge I,J” issue, translating to very slight arcs. Do probelmatic commands show very large I,J ?

    December 30, 2020 at 11:12 am #11929
    JTW
    Member

    Thanks very much for your input!

    I did give the other thread a read, and altho interesting I don’t think its the same thing for two simple reasons: (1) all moves generated by my code are either G0 or G1 … my code is not sophisticated enough yet to use arcs, and (2) I am already working in millimeters.

    Wondering out loud, could the resulting high velocity value tinyG reports back be cause or effect? What seems to be happening for reasons that I do not understand is that the planner is not generating an “S-curve” for this one move and instead hitting it with a step acceleration (jerk) that spins it out. As a result the velocity reported back is near the maximum allowed.

    Would it help for me to create a drop box repository outlining the specifics? (tinyG setup commands, gcode stream, return stream)

    Cheers!
    John

    December 30, 2020 at 11:59 am #11930
    cmcgrath5035
    Moderator

    Well at least we have eliminated(?) some obvious items.

    To my knowledge, tinyG only makes moves along it’s calculate S curve.

    Do you make frequent changes to the G1 S (speed) parameter?
    Does your generator intermix a lot of G0 and G1 moves?

    i am not a developer, perhaps you will need to address this at the Issues interface, https://github.com/synthetos/TinyG/issues

    December 30, 2020 at 1:28 pm #11931
    JTW
    Member

    The more we can eliminate, the closer I am to an answer!

    Yes, the G1 speed does see frequent changes in the sense that it may get a feedrate request of 3000 for a string of maybe 200 commands, then shift to feedrate requests of 6500 interleaved with G0 commands (at 7500 mm/min) for a few hundred commands. (Imagine drawing the perimeter of a complex polygon at a slow speed in a continuous sequence, then shifting over to orthagonal fill lines at high speed that draws a single pass with a G1 then make a tiny G0 step before drawing the next pass as one moves across the interior of the polygon.)

    And that answers your next question. Yes, there are many, many, G1-G0-G1-G0 sequences. In fact, this is where the error has always occurred!

    If this means anything more to you please let me know. Otherwise, thank you for your thoughts and I will shift over to the link you provided and start a thread there.

    Cheers!
    John

    December 30, 2020 at 2:34 pm #11932
    cmcgrath5035
    Moderator

    Having watched my Prusa printer do it’s thing, I have a good idea what your description above is all about.

    I’m wondering if somehow tinyG is attempting to convert a string of G1 and G0 commands to it’s S curve and somehow losing track of target velocity. Or put another way, is there an assumption that the S curve is comprised of only moves at a single target velocity.

    You may also want to have a look at G2, https://github.com/synthetos/g2/wiki and https://github.com/synthetos/g2/issues
    It replicates tinyG capability but adds a whole lot more. G2 targets 3D printing type applications – perhaps if you can understand the differences between tinyG and G2 you will understand your issue better.

    March 3, 2021 at 4:46 pm #11954
    JTW
    Member

    UPDATE: After some on/off debugging of this problem over the past couple of months I believe I have determined the cause, albeit not an elegant resolution.

    The problem (position error due to high velocity) occurs when a COLLINEAR series of G1, G0, and G1 moves occur. In my case, the tinyG was executing a G1 at a 45 deg angle (i.e. both X and Y axes engaged) over a move of about 10mm which is long enough to reach full velocity, followed by a short, 1mm, G0 move at the same angle (i.e. collinear), followed by another G1 move similar to the first again at the same angle (i.e. collinear).

    The result of that sequence is that the first G1 move executes properly, but then the tinyG ramps up to G0 speed, blows thru that end point and finishes at the end of the next G1 move (but does so in such a way that G1 move is a “spin-out” – that is, a position error).

    Has anyone seen this before? Is this a known bug? Does it have anything to do with setting jerk settings (jm/jd/ja)?

    Cheers!
    John

    March 3, 2021 at 5:33 pm #11955
    cmcgrath5035
    Moderator

    Interesting, and a somewhat odd Gcode sequence. First I have seen such a well documented situation. My guess is that the planner, always looking ahead to plan for the next move, gets confused about what maximum speed to plan for.

    My suggestion is to post this question at https://github.com/synthetos/TinyG/issues.
    That is where bugs get addressed

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