Delta printing undersized

I have an Anycubic Kossel Linear Plus running Marlin 1.1.9 and, on the whole, I'm very happy with it. It's easy to manage and produces some good prints for me, both in PLA and ABS (even some TPU).

However, a couple of days ago I tried to print a fairly large object, and it came out undersized. First of all I thought I'd made a mistake in my OpenSCAD code, but when I recheck I couldn't see a problem with my calculations. I then I checked the dimensions in the STL file using netfabb - and they were what I had coded in OpenSCAD.

I then designed a simple test piece, a cro#define DEFAULT_AXIS_STEPS_PER_UNITss shape of 150mm on each leg. When I printed this on the Kossel I ended up with a piece that was about 148mm on each side. I tried it on my CoreXY printer and that gave me a part that was exactly 150mm on each leg, as designed.

Now when I had a similar problem on my old Prusa-clone machine with a very old version of Marlin it was very simple to change the 'steps per millimetre' value to bring it back to where it was meant to be. However, when I looked in the configuration.h file for the Kossel I saw that things had changed - the steps-per-millimetre seems to be calculated.

//=============================================================================
//============================== Movement Settings ============================
//=============================================================================
// @section motion

/**
 * Default Settings
 *
 * These settings can be reset by M502
 *
 * Note that if EEPROM is enabled, saved values will override these.
 */

/**
 * With this option each E stepper can have its own factors for the
 * following movement settings. If fewer factors are given than the
 * total number of extruders, the last value applies to the rest.
 */
//#define DISTINCT_E_FACTORS

/**
 * Default Axis Steps Per Unit (steps/mm)
 * Override with M92
 *                                      X, Y, Z, E0 [, E1[, E2[, E3[, E4]]]]
 */
// #define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 80, 98 } // This is no longer used in Marlin 1.1.9 - it is now calculated below

/**
 * Default Axis Steps Per Unit (steps/mm)
 * Override with M92
 *                                      X, Y, Z, E0 [, E1[, E2[, E3[, E4]]]]
 */
// variables to calculate steps
#define XYZ_FULL_STEPS_PER_ROTATION 200 // These are the setting for the stock Stepper Motors, pulleys and Belts on the AnyCubic Kossel
#define XYZ_MICROSTEPS 16
#define XYZ_BELT_PITCH 2
#define XYZ_PULLEY_TEETH 20

/

I used autotune to set this up and that has worked well, with consistent and even first layers and clean, straight sides. It's just the undersize that's annoying me! I could scale the object in the slicer, but that's cheating...

I could probably uncomment and change the #define DEFAULT_AXIS_STEPS_PER_UNIT setting, but that isn't in the spirit of the new Marlin, and would also be regarded as a backwards step.

All help gratefully received...

Edited 1 time(s). Last edit at 05/19/2020 04:11PM by David J.

Typically dimensional inaccuracies on a delta are due to an incorrect value for the diagonal rod length. Try using a formula like this:
ActualSize/ExpectedSize*CurrentRodLength=NewRodLength

Using the example you gave, I would try decreasing your rode length by about 1.3%.

Side note: I have the same printer. AnyCubic didn't cut the rods to the same length (they are supposed to be exactly the same). This can lead to problems, it would be a good idea to check yours...

I was wondering if it was something like rod length... I have limited knowledge of Delta mathematics...

I did check the rod lengths when I assembled the printer - they all matched pretty well perfectly (I was surprised too!).

Now I'll go and try out that formula.

Late update: I've been using a different printer to finish a project, so I wasn't able to get to this issue until now.

I can report that, after a bit of fiddling with rod length and subsequent recalibration, the dimensions are far more accurate than they were previously.

There is still a small discrepancy between the X and Y axes, but that may be due to individual rod lengths. It's certainly good enough for me, although if I take the printer apart sometime in the future then I'll put more effort into checking and fixing the rods (if necessary).

Thanks for your help!