Delta DELTA_DIAGONAL_CORRECTION_A not applied

forerunnert

Hello,

I've spent the better part of a week trying to wrap my head around why I can't get Repetier_firmware to properly apply DELTA_DIAGONAL_CORRECTION_A on an enlarged Kossel delta running v0.92.8 (Ramps 1.4).

I started with carefully measuring my diagonal rods and pairing them on size. I took the mean of all and used that for DELTA_DIAGONAL_ROD.

Based on that I entered in my Configuration.h:

#define DELTA_DIAGONAL_ROD 320.68 // mm

#define DELTA_DIAGONAL_CORRECTION_A -0.035

#define DELTA_DIAGONAL_CORRECTION_B -0.06

#define DELTA_DIAGONAL_CORRECTION_C 0.09

I then continued with using the online Escher calculator (http://escher3d.com/pages/wizards/wizarddelta.php) to generate probe points which I measure using my probe. These converge consistently to ~0.02mm with the generated numbers for endstop corrections, delta radius, homed height and  tower position angle corrections. The latter I added to DELTA_ALPHA_A - DELTA_ALPHA_C and uploaded all numbers using Repetier_host to change them in EEPROM.

Then I moved on with diagonal arm correction to correct for discrepancies in scale. I printed a calibration object consisting of 60mm arms rotated so they align with the X, Y and Z towers, and measuring them afterwards. They were all off by 0.2-0.5mm.

I calculated corrections with:

(measured length(arm) / wanted length(arm)) * DELTA_DIAGONAL_ROD(arm) - DELTA_DIAGONAL_ROD(arm)

taking into account the earlier DELTA_DIAGONAL_CORRECTION's.

After each change I recalculated endstop corrections, delta radius, homed height and  tower position angle corrections.

This worked great for the B and C tower, which I get within 0.01-0.02mm of the 60mm target but tower A is consistently 0.4mm too small :-(

Even making tower A diagonal arm 5mm shorter still gives me a printed result of ~59.6 mm: it never seems to change.

I think my methods are sound, so that would leave me a bug in repetier_FW or am I misguided by an EEPROM peculiarity?

Or should I enter my corrections in Configuration.h for them to stick better? I'd rather not since I like the EEPROM uploading better.

Thanks,

Michel

Repetier

Checked the computations and correction A is included the same way as B and C (symmetric problem) so I think the math is correct.

forerunnert

I did the same earlier :-)

I eventually 'fixed' my problem by re-doing the Escher calibration steps with my original measured diagonal rods, a few mm larger delta radius and 0's for endstop and tower offsets. 

That ultimately got me within 0.1mm for XYZ dimensions which was good enough for what I had to do. I guess the Escher calculator was eliminating my diagonal rod adjustments (I probably should have only calculated endstop and delta diagonal only and not all 6 factors).

I wonder though: have you ever considered just using a scaling factor for X and Y positions?

It seems that would have solved my case: make sure that the printer is calibrated to print absolutely flat in XY (I got 0.03mm deviation easily), print two calibration objects, determine scale and apply that to every X and Y move.

Or would this have other side-effects?

Thanks!

Michel

Repetier

If you mean different steps per motor that would be a problem. All calculations are done in steps assuming they are all the same, so nothing would work any more until you rebuild to a more complicated math. Maybe later when we can switch to pure float positioning until conversion to motor steps.

forerunnert

No I meant more in line with actual XY coordinates, eg. the same effect as scaling X and Y of the to be printed object in the slicer would have.

I don't know how that would end up in code though.. could it be as simple as parsing the gcode and multiplying X and Y coordinates with their respective factor? 

I've read a lot of experiences of others dealing with the same issue of having a perfectly flat printing delta but with dimensional inaccuracy. I couldn't find any bullet proof method for correcting the XY inaccuracy though and this seemed such a simple solution.