Calibrating CoreXY

DeJe

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

Morpheus69

Hi, i had same problem (0.2mm of difference) with my new hypercube, now solved i hope. In my case i adjusted thight belts.
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

DeJe

Thanks.

But as I said already I had no much success in tighten the belts.

I would rather like to have a compensation value for X(A) or/and Y(B) to be set. So the question goes to @Repetier if that would be in any way possible.

best regards,

DeJe

Repetier

If it is constant error that is not firmware related or an effect from backlash which you can set only in pure cartesian printers. Slicers have an option to grow/shrink outline a fixed distance to compensate it. But they do it in x and y the same amount. Also x and y should have same steps as we need for some direction to step x and y motor the same distance to make the move. Mixing resolutions will have unpredictable results.

DeJe

@Repetier, thanks for answering.

I just saw in the firmware you have XY compensation implemented. Am I right it will also work with CoreXY printers? I will try this tonight. That feature I was looking for. :D

Just a few more questions.

- I think I did saw somewhere here that CoreXY is somewhat handled like deltas?

So there are any delta settings in configuration.h I should modify to work best with CorerXY? There was "DELTA_SEGMENTS_PER_SECOND_..." and "DELTASEGMENTS_PER_PRINTLINE" mentioned I think.

- I use DUE with (modified) Ramps 1.4. Should I enable or disable quad stepping?

Regarding FAST_COREXY. Do you still working on that feature? In my tests it does not really work good as mentioned in the first post. But I am willing to test/debug if you like.;)

Thanks,

DeJe

Repetier

If you mean backlash with xy compensation, I do not think it works with core_xy since you always use 2 motors and there the backlash needs different handling.

FAST_COREXY is delta like otherwise not. So far I know it is working as supposed, so I'm not working on it. Having no core xy at the moment that is hard to tell how good it works. Soon I should get a core xy printer so I can tell myself.

DeJe

Thanks. I do not have backslash. I just want to use "AXISCOMP_TANXY".

This should do the same in firmware as modifying the belt tensions in hardware.

Anyway, I try it out and let you know here.

Ah I see, only in FAST_COREXY its like delta. Thanks for clearification.

Regards,

DeJe

Repetier

AXISCOMP_TANXY is no problem. That is just a transformation to coordinates and should work.

DeJe

@Repetier, I had a short test as it is late already. ;)

It worked as expected. I got way below 0.05mm difference between X/Y using TANXY in second shot (had the sign false in first try). :D

Thanks again and best regards,

DeJe

geoffreyforest

Hello,
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.

Repetier

It just does a axis transformation to correct wrong angles:

// 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_COREXYZuint8_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 integercorePosSteps[B_TOWER] = static_cast<int32_t>((cartesianPosSteps[X_AXIS] - cartesianPosSteps[Y_AXIS]) * 1.01);and you are done.

geoffreyforest

Thank you sir, I follow your explanation.
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

Repetier

Yes, the nonlinear methods use a lot or memory for nonlinear data precomputed. Since the corexy only uses it but is not nonlinear you can reduce the subsegments per line safely to 10. As longa syou have 900 byte free in ram everything should work fine.

Be carefull with my change to select the case that you are using. As you see there are 5 cases.

geoffreyforest

I reduced both DELTA_SEGMENTS_PER_SECOND_PRINT and DELTA_SEGMENTS_PER_SECOND_MOVE to 10. I have 978 bytes free for local variables :) Maybe my next controller should be a DUE.

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.