Calibrating CoreXY
Hi,
since a couple days (if not weeks) I try to calibrate my CoreXY printer. It is a custom build based on VulcanosV2 on Instructables.
Without success.
Going to conclusion first, I think there's something in firmware math which to me seems to be wrong.
But going to details...
I print a 50x50mm object, 45 degree on the bed. I use Simplify3D and Repetier-Host/Server.
After measurement I got a difference between x and y axis of about 0.2 mm.
So I tried to reduce this difference. First of all I tried to adjust the loose or tight of the belts.
For this I got a bit better results but still way over 0.1 mm. But one belt I had to tighten that much, I clearly see that my printer mechanics is way off of square. Also the print itself isn't square anymore!
Next I changed pulleys from right to left than motors from right to left... no difference.
Last I changed steps of A and B motor but still got the same. Not only the same, it does not even change the direction of difference.
For example:
A=160 steps, B=163 steps -> x=49.4mm, y=49,6mm
A=163 steps, B=160 steps -> x=49.4mm, y=49.6mm
If I look right this should not happen on CoreXY mechanics? Am I wrong?
What I also discovered: If I do extreme step change, both axis starts moving even for 45 degree movements.
For extreme step change I set A=160 steps and B=170 steps and vice versa. Both axis are moving. For sure I got a trapezoid, but it keeps same results. X still is the same amount smaller than Y for both settings.
So you see, I do not have any idea how to solve this issue.
Is there any setting were I can get to "swing" around 0 difference?
I also tested last dev firmware and FAST_COREXY. For release version there is no difference. For last dev version I do have serious issues with Z homing. X and Y home seems to work OK. But Z homes normally but after that it moves down about 20mm and I do not have an idea how to remove that "offset".
Sorry for long post. But I am a bit frustrated because I do not find any answers. To some 0.2mm or 0.1mm doesn't seem to be an issue. But I mainly print mechanical parts were this difference indeed is an issue.
best regards and thanks for reading,
DeJe
Comments
Be sure are the "same" tight, not too much, but no any play during movements, when you see "rigid" belt movement on your core should be enough. I reduced the difference under 0.1mm.
good luck
I am having a similar issue as stated above. I have a corexy machine that previously ran smoothieware. My two XY motors need slightly different steps/mm values. This worked with smoothie, giving a unique value for each motor resulted in correct dimensions when printing. But I see you said above that with repetier-firmware, the two values must be the same for the XY motor steps/mm.
Can I find documentation on how the AXISCOMP_TANXY and FAST_COREXY functions work? It seems I need to implement these to calibrate the motors individually.
Thank you. This is the only difficulty I am having. I like the firmware very much, and flashing from Repetier-Server is VERY convenient.
// Axis compensation:
x = x + y * EEPROM::axisCompTanXY() + z * EEPROM::axisCompTanXZ();
y = y + z * EEPROM::axisCompTanYZ();
So I do not think axis compensation is what you need here.
FAST_COREXY 1
makes firmware use the nonlinear functions for deltas just with core xy equations. Currently the config tool can not handle that and you need to set it manually and select delta to set the nonlinear params and then switch back. I'm working on a new config tool for 1.0 that will be able to handle this better, but it is not finished yet. In that case positions are computed in motion.cpp like this:
#ifdef FAST_COREXYZ
uint8_t transformCartesianStepsToDeltaSteps(int32_t cartesianPosSteps[], int32_t corePosSteps[]) {
#if DRIVE_SYSTEM == XY_GANTRY
//1 = z axis + xy H-gantry (x_motor = x+y, y_motor = x-y)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Y_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[X_AXIS] - cartesianPosSteps[Y_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[Z_AXIS];
#elif DRIVE_SYSTEM == YX_GANTRY
// 2 = z axis + xy H-gantry (x_motor = x+y, y_motor = y-x)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Y_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[Y_AXIS] - cartesianPosSteps[X_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[Z_AXIS];
#elif DRIVE_SYSTEM == XZ_GANTRY
// 8 = y axis + xz H-gantry (x_motor = x+z, z_motor = x-z)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Z_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[X_AXIS] - cartesianPosSteps[Z_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[Y_AXIS];
#elif DRIVE_SYSTEM == ZX_GANTRY
//9 = y axis + xz H-gantry (x_motor = x+z, z_motor = z-x)
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS] + cartesianPosSteps[Z_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[Z_AXIS] - cartesianPosSteps[X_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[Y_AXIS];
#elif DRIVE_SYSTEM == GANTRY_FAKE
corePosSteps[A_TOWER] = cartesianPosSteps[X_AXIS];
corePosSteps[B_TOWER] = cartesianPosSteps[Y_AXIS];
corePosSteps[C_TOWER] = cartesianPosSteps[Z_AXIS];
#endif
return 1;
}
#endif
But I do not really understand why you have different steps per mm assuming both motors use same pulleys and belts it should be identical especially with equal tension on the belt. Computations are here in integer, but that would be the equation where you could change the weights for the motors in nonlinear case. Guess you would need to multiply one of them with a factor after converting it to float and then convert result back in integer
corePosSteps[B_TOWER] = static_cast<int32_t>((cartesianPosSteps[X_AXIS] - cartesianPosSteps[Y_AXIS]) * 1.01);
and you are done.
I believe my two XY motors are not exactly the same, thus needing slightly different steps/mm values. When I did this in Smoothie, it worked to correct inaccurate print dimensions. I'll first set the steps/mm in EEPROM so that one of the motors is correct, then do a test print. Then I'll try changing the corePosSteps[B_TOWER] calculation you suggest above and see if that does the trick.
Incidentally, I compiled the firmware with FAST_COREXYZ enabled (not FAST_COREXY, I must have mis-read it in another thread) and I got a warning that the global variables used 88% of memory, stability issues might arise. I suppose this is due to the non-linear calculations? I didn't get this warning before.
Thanks
Be carefull with my change to select the case that you are using. As you see there are 5 cases.
I did see the several cases of drive system and only changed the line that pertains to my setup. After making the change and inputting my custom factor, the 4 sides of my test print are all within 0.2% of theoretical (before, two sides were about 1% off). Thanks so much for the help! I've saved this page for future reference if I need to do this again.