Circles come out as ovals

[nsmith]

Every time I print an object that is circular it becomes elongated along the Y axis. What would cause this? What should be changed ?Everything else seems to print fine

[RetireeJay]

Which model printer do you have? (Simples are more susceptible to slipping in X and Y)
Are your X and Y calibration numbers very close to being the same? (They should be)
If you print a square and measure it, are the sides really equal?
If you look at the G-code file in the graphics screen of Repetier, does it show the circle as a circle? (maybe there's a problem in the G-code, probably traceable to a problem in the STL)

[nsmith]

Printrbot Plus V1

I will check my calibration numbers

I dont think it is the STL because this has happened across multiple prints with various STL files

[RetireeJay]

I have a Printrbot Plus also.

In Repetier, there is a menu item called "tools" which gives you a calculator for calibrating according to which belts you are using. Assuming that you are using the same belts for X and Y, then your calibrations should be extremely close to identical. For example, I am using a belt pitch of "2mm (GT2 Belt)" and a pulley with a tooth count of 20. So this gives me 80 steps per mm. After extensive work calibrating rectangles inside and outside dimensions, I ended up using 81.1 for both X and Y. That's just a shade more than 1% greater than the theoretical value - and it's probably because I was overriding Slic3r's automatic generation of trace width with a wider one. So what I'm saying is an excellent place to start is with the exact theoretical values, and keep X and Y identical.

Now, to put this into practice, use Repetier's "Config" menu item "Firmware EEPROM configuration" screen. Enter the correct values for both X and Y calibration, and then click on Save to EEPROM. Verify yes, you want these values in EEPROM.

Finally, make sure that your Slic3r configuration does NOT have any M92 commands which would override these nice, clean values. If you use Slic3r from within Repetier this can be tricky because you have to control which configuration file for Slicer is being used by Repetier by its name alone.

<Soapbox> I wish that Slic3r gave you clear visibility of much, much longer names for the configuration files it creates. When you have dozens of options to choose when storing the configuration file, it's impossible to give clear and meaningful names that fit inside the tiny selection windows they give you. </Soapbox>

[Tdeagan]

my Plus V1 had this problem and it was the motor mount
viewtopic.php?f=15&t=2684

Normally, it would be the set of things RetireeJay is describing, but...

[nsmith]

Interesting I will check out the motor mount

I did print a 25mm calibration cube

http://www.thingiverse.com/thing:45225

The x axis was pretty much on 25.07mm but, the y axis what off and measured 25.7mm

I use slic3r/pronterface/LCD Screen and I set my calibration via the start of G code(Which Retiree Jay is not a fan of, and understood #rant accepted) right now I have

M92 X64.8592 ; calibrate X
M92 Y64.8592 ; calibrate

Going by the math for the 25mm cube calibration the value seem not to change much

- new_steps_per_axis = 25/measured_size_in_axis_in_mm * current_steps_per_axis.

But I will try again and report back

I wonder if the problem in the motor mount can be offset by changing the value? As a Controls Engineer I spend my day solving mechanical problems via programming

[RetireeJay]

It's not at all clear how the motor mount being trapezoidal would affect the calibration. The wood piece the motor is mounted on remains parallel to the carriage; it's just a little offset horizontally. So the motor shaft is still perpendicular to the path of the belt, and if the belt isn't slack then rotation of the pulley = movement of the belt.

However, a severe trapezoid may be a symptom of excessive belt tension. The motor bearings do have a limit to how much lateral force you can apply before the friction starts to build up and the motor starts to skip steps.

I spend my day solving mechanical problems via programming

I've been in your shoes, but in this case I highly recommend finding the root cause. If you plaster over a fundamental problem without understanding the mechanism, then as time goes on you will continually have to tweak your correction. But if you fix it so it's working the way it should then you can move on to the next optimization and not worry any more about this one. [You do realize that 3D printing is a never-ending search for even better optimizations, don't you? ]