Printing ovals instead of circles
-
@Manuel207 said in Printing ovals instead of circles:
M556 S100 X-1.058
What results do you get without skew correction?
-
@droftarts I checked them. They are all tight on the motorshaft.
-
@Phaedrux I tried to see if the skew compensation has an effect on the dimensions of the ovals. But the result is exactly the same with and without.
-
@Manuel207 Are the oval's axes aligned along x & y, or at 45 degrees to x & y? If the axes are aligned along x & y, it's not the skew compensation, but a scale issue between the axes, or backlash in the belts. If it's at 45 degrees, the skew compensation would fix it.
(update... oops. I forgot this is core-xy, so the syndrome would be different. since the belts already pull at 45 degrees, both belt slip and skew should make an error at 45 degrees. This still leaves the question as to which axis the error is on.)
-
@mendenmh The ovals are 45 degrees to x&y, good point.
It's a rectilinear cartesian motion system. Printhead is on xy (uy). Y-axis runs on two individual steppers, each has its own limit switch.
I could try to play with the skew compensation, but the current measurements work to produce rectangular parts. -
@Manuel207 Are the parts really rectangular, or parallelograms? They would have the right size in x & y if there is skew, but the right angles will be very slightly off right. It is most noticeable on circles, since slight bumps on the corners of rectangular pieces make it really hard to measure the angle between the flat faces. What I did was printed a large, thin circular plate and then measured it carefully, and adjusted the skew until it was round. I now have a really well-calibrated printer.
-
@Manuel207 said in Printing ovals instead of circles:
I don't run an IDEX nor do I use any external drivers but there are a few things that look strange in your config.g
M569 P5 S0 R1 T2.5:2.5:5:0 M569 P6 S0 R1 T2.5:2.5:5:0 M569 P7 S0 R1 T2.5:2.5:5:0 M569 P8 S0 R1 T5:5:10:0You have different values for drive 8. Are those values correct?
Also, from the WIKI we have quote .......
" RepRapFirmware takes the highest T parameters seen in any M569 command, and applies those values to all drivers for which any nonzero T parameter was specified."
That's a bit open to interpretation but as I read it, the T value for drive 8 will be applied to drives 5,6 and 7 but as they are different motors, are those values appropriate?
Then we have.............
M350 U16 Y16:16 Z16:16:16 E16:16 I1Firstly you haven't set micro-stepping for the X axis. I believe the default is 16X so it might not matter but it's always best to explicitly declare these things. Secondly, micro stepping is applied per axis and not per motor. You must use identical motors and remove the colon separators for Y and Z (but not for the extruders as these are treated as separate axes). I believe the firmware will use the first value and ignore the others, but again it's best to do it correctly.
Then we have.........
M92 X40.00 U80.00 Y53.33 Z640.00 E396.00:396.00This is very strange. I assume the U axis is the second "X" axis so why are the steps per mm so different given that micro stepping is the same? Are you using different size pulleys?
More importantly, the value for the Y axis is a very strange number (53.33) - almost as if you have an imperial rather than metric size pulley. How did you arrive at this number? If you command a (say) 300 mm move on each of the X,U and Y axes, do you get exactly 300mm of movement? If the steps per mm for the Y axis are not correct, then that would certainly give you ovals instead of circles.
Next we have ....
M566 X400.00 U400.00 Y400.00 Z300.00 E3000.00 M203 X20000.00 U20000.00 Y20000.00 Z2100.00 E3600.00 M201 X2000.00 U2000.00 Y2000.00 Z400.00 E4000.00This is not relevant to your issue but you need to specify values for the second extruder using a colon separator in all of the above commands.
Also...
M204 P4000 T5000Again, not relevant to your issue but the firmware will apply the limits set in M201 so higher values in M204 will have no effect.
Lastly....
M906 U1000 Y1800:1800 E1000:1000 I30Firstly you haven't specified a motor current to the X axis (nor the Z axis). This will result in a very low current being applied so you might well get missed steps which could lead to ovals instead of circles. Secondly, you have used the colon separator for the Y axis but the firmware does no support different current settings for multiple motors on the same axis. So add the motor currents for X and Z but remove the second value for the Y axis.
-
@deckingman I have different values because I have different external motor drivers. Drive 5-7 driving the z-axis and drive 8 the x-axis. Since i ran out of onboard drivers on my duet wifi I used the drivers i had laying around. The project grew over time. When I started the build I was on a budged. Nowadays I would switch to a Duet 3 board.
I need the higher values for the DM542T to work properly. Lower values caused wierd layershifting to one side.Good point with the microstepping per axis, I corrected this thank you!
The x-axis is not listed because I set microstepping via dip-switches on the external motor drives. (With this in mind I can delete the z-axis microsteps too)The different steps/mm values for x and u also refer to using different motor drivers. U is driven by the onboard duet wifi driver and x by the external DM542T.
I am running a HTD 3M 10mm belt on the y axis with a 20 teeth pulley.
The calculator gave me this value:
The measured dimensions of the parts are correct. Is there better way to measure the driven distance directly on the axis?
Thanks for the tip with the colon seperator I updated my config file!
The currents for x and z in M906 are also not specified beacuse i am driving them of the external driver.
-
@Manuel207 Hmmm. So do you get ovals with both X and U? It might be worth checking. If U uses an onboard driver and X is using an external driver, then if there are differences in prints it would indicate an issue with the external driver settings. If the prints are the same, then we need to look elsewhere.
The U axis steps per mm calculator looks correct and I get the same number. i.e. 3mm pitch x 20 teeth = 60mm per revolution. 200 full steps per rev / 60mm = 3.3333 full steps per mm x 16 micro steps = 53.333 steps per mm. But it might still be worth checking. Looking at you axis limits, you should be able to do a 400mm long move (25.5min, 436.7 max). So you could get a fair approximation of actual distance using a steel tape measure. You ought to be able to measure within a mm which is a maximum error of 0.25% over 400mm. If the ovals are caused by incorrect steps per mm and you command a 400mm move then you should see that with a tape measure. i.e if it's within a mm then it's probably right, if it's 5, 10 or more mm out, then that's the problem.
-
@deckingman I tested a 400mm move and it is nearly perfect (maybe 0,2-0,3mm if even measurable?).
I also printed the same part with the second tool and voila perfect circles. So you are on the right path. It has probably something to do with the external driver. I am going to test different microstep settings and currents on the external driver? Do you have other suggestions what it could cause?
-
@Manuel207 said in Printing ovals instead of circles:
@deckingman I tested a 400mm move and it is nearly perfect (maybe 0,2-0,3mm if even measurable?).
I also printed the same part with the second tool and voila perfect circles. So you are on the right path. It has probably something to do with the external driver. I am going to test different microstep settings and currents on the external driver? Do you have other suggestions what it could cause?
Well at least that's narrowed it down to the external driver. Sorry I have zero experience of external drivers so can't offer any other advice. Maybe someone more knowledgable than me about these things will step in.
