NEED HELP: Problem following a curve trajectory!!

Home Forums TinyG TinyG Support NEED HELP: Problem following a curve trajectory!!

This topic contains 8 replies, has 2 voices, and was last updated by  cmcgrath5035 3 months, 3 weeks ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #10559


    TinyG is running on an OX machine (OpenBuilds), NEMA23 Stepper motors and 24V@14.6Amp power supply.

    the machine has been running fine for a while, but lately I noticed that a portion of my cut was not accurate. I narrowed it down to a section that has a figure of a SPIRAL on it SVG File (Inkscape)

    Test Spiral

    I’m running CHILIPEPPR.

    At this moment, my machine is running with no load and I am using a pen to draw the output (after ruining some material). The speed is just 300 mm/min, but regardless of speed the result is always the same.

    I generated the code with JSCUT which generates just G1 codes (small lines).
    Here’s the G-Code GCode-JSCUT Original
    Here’s the Output Output-JSCUT-Original
    From the image, the machine made some strange and uneven movements, I expected to have a constant distance between cuts, but it varied from 2.5mm to 5mm.

    I verified the paths on CAMOTICS and CHILIPEPPR and all looks good and constant.

    What am I doing wrong??

    I took all the code generated on the previous stage and flipped it, meaning the first position is now last and the last is now first. The direction of the path now is INVERTED. But all coordinates are exactly the same as previously
    Here’s the new G-Code GCode-JSCUT Inverted
    Here’s the Output Output-JSCUT Inverted
    From the image, the machine made some strange and uneven movements, and more surprising is that the drawing is not the same as the original; where I used to have a gap of 2.5mm now is 5mm and where I used to have a gap of 5mm now is 2.5mm.
    This is the same coordinates on a series of very small straight lines, did not generate the same results. I get to the conclusion that it might not be an issue with my original drawing on Inkscape but something with the machine.

    Why is it that using the same set of coordinates, I’m getting a different result? Both wrong by the way.

    What has to be done in order to get the right output?

    I switched from JSCUT to MAKERCAM, and generated a new G-Code. This time MAKERCAM generated the code with G2/G3 codes as opposed to just G1 from JSCUT.
    Here’s the 3rd G-Code G-Code-MAKERCAM Original
    Here’s the Output Output-MAKERCAM Original
    As can be seen from the drawing it is exactly the same result I’m getting from the FIRST case, Meaning the gap of 5mm is where the original gap of 5mm was and the gap of 2.5mm is where the original gap of 2.5mm was. The figure is almost identical.

    This time – sound wise – the stepper motors were producing “music”.

    Two instruction’s set completely different are generating the exact same wrong output. One limited to G1 codes while the second using G2/G3 codes.

    I went to TinyG’s configuration and moved the JERK MAXIMUM at (million) 2, 10, 250, 5,000 and 10,000 and the problem is still there. The drawings are almost identical (at lower level the edges are a bit rounder, and a higher values the edges are sharper).
    Here’s the configuration file TiniG Configuration file that I’m currently using.

    I also moved the potentiometers to higher values with no change.

    After spending too many hours trying to figure this out, here I’m requesting support to solve this issue and better understand what’s happening and more important the limitations on TinyG.

    Thanks in advanced for your help!



    I have seen similar behavior in the past caused by loose set screws on the pulleys.
    Do your stepper shafts have flats?
    If not, grab a file and make some.
    Then make sure your set screws are centered on the flat and snug.

    What frequently happens, even with flats, is that the set screw loosens just enough for the pulley to rock back and forth from one side of the flat to the other

    A quick test would be to energize the motors(to apply holding torque), then grab the pulleys with you fingers and see if you can rock it back and forth.

    I’ll look closer at you excellent documentation this evening.
    Right now, it’s back to Irma cleanup.



    cmcgrath5035 thank you for your reply.

    Last night I took out all 3 stepper motors and tighten the tiny screws. The one on X was slightly loose.

    My stepper have flats and the screws are centered on the flat.

    It is amazing how accuracy depends on these tiny screws.

    The result is much better now, however it is still slightly deformed.

    Here’s an image of the new output after the adjustment Output after adjustment.

    At this point, I’m not certain that this is as good as I’ll get.

    More important, I hope you and your beloved ones are OK after Irma. In my prayers.

    Best regards



    Good progress.
    An unfortunate side effect of Ox using GT2 belts is the larger size pulley, compared to Shapeoko where $tr=42mm or so. The NEMA23’s provide the additional torque, but the really beat on the set screws.

    Do your pulleys have one set screw or two?
    When I reworked my SHO, I tapped in a second set screw at 45 degrees relative to the one I had. I then created a “mini-flat” under that screw for added grip.
    A two set screw arrangement would help.

    Thanks, we are some of the fortunate here in Irmas pat’h (Cape Coral).
    No house damage, just a lot of vegetation to process. Folks to our south are really hurting. Is the price we pay for living in paradise.



    You might want to rerun a machine calibration, to see if a perfect large square is, well, as perfect as you can measure it.

    $_tr=60.00mm is the correct theoretical setting for X an Y with GT2 belts and the stock pulleys. You might need to further tighten belts or perhaps tweak $_tr values to improve concentric curve accuracy.



    Thank you cmcgrath5035:

    I will run the calibration over the weekend.

    My pulley has 2 screws, the second one doesn’t do much as it doesn’t sit on any flat on the axe. As you said adding a “mini-flat” surface may help. I’ll need to look at how hard it is to make this 45 degree flat.

    I’ll keep you informed.

    Thanks and best regards.



    you might find that enlarging the size of the setscrew that engages the flat will help.
    And search for ‘cup’ of flat bottom set screws, rather than ‘tapered’ or pointed’. More surface to interact with the flat.
    Good luck



    Hi cmcgrath5035:

    I followed all of your recommendations and it really improved the output of the machine, here’s what I did:
    – Square the machine, it was a bit off
    – Calibrate $_tr, it was pretty close with the standard value, but anyway there was a very small adjustment to be done
    – Added the “mini-flat” to the motor axes
    – changed the small screws for flat bottom ones
    – Applied nail-polish to the small screws,
    – Tighten the belts, I realized that with all the movement these have to be adjusted regularly.

    Here’s what I realized: Most of these adjustment are temporary, because there is a flaw if this OX design, and no mater how thigh you do the adjustment, over time it will fail.

    On a previous post you mentioned:
    An unfortunate side effect of Ox using GT2 belts is the larger size pulley, compared to Shapeoko where $tr=42mm or so. The NEMA23’s provide the additional torque, but the really beat on the set screws.

    1. Could you expand on this?
    2. Does changing the pulleys help alleviate this problem?
    3. any recommendation on pulley size?
    4. Is a pulley the way to go, especially for X axes, would it make more sense to change it altogether to a screw system? (like Z Axis)?
    5. What are the pros-cons of changing X to a screw system?
    6. If it makes sense to change to a screw system for X axis, could you point me to where could I start searching?

    On a slightly different subject, I’ll start looking for a 3D printer, more likely a delta construction. Could you give point me on where should I start looking?

    Thanks for your support and bestregards.



    I am not an Ox owner, but there do seem to be many happy with their machines over at the Ox Forum

    Let’s not kid ourselves, even the big industrial machines need good maintenance. It would appear you have discovered the critical areas to keep track of.

    There is no easy answer to the screw vs belt question. Screw machines are costly to scale(in size) but perhaps more rugged.
    Generally speaking, the lower the value of $_tr, the more usable holding torque from your motor spec you get.

    The torque/pulley issue.
    AFAIK, Ox specifies the smallest pulley that is generally available for GT2 belts, which are more rugged than MXL belts used in ShapeOko designs.
    Smaller pulley diameter is better, from a torque load perspective.
    It is perhaps easiest to think of the issue in terms of holding torque.
    If you energize your motors to hold a position, then try to push the gantry manually in X or Y direction, your pushing force is translated into a rotational load on the stepper shaft, the stepper pushes back with the torque available determined by how much current you dump into the stepper, which at rest is acting like a stationary electro-magnet.
    In this mode, the pulley diameter acts to amplify the amount of torque on the shaft you are creating by pushing on the belt. That torque amplification scales, I believe, as radius-squared, radius of the pulley.
    A long while back I did the math and came to the informal conclusion that an Ox with ‘good’ quality NEMA23 motors and ShapeOko with ‘good’ quality NEMA 17 motors had about the same gantry holding properties out-of-the box.
    The Ox design wins here for heavy duty users because there are a lot more stepper options above ‘good’ level in terms of available holding torque. And some folks have even gone to NEMA 34 motors.
    Alas, high torque motors, high current drivers, cooling systems and power supplies drive costs up quickly.

    I hope that helps, the math gets complex and there are way too many variables to get super specific.

    3DPtr: I am not a player yet, searching like your for alternatives. If you dig into G2core

    you will see that a lot of the recent work is targeted at 3DPtr enabling enhancements. G2Core is the motion engine for several evolving 3DPrinters.
    My take is that the bigger question in that space is around the CAM layer software features, functionality and the entire 3dPtr tool chain.

    A lot more complexity, and a lot more opportunity in 3D space, depending on what you want the end result to be.

    • This reply was modified 3 months, 3 weeks ago by  cmcgrath5035.
Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.