Callibration of New Machine

Home Forums TinyG TinyG Support Callibration of New Machine

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #11088
    melticus
    Member

    Hi Guys,

    New to TinyG and CNC in General. I built my own CNC machine based on Tiny G on the Due. I am having troube with calibration. When I print a simple test project, the letters “FIRST CNC”, the first pass is OK, compressed in the x axis so I can use $xtr=20. When I do the second pass (To Go deeper) there seems to be an inaccuracy on the x axis. In particular when there is a curve in the letter I am cutting. Each time it restarts is seems to add .2 mm or so in the x direction. Also I looks like the Letters are “Slanted” like Italic.

    I cant attribute it to x or y inaccuracy. Is there a way I can send you guys a picture? Its hard to describe?

    Is there anything out there to help with callibration? I dont implement microstepping. Could this be related to it?

    What are the callibration commands in GCode that I can play with. I use the $xtr to correct the x and y but is there any other?

    Any help would be appreciated.
    M

    #11089
    Zootalaws
    Member

    That usually indicates one of your axes is slipping.

    Screw or belt?

    #11090
    melticus
    Member

    Its a belt Zootalaws.

    I ran it extreamly slowly ( limited the feed to to about 10mm per min and limited the seek to 100mm per min) same result.

    Another reason I think its not a slip because the “error” is exactly the same every time. A slip should show up as a step on one round.

    I also made an Astrix with the Jog Buttons at full acceleration 50000mm/min and I get perfect repeatability with a 500mm Astrix still goes perfectly to the middle everytime. I thought this would prove no slippage? (BTW I am testing this by replacing the tool with a pencil attachment.)

    With the current setting I have about .1mm accuracy (hope to improve it by adding micro stepping). Would this be a possibility? if my CAM is assuming microsteps then I will lose accuracy consistantly as the motors wont step? I am using CNC.js as my CAM program.

    Wish I had a way to show you the images.

    #11091
    cmcgrath5035
    Moderator

    Best way to show us a picture is to put it on your cloud drive (Gdrive, etc.) and provide a URL here.

    Are your pulley set screws real tight(the ones against the flat on the shaft) ?
    Are you sure your pencil mount can not allow 0.2 distortion?

    #11093
    melticus
    Member

    Thanks CMCGRATH5035. Here are my files:
    CamGTextJpgs

    The Cam.jpg shows the original file in CAM.js.

    Then I have two examples of the affected prints.

    There is an obvious X scaling issue. But you can see the italic type effect and the error between passes.

    I checked again the tightness as you suggest. but it is solid and the pencil is wedged in very tight. I cant see the issue as a slip though. it is too repeated. consistantly.

    #11094
    pca
    Member

    How are you zeroing the machine? It might be that when it returns to the home position, it mechanically hits an end stop or obstruction before it hits a limit switch, even only by a tiny amount, which causes the stepper motors to lose a few steps in a predictable manner each time. Essentially, as an example, you could go 1000 steps right, 1000 steps left again, but after 998 steps you end up hitting something that causes you stop moving and lose those last two steps.That might only be a rough spot on the carriage mechanism if the torque is too low.

    The end result would be each time you repeated the process, you’d move another two steps further out, giving something not dissimilar to what you’re seeing.

    I’ve had problems on a laser cutter that turned out to be something a little like that caused by some detritus on the rail which acted like a one way bearing, so the carriage would go over it in one direction without noticing and momentarily stall in a fairly consistent manner in the other.

    Just a thought.

    #11095
    pca
    Member

    As an update to my post, I would suggest you create a gcode file by hand which is just a series of back and forth moves on one axis and accurately measure how far it goes in both directions over a number of repetitions at different speeds and distances. Check it’s doing the same travel both ways, and very carefully observe your pulleys, stepper motor shafts, and any mechanical connections for unwanted movement. Do each axis in turn, then try diagonal movements too.

    Hope this helps 🙂

    #11096
    melticus
    Member

    Thanks PCA but I dont think thats it. I dont have end stops. I just set the machine home in the middle of the bed so it never goes near the end stops.

    Also this error happens while printing. the depth is 3 mm and I set the steps to 1mm so the system passes three times to get to the depth. this is always offset.

    Still puzzled:-/

    #11097
    pca
    Member

    If you don’t have end stops, I suspect that may be your problem right there. Without some method to hard-zero it at some point, if it DOES drift for whatever reason, there’s no way to correct for that. It would only take a small amount too little available torque for it to lose a step here and there and end up all over the place. If it rezeros ever time it homes, that’s going to be minimized or eliminated.

    Another thought strikes me as well; if you have a variable tightness on your belts, caused, for example, by one of the pulleys not quite being round, or the drive hole not being square to the center of the thing, and your torque is a little too low combined with the cutting forces, you can end up with missed steps from that. Each time it goes around you could lose a step or two, and it would add up to a considerable offset which would tend to cause similar results.

    Whatever it turns out to be, I wouldn’t be surprised to learn it was purely mechanical. Some of those sorts of problem can be very subtle.

    Good luck with it in any case!

    #11098
    melticus
    Member

    Cool,
    I will try the repeating Gcode. I will write it myself. At least I know that is correct, eliminating an unknown. Good practical advice, thanks pca. Will let you know my results..
    Matthew

    #11102
    Zootalaws
    Member

    I understand that you say nothing’s slipping, but the whole thing about CNC controllers is repeatability – if you are seeing cyclical differences, it’s nearly always something with a dodgy configuration, mechanical or electrical. If not mechanical, you are missing steps.

    As you’ve confirmed that the drive system is solid, all that’s left is to check software configuration, electrical connections and interference.

    If it was me…

    Always start from a factory reset. Save your current settings, reset, then do no more than ensure your axis settings are right. Turn your stepper pots down to 8 o-clock.

    Rather than using generated Gcode, just issue the commands you need, then you know nothing else is being introduced:

    Tape a digital caliber to your y-axis
    Pull the caliber wide open and nudge the carriage up to the caliber end and zero the caliper and axes.

    G28.3 X0 Y0 // zero x & y

    Issue a slow move command like G1 F500 Y50 then G1 F500 Y-50 and repeat a few times.

    It should repeat with no variance

    Your caliper should read 50mm – if not, your calibration is out.

    Do the same for your X-axis.

    I always use digital calipers for calibration – easy and accurate

    • This reply was modified 6 years, 2 months ago by Zootalaws.
    #11104
    melticus
    Member

    thanks zootalaws. I like your process. I will try that. As an update, I did do a repeatability test with hand coded GCode. first I used a g0 based command

    G0 x10.0 y10.0
    g0 x10.0 y50.0
    g0 x50.0 y50.0
    g0 x50.0 y10.0
    g0 x10.0 y10.0
    g0 x0.0 y0.0

    I copy and pasted this 30 times in the file to repeat it over and over with my pencil jig

    The machine repeated the pattern perfectly with no slips.

    Then I did the same test except changed all to g1 with f40

    This was slow. BUT. I was seeing slips in my x axis (gantry). I did notice the torque was much reduced at this slow rate. so I am suspecting my stepper controller.

    By the way the machine is clean. I removed all dust and grit from the drive system.

    I will try your test,do it, to see If I can get any more clues

    Getting close to the truth I think! Thanks guys.

    #11110
    cmcgrath5035
    Moderator

    I am a bit confused by your comment ” I did notice the torque was much reduced at this slow rate. so I am suspecting my stepper controller.”

    Are you using an external stepper driver (controller)?
    What observation makes you say torque is reduced?

    As you observe, the G0 version of your program runs at whatever you have set for max velocities in X,Y and Z, where as G1 f40 runs at 40mm/minute.
    The torque applied to the discrete rotations of the stepper is nearly the same at Vmax and F40, in a real world the effective torque would be slightly less at Vmax.
    On each step pulse, the stepper controller dumps a pulse of current into each winding, at the correct timing, to create movement. The current level is controlled by the POT. At higher speed, I would expect the motor core to heat up a little, as the stepper heats up a given pulse of current will generate slightly less effective torque, but that should be trivial.

    Keep in mind the following as well:
    The first two lines of your program are
    G0 x10.0 y10.0
    g0 x10.0 y50.0

    tinyG implements continuous motion from the starting point(I’ll assume (0,0)). When the motion gets close to the (10,10) point,a third order polynomial track is computed to keep the the spindle in motion as it changes X velocity to zero and continues on to (10,50). The actual path of the spindle will not pass thru (10,10). The amount of ’rounding” at each corner is a function of the velocity of the spindle and it’s mass, with the mass represented by the jerk parameter ($xjm, $yjm, $zjm).
    When the program runs with f40, the momentum of the moving spindle will be lower and the computed third order polynomial will more closely match the path over (10,10).

    It might be useful to dump your parameter set ($$ command) and copy it to a cloud drive, then provide a URL.

    Also, just to clarify what I think Zootlaws is suggesting “Always start from a factory reset. ”
    I believe he is saying move you spindle to what you want to be the (0,0,0),
    then do a hard reset of the tinyG board with the pushbutton or a software reset from the CLI (^x Reset (control x) )

    For tinyG, a “Factory reset” is a $defa=1 command from the CLI, probably not what you want
    https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97#defa—reset-default-profile-settings

    #11111
    Zootalaws
    Member

    No, I meant $defa=1

    In my experience, when you get weird results, it’s a good idea to go back to defaults and try with basic settings applied (motor def, direction, etc.).

    #11112
    cmcgrath5035
    Moderator

    OK, and I agree that “When things get wierd, do a $DEFA=1 and reload all parameters”.

    I read your suggestion to be “every time you load a new Gcode file, …”,
    which is likely overkill.
    Reloading a full parameter set takes a good bit of accurate typing.

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