Callibration of New Machine

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 🙂

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!

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, 1 month ago by Zootalaws.

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

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.